What is our primary use case?
We're running jobs on a global scale. Being a global company, we're running scheduled jobs and ad hoc jobs across different regions. Jobs cover backend processing, financials, and the like. We're running on an SAP ERP system and we're also running Informatica for data warehouse. We're running BusinessObjects web reports as well as a lot of straight Windows and Unix command-line things. We run FTP processing, PGP encryption processing, and data services jobs. We're running about seven or eight of the different adapter types that Tidal has available.
We have it on-prem. Both our test and production environments are on fault-tolerant setups.
How has it helped my organization?
When I started here, they had already been on Tidal for about five years. So I'm not really sure where they were before Tidal. They did a lot of mainframe things in the past. From what I've heard from people here from the "old school," once they globalized and got everything into Tidal, the ability to see everything across the scheduling universe was a huge improvement. They didn't have to give different people different access to different systems and check four or five things, just to make sure something was running correctly.
The solution helped to reduce weekend and overtime hours. We're a 24 by 7 support model. Regarding the Tidal application, the one thing that we try to explain to anybody, from a support or monitoring standpoint, is that jobs trigger through Tidal, but not physically in Tidal. So if we have, hypothetically, an SAP job failure, it's not a Tidal failure, it's an SAP failure. So it goes right to SAP support, which saves time. In the environment I came from, they didn't have that mentality. So if, hypothetically, an ERP job failed, they'd call the Tidal person first instead of the ERP support. That type of understanding, as a whole, really helps from a support standpoint. The admins don't get a lot of calls unless there's an actual issue with the Tidal application itself.
In the time I've been here, we've definitely increased staff availability. From a business standpoint, we've started utilizing file monitors more, for what they call "file events" within the application. In the past, when an end-user would drop a file in SAP, for example, they'd contact our operations team, or send an email saying, "Run in this job." There isn't a real need for that in many cases. We've implemented a lot of file events that will actually only run jobs if they need to, if a file's available. Along the same lines, we had processes that would run a process in SAP, and even though it didn't create a file, there were other jobs downstream that would be hanging out and waiting for a file that never showed up. So not from just a staff availability point of view, but in terms of resource availability, it has definitely improved things a lot. From an operator standpoint, I would estimate Tidal is saving us 15 to 20 hours per week, just in manual interaction with inserting jobs on a request, since a lot of that stuff was implemented at our end.
Regarding job counts, we're pushing over seven million a year. That varies, obviously, depending on request jobs and other things. There are some processes that we shut down for year-end processing, so they stop running for a week or two. But from an expansion standpoint, we are constantly looking to see where else we can use Tidal, for new applications that are coming online or things that people are running on their own where they haven't even thought about Tidal's scheduling. In 2019, we did 7.7 million jobs. In 2018, we were at 7.1 million. In 2017, we were at 6.1 million. So with Tidal we're adding on the order of half-a-million jobs per year.
What is most valuable?
The feature that I find to be valuable, as I'm working with other folks, is the ability to cross-schedule across platforms, and the flexibility that comes with that. I'm kind of biased, as I've only used Tidal. I haven't used CA or IBM or any of the other scheduling platforms that are available on the market.
From a management standpoint, when using the solution for cross-platform, cross-application workloads, I've never had a problem with the application. It's very interactive, especially with the different security levels that they offer. We have two or three operators who are at a certain level where they can actually rerun jobs. If they fail, they don't actually have to get ahold of a Tidal administrator. The only thing they don't have access to is changing the master settings on the jobs. That flexibility of access is a big plus.
We do have a few developers who will actually set up processes within Tidal, but only in the test systems. They get a little bit more access that way, but they obviously have to have training prior to that, from me, on how to properly schedule things in Tidal. So the security and flexibility are valuable features.
They have a lot of pre-set stuff, but you can actually create something like: "Run the third Wednesday of every third month on a blue moon," going to the extreme. Their scheduling functionality is really advanced enough where we can create a lot of different kinds of customizations, based not only on a regular calendar year, but on fiscal calendars and regional calendars. We have jobs that process files for our EU operation and when they have a bank holiday over there we don't need to run the job. We can tie up those jobs that don't need to run on their local, European bank holidays.
The solution also enables admins and users to see the information that is relevant to them. The admins have super-user access, so they can actually adjust and transport different jobs from test to prod. Whereas the operators can adjust a job that's already scheduled if they need to, based on direction from support. They can change this variable, or change this setting, or change this text. But they don't have the access to actually change the master copy of that job. So, a one-off change is literally just that, a one-off change of the next compile scheduled. Otherwise, it's going to run as it's normally set up.
Another good thing that Tidal has is in regard to the history retention of job failures. Whereas our SAP ERP system usually has an eight-day history retention for jobs, Tidal can actually go back longer than that. So if somebody says, "Hey, why did this job fail three weeks ago?" we can bring up the failure message, which is something they can't do directly in SAP.
What needs improvement?
For the most part, the drill-down and the logging are really good. But if we take an Informatica job, for example: We have the ability, and the operators have the ability, to actually drill down and see, at a session level, where the failure is. There is, unfortunately, no way to extract that into an actual output email or failure email. It's not that that information is not available, but extracting it into an email would be a nice-to-have. It's minor, but it would definitely be a help. In the grand scheme of things though, you can drill down to session-level failures and get that error message to provide to support.
Another thing has to do with job events. A job event triggers when a job completes. It sends an email or reruns a job. Right now — and I've even talked to Tidal about this — it will run all the events at the same time. It doesn't provide the logic to say, "I want this job to rerun five times. If it fails on the fifth time, then send an email: 'Out for Failure.'"
The only other thing I would like to see is an easy way to flag jobs running longer than a certain percentage of the estimated time they should take. Right now, you can hard code in a max expected run-time and you can trigger a notification off of that. The unfortunate thing is, in a consumer product-related business such as ours, Q3 and Q4 jobs are going to run longer. So you can't really put a hard-coded expected run-time, because that's going to fluctuate. So it would be useful if we could specify something like "Flag this job if it runs 25 percent longer than estimated," which the solution does track for 30 or 35 days. That's what they usually recommend, out-of-the-box, for keeping track of history.
For how long have I used the solution?
I have been using Tidal for about 13 years. I used it for about eight years at my previous company and then I came over to this company.
What do I think about the stability of the solution?
I came on about four-and-a-half years ago here and Tidal has been really solid. The high-availability and the fault monitoring they use is very good. I can think of twice, in the last four-and-a-half years where we've actually had to failover for one reason or another. And the bottom line was that it wasn't even a Tidal issue; it was something to do with patching. One of the patches from Microsoft was a little funky. From a stability and support standpoint, this is a rock-solid app, in my opinion.
It's very stable, especially for those who utilize what they call Fault Monitor or Fault Tolerance. When we do patching, the jobs, in and of themselves, automatically fail over from our primary to our backup. There might be a slight disconnect in the web UI that the operators use, but that maybe lasts a minute because of the cut-over time. But it picks up all of the backend PIDs, and the jobs just pick up where they left off. From a stability standpoint, this is a really good product.
What do I think about the scalability of the solution?
From what I've seen, the scalability is very good. There are companies that I know that run millions of jobs a day. I've been through some user groups that have some people running nine different instances of Tidal, and they're running a lot of different things. So, the 7.7 million a year we run here, coming from where I was beforehand where we were running about 400,000 a year, seems like a lot. But we're still a small fish in the barrel compared to how other Tidal customers are using it.
So the scalability is phenomenal. We're always looking for that next hook and working on trying to tie into other things. We're keeping our versions updated as much as we can, in regard to OS compatibility. Take Informatica, as an example: We're making sure that we're as up-to-date as we can be with the versions that are out on the market.
Which solution did I use previously and why did I switch?
In my previous company we used the Lawson ERP's internal job scheduler. There were Windows tasks that we had to check on. They were running a lot of VB6 stuff. In my current company, I came onboard years after they had already cut over to Tidal. I know they had some mainframe stuff in the past, but I don't think they converted from something like CA to Tidal. Tidal was their first choice.
How was the initial setup?
I came in at the tail end of the initial setup when I first started with Tidal back in '07. The decision had been made on the application before I got the position of scheduler in the Tidal admin. In terms of the actual setup, I was on the periphery. Once it was set up, I got more involved. But I have been involved since then with the system upgrades and version upgrades.
Upgrades seem to be fairly straightforward. When it comes to hotfixes and partial, mid-version updates, it's pretty simple. You don't have to call the vendor in. When it comes to versioning upgrades, like when we'll go from 6.3 to 6.5 in a couple of years, we do utilize a third-party vendor to come in and assist, because they do a lot of backend database cleanup and scrubbing. We're running in a SQL database for Tidal, and I know just enough SQL to get me in trouble. So we do rely, especially because this is such an enterprise-based application here, on having a third-party come in and take over the upgrade part of it. We work in conjunction with them, making sure jobs are set and that the copies are good.
As for the learning curve, a lot of it depends on the individual's knowledge of the particular systems. Windows is fairly straightforward. If you know some Unix commands, you can help set them up really easily within the application, when you're setting up a job to run from the Unix command line. If you don't know SAP or whatever the ERP system of the company is, at least a little bit — enough so that you can navigate through it — there might be a little bit of a learning curve. But it's really not as big as one might think. Take the SAP ERP as an example. I came from a Lawson background. I came into the SAP environment here, which I was totally unfamiliar with. But within about a month, I was able to set up SAP jobs without an issue.
There are some little things involved in understanding how to up jobs if you want to overwrite certain variant settings. Learning to do that, and making people feel comfortable doing that, was probably the biggest learning curve.
The other thing is understanding using API hooks within Tidal to other processes. That's one thing they could improve on as far as their training materials go. I've talked about that with them during the past couple of user calls that I've been involved in. At this point it's still a little rough, but hopefully that will get better as time goes on.
The amount of training a new user needs in Tidal depends on the level they're at. We have a training program in place for our operators who do a lot of the manual reporting and failures, running jobs on request, etc. We'll start them with just an inquiry only so they can see everything that's happening, but they can't act on it. That way they can get a feel for the application. We'll give them that for about a week or so, and they'll work hand-in-hand with an operator who's been onsite and using the application. Then we can roll them out to a test version with test-operator access, for another week or so. By that time, they're through four weeks of Tidal acclimation and they're good to go with everything. Because of the operator's schedule — they work a four-on, three-off rotation, it's not like they're working five eight-hour days of straight Tidal — plus all the other things that are on their plate for their job requirements, they're not going to see every single potential issue that could come up. But they have a pretty good grasp at the end of that time.
We'll usually get a feel from not only the trainee, but also the person who is working with them, about how they are doing and if they feel that they're ready to start doing stuff in production. Generally, within a month, they're up and running as an operator, in both test and prod environments.
Developers are a different story because of all the different things that they have access to regarding scheduling and building schedules. We haven't brought on a lot of developers since I've been here. It would probably take a good two to three weeks for developer training, if someone wanted to know how to set up a job in Tidal. We'd really try to hand-feed them little things, so they don't inadvertently schedule a job, or an entire job group that runs hundreds of jobs, which could really bog things down from a systems standpoint.
What about the implementation team?
The partner we use is a Tidal partner called BLUEHOUSE. They've always been very helpful and very flexible in terms of scheduling. The way we do it here is we'll have them come onsite to update our test system. We'll bring that up online and run that on the new version for two months or so. Then they'll come back and we'll do the production update. The whole time onsite, between test and prod together, is about four or five days. But they do a lot of the prep work for production, while we're doing the test upgrade. When we're ready to go to the production, they're only here for a day or a day-and-a-half at the most for the production cut-over. When it comes to initial support right after the fact, they're very receptive to fielding the questions.
What was our ROI?
I would say we have seen a return on investment by going with Tidal, and not only because of the volume of jobs we're running, but because of the variation of jobs that we're running. It gives us the ability to manually adjust processes on-the-fly, and having that visibility and quick reaction to failures has been a big plus for us.
Which other solutions did I evaluate?
At my previous company they looked at IBM, CA, and one other solution. The reason my old company went with Tidal back then, was that it was the only one that offered integration with Lawson.
What other advice do I have?
As with any product you're looking at, first of all, don't get pigeonholed into it. Don't have a laser-focus on an individual product. But with Tidal, especially now that they're rebuilding the customer base, reach out and work with their salespeople, and network with current users. One thing I found, especially being on some of the network boards — they used to have a Yahoo Group for Tidal — people aren't afraid to say, "Hey, this works great and this doesn't." I'll be the first to tell you what works great and what still needs some work. And now that Tidal has put its own forum together, the company is monitoring and responding to concerns and questions a lot quicker than they used to when they were under Cisco's umbrella.
The biggest lesson I've learned from using Tidal is that it's always growing. In user calls that we've had since Tidal went back to its own environment, they're really looking to rebuild and invest in the application, and make sure that things are up to date and validated. They're working on making sure they're as current as they can be with certain connections.
It's like they have a renewed vision since Tidal was divested from Cisco. They seem to have a real yearning to get back into the way things used to be in the pre-Cisco days. I'm not trying to knock Cisco, but it is what it is, because I worked with Tidal before Cisco acquired the product. Now with the STA Group and a lot of the older Tidal developers and folks "back in the saddle," there seems to be a renewed interest in rebuilding, making it a lot easier, and opening up a lot more process availability for users and customers.
We've got a handful of developers, five or six people, who actually have the ability to create jobs in our test system. We have a team of six operators who have access to Tidal as well. They do the 24-hour monitoring and ad hoc jobs, etc. And we have two Tidal admins. We do have some other folks who have inquiry access into our production system. We'll give people who might be developers in our test system view-only access to prod. Overall we have 15 to 20 people who have access to the system, with varying security levels. I'm responsible for maintenance, upgrades, job migration, and production. I also work with people who don't have access to Tidal and on helping them get jobs set up properly. I also make sure we get the email notifications correct.
For what we're using it for, and what we have, it's very good.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
