What is our primary use case?
I have three installs of Tidal: production, qual and dev. I have a portfolio of 12,000 unique job definitions in production, 13,500 definitions in qual, and about 8,000 in dev.
The Tidal adapters I use are for Windows and Linux agents, as well as Informatica, Cognos, and mSQL.
How has it helped my organization?
With the portfolio of jobs that we're talking about, it's continuing to grow. There is way more work being added to the system than there is work that is being retired from it. That's just the way the animal works. It's been able to handle, perfectly fine, the complexity of the interrelationships between the processes.
We actually ported off of Maestro. Maestro was the scheduler that we were using, enterprise-wide, and it was very inefficiently used when I got here. When we came up on Tidal, we didn't convert anything. We built all of the definitions that exist in Tidal. So over the 15 years, that portfolio has grown.
As a whole, we're trying to automate as many things as we can to alleviate the manual processes. One of the things that Tidal has helped us with, because it is cross-platform: We had a number of different schedulers in this organization and we've been porting everything that was running out of these other, unrelated schedulers into this scheduler. That has afforded us the ability to set up direct dependencies between processes that couldn't talk to one another before. Over the 15 years, we've definitely gained a lot from that. What had been manual controls have become automated controls, by using this tool to replace a number of schedulers.
What is most valuable?
The automation aspect of the solution is the most important. I'm able to construct groupings that have dependencies which automatically allow the proper jobs to run in the proper sequence. That's the strongest selling point of any scheduler.
As for the solution's ability to enable admins and users to see the information relevant to them, the security model that I use is fairly simple and straightforward. For developers and other folks, an inquiry-type access is more suitable for the production environment. I've added functionality for people in both the qual and the dev environments, based on their roles. But I haven't restricted anything, meaning that anyone who has an account can see everything. There is a lot of flexibility in the way that things can be configured with Tidal. You could restrict it down to the point of people only seeing those things that are applicable to them specifically. I found that that would be too restrictive, and result in a lot of overhead to manage. So I went with a much simpler model, but the flexibility is there.
There are certain things I can put in play, triggering events based on statuses. For instance, if I have a certain job type where a number of the jobs are going to "waiting on resource" in the middle of the night, I can configure alerts so that I can assess those and then determine if I have to raise the job limits on some of those resources to make sure that we're not having things held up on necessarily. By the same token, if we're having long-running processes, I may want to tailor that down so we don't have so many processes running concurrently. There's some flexibility in that. I haven't had to rely on it a lot, but there are some features there that can be tapped into.
What needs improvement?
From an administrative point of view, I wouldn't give really high marks to the solution. I actually entertained getting the JAWS application at one point. One of the shortcomings with the scheduler is the reporting capabilities. At least at the time, JAWS was the best that they had for a third-party integration. I think they've got things in the pipeline to help alleviate that gap.
Also, one of the things I'm concerned about is that, with the security we have, there's a hazard that somebody could go in and accidentally delete a master grouping of definitions out of Tidal. Right now, I don't have an easy way to recover from that. It looks like a couple of things that are in the pipeline with Tidal are going to allow for that kind of recovery. There should eventually be a replacement for the Transporter tool. That sounds like it's going to have the capability of doing copies out of Tidal. If I scheduled that once a week, it would give me a copy of definitions out of Tidal. If it turned out that one of the operators, who had the rights, accidentally deleted a grouping of definitions, I would have something that listed definitions that I could go back to and recover.
For how long have I used the solution?
I've been using Tidal Workload Automation for about 15 years.
What do I think about the stability of the solution?
The stability has been fine.
In fact, we're going back to using the master and the fault monitor. We had it disabled for some time, but we've gone back to setting it up with the fault monitor and the master, and the backup. There was a problem with it. There was some kind of a fault status that kept getting triggered. The network person who was in charge convinced us to disable the redundancy that we had set up, and we've just recently gone back to it. And it's been working fine.
What do I think about the scalability of the solution?
We haven't hit any roadblocks with volume, but I think we've been sized properly too, behind the scenes, with each upgrade that we've done. It's been scaling fine. That's the bottom line.
There are systems out there that are larger than ours. We try to get to the user conference, here in Boston once a year, to do some comparisons to other organizations and the way they're using the tools. It's an information-sharing session.
Whenever we go for an upgrade, we look for an assessment of whether we need to provide more horsepower or not. If any of the configuration has to change, we watch that carefully with each upgrade. There's a formula that Tidal provides on whether you should have a small, medium, or large installation, based on the number of definitions that you have. They help with calibrating that.
We consider Tidal to be an enterprise scheduling application, so any new process that comes along is first looked at to see if it can be run from Tidal, whether that would involve purchasing another adapter or whatever else would make it work from here. We want it to be an automated function as opposed to being run manually and not integrated with the scheduler.
How are customer service and technical support?
The technical support is much improved. That's over the course of 15 years. Tidal has gone to great lengths, with the transition to STA, to strengthen its support capabilities and also strengthen the relationships it has with its clients. STA seems very interested in trying to focus on a direction, advertise that direction, and make the current clients comfortable. That, in turn, will help them take on new clients.
Which solution did I use previously and why did I switch?
As I mentioned, we came off of Maestro. Back in 2004 or 2005, when we were looking at schedulers, Tidal was one of the solutions we demoed. Universally, we all decided that Tidal seemed to be the better candidate.
How was the initial setup?
The setup was pretty flexible. We had to come up with our own ways of deciding how to group things and what our naming convention would be.
When we first came up on the product, one of the issues that we noted was that the default sort for all of the jobs was alphabetical. That complicates the ability of the operators to visualize the order jobs should run in. To overcome that, we came up with a naming convention that puts a prefix on all of the job names with a number. So when we create our groupings, within a grouping it will list the jobs in the order that they run. Half of Tidal's clients wanted to see things alphabetically listed and half wanted to see them listed numerically, in the order that they run. The vendor wasn't willing to modify the product to give the user a choice of one order or the other.
I don't remember the original installation taking that long. It took us a while to actually build all of the job definitions. That was a lot of work. It was done within about a week. Once the equipment had been spec'ed out we had an onsite install here in the computer facility.
We've had to train a number of new operators and I don't think it's been a terribly big learning curve for them to understand how it works. The developers, in fact, self-trained in their environments and they seem to be able to maneuver fairly well. There are times I have to explain things here and there, some ways of handling things that are more convention. Those are things they have learned over time. But they seem to do all right with it. There isn't that much of a learning curve.
The only people who need to have the training would be the operations staff. I think there was a beginner's and intermediate course that we originally took, when we came up on the product. And then we learned things as we went.
One of the things that would be beneficial though would be some training that incorporates best practices. You can go through the manual and it will tell you, "This feature does this," and, "these are the parameters that you need to put in," and then the delimiters, but it doesn't necessarily tell you the best use case for certain functionality. I've had a few people mention to me "Oh, you shouldn't do this, and you shouldn't do that." Well, where does it say that in the book? It doesn't. And that's the problem. There's a little difference between an instructional manual that gives you the nuts and bolts of how to do things, and something that's more tailored to best practices, or recommendations of things you should not do. And some of that has to do with the architecture behind the scenes. Users wouldn't necessarily know that unless there was some documentation expressing it.
What was our ROI?
I don't really have metrics for ROI. It's more of a feeling because we've been able to consolidate from all these separate scheduling products into this one scheduling tool, allowing us to have direct dependencies between things. That's an efficiency in itself, but I don't have any statistics to support the number of hours saved and the number of dollars saved. Overall, it has improved our business model with automation.
What's my experience with pricing, setup cost, and licensing?
My experience was that it was very difficult to figure out the licensing cost on an annual basis. I don't know if they've changed the model, but I remember it would take a month to reconcile if we were being billed the proper amount because it was based on the number of CPUs; if they were test CPUs or production CPUs. I recall, and this was probably five years ago, that it was very difficult to reconcile the annual statement with what we had, and to verify that they were components we were using.
Our ability to budget for the solution is a fairly easy aspect of it. One of the difficulties that I have internally has to do with the specialized adapters. I don't think it's well known within my company that I can't just snap my fingers and get an adapter. There's a cost associated with it and the license key has to be updated after we've made the outright purchase of it. I don't think there's familiarity, within our company, of budgeting for the coming year if it involves these additional Tidal components. That's nothing to do with Tidal. That's just an internal struggle.
Which other solutions did I evaluate?
There were five solutions we looked at in total. Two were ruled out right away. When we went to do demos with the three of them, the third one couldn't even do the demo, so it came down to Maestro and Title.
What other advice do I have?
One piece of advice I would have is that if you get into a product, try to keep it upgraded. It's to your benefit, support-wise to be, maybe not on the cutting or the bleeding edge, but close to the current version. That's been a pain point for Tidal, to try and get their clients up to speed.
Stay on the latest version because of the functionality. It's not only relevant to just this tool, but to many IT tools. It's just like the next generation of laptops that are coming out; they're coming out more quickly. The same thing is happening with the functionality that is being added to all of these products, including the scheduling application. It's important to go through the pains of staying up to date.
It's been a good product. We could have done a lot worse. This is a heck of a lot easier to use than some of the other schedulers that I've used in the past. But, then again, it's been proven as a solution, as well. Other solutions are all moving targets. Everybody is making changes in their products. At the time that we made the selection of Tidal, it was definitely constructed a lot better. It was easier to use than the other option.
In terms of the number of users in our organization, I honestly wouldn't mind if everybody in the company had an account to log into Tidal with inquiry access. But I think we've got around 300 accounts set up in each instance. They could be used by managers, developers, operators, and all the other IT folks who have accounts.
For deployment and maintenance of Tidal, since we're doing a 24/7 staff, we're talking about eight people, and three or four other people who are going to be part of production control and/or an IT server ops-type of functionality, because you need that level of support as well from time to time. So we have twelve or so people in one capacity or another maintaining Tidal.
I would give Tidal a solid eight out of 10.
Which deployment model are you using for this solution?
Private Cloud
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. The reviewer's company has a business relationship with this vendor other than being a customer: Partner.