Tidal by Redwood Reviews

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.

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.

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.

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.

I've been using Tidal Workload Automation for about 15 years.

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.

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.

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.

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.

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.

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.

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.

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.

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. 

We use Tidal extensively to run our health and welfare claims processing throughout the day. That's the reason we got Tidal back in 2011. We receive 15,000 to 20,000 claims a day and we use Tidal to process the whole thing, all the way through to creating checks at the end of the day.

Since 2011, we've expanded it to other applications and other processes: mostly reports, and files that come in electronically from other companies that feed other applications. And in a roundabout way, what we use Tidal for is to execute the applications to load whatever needs to be done on those applications.

The transfer function we used to do with Tidal has been switched over to another software product called Cleo. And that is run by our network team. That way they can control all the information that comes in and out of our building. They can put secure FTP on it, encrypt and decrypt the information, and set password protections. Cleo has its own scheduler, like Tidal, but they don't use it. They let Tidal execute the Cleo commands to bring the data in and Tidal will execute any application programs after that.

Overall we run 1,100 to 1,200 steps every day, depending on day of the week. I call them "steps," but they're actually multiple steps. Before you get to the actual processing of a program there might be a move, a copy, or a delete when we're clearing out folders, using DOS commands. We then move data around to certain directories so that either the TriZetto software that we use can find that data or any internal programs that we use in VBS, .NET, Oracle, or MS SQL stored procedures can find that data.

We're also starting to use this new MDM application which captures addresses from various databases, verifies they are correct, and pulls them together into one database. After all of our nightly processing, we have Tidal kick off the main MDM master so that all those addresses are in sync.

Tidal sits on its own database and then it talks, through agents, to the other applications.

People who are on the Client Manager were complaining about response issues. It's never been proven that a batch job is causing the issue, but they do find that so many things are hitting the database at the same time that they shut down the batch job that's running at the time. We've now been able to move our schedules around so that it can just run at night when everybody's off the system.

Also, after a while using Tidal it started to reduce weekend hours by not have to watch it constantly on the weekend. The only time we're really busy on a weekend, now, is when there is a major upgrade going on, as we usually do it on a Saturday or Sunday. But other than that, it's very quiet on the weekend. It has reduced overtime by 80 to 90 percent.

As of right now, the only time we really have overtime is planned overtime. Once a month, our network team applies the Microsoft security patching, so we have to pick a day, once a month to hold everything in the schedule. They then apply their security patches to all the Windows Servers. They bring the applications back up and we have to do a quick, sample test to make sure Tidal is okay. We then run a few jobs to make sure other things are okay and the business users have to check their applications and their data. At that point we turn the schedule back on for the weekend. It sounds like a lot but it only takes about an hour. Where we used to have two or three hours of overtime a week, now it's down to one hour a month.

In addition, our number of jobs has been growing steadily. We do about 1,100 to 1,200 jobs a day. We could go further but we have never really tested how many jobs we could do.

One of the most useful features is being able to set up a schedule and create dependencies. The calendar can kick off processes at certain times, based on dependencies that you specify, like time, or whether another process has finished. Dependencies are the most useful thing.

You can also verify that a step is finished. And some of our departments are really interested when something has started. You can send out an email saying this step has launched or this step finished normally and, obviously, we always have it notifying us when something goes wrong.

It's also very useful to do repeating steps. If you need to do something multiple times throughout the day, it's very easy to just copy that group of steps or jobs and continually process the same thing each time. And you can always have one dependent on the other.

Tidal is also helpful because, once you set a schedule, you can keep an eye on it. You can kind of have "bookmarks" where it can tell you when this step is done and that step is finished, and you know that the schedule is moving forward and nothing has been stopped yet.

We've had some quirky stuff happen on an occasional basis where a job does not take off. For example, a job we expected to be finished by 3:00 a.m. is sitting there and not executing when we come in in the morning. We have to go all the way back to the dependencies and then we can see that one of the dependencies has become unscheduled, for some reason. No changes were made to the schedule but this prerequisite job has, all of a sudden, become unscheduled. I have brought this up with Tidal's support but they have never had an answer for it. It would be helpful to be notified ahead of time when something is going to stop the schedule, even if we don't necessarily know what's causing it.

But the main area for improvement is reporting. A lot of our managers would like to have metrics shown in graphs for the products they keep track of. The reporting part of Tidal isn't very useful. When you use the report function, you can't bring that data into an Excel spreadsheet. I understand in the new release they have something called Explorer which is a new reporting feature. I think they acquired a product to handle reporting functions, but we haven't gotten it yet.

We've been using Tidal since 2011.

Tidal has been pretty stable. We've had these little quirks, but they are mostly just minor bugs that crop up every once in a while. For instance, you might have to click on something twice or click off of something, like a tab, and then click back on it and it will bring up the screen. But other than that, it's been pretty stable.

The scalability is pretty good. We've used Tidal only for our main application which is our health and welfare system. We do a lot of reports and off of that, but we don't use it in any other areas. 

We've never scaled it extensively across too many different platforms. The only thing we have right now is a SQL Server platform and an Oracle Database that we go against. We're only in one location.

I don't see us expanding our use of it for now. We're pretty stable.

I haven't really dealt with Tidal support too much. The only time I really dealt with tech support is when we were doing an upgrade to a new release, to find out what release we need to have the agents in and was it compatible with other releases of SQL Server. The Tidal database, itself, is on a SQL Server release — I think it's at 2012 right now — and it can go up to 2016, but other applications are at different SQL Server levels. We had to check with them to see if it was all compatible.

They were very good in responding.

We had two mainframes running all of our applications. We were using CA products. Our health application was ClaimFacts, from TriZetto, but they were dropping support for the mainframe product and everybody had to switch to Facets. We were running both products at the same time while we were transitioning to Facets. We had to run ClaimFacts, the mainframe version, for about a year or so because, if somebody has a claim they have a year to report that claim and another six months to make adjustments on their claim. So our old mainframe product had to be kept until all that faded away. 

Then everything went into PC, server-oriented applications. We got Tidal because the company, TriZetto, used Tidal to run their stuff. So we brought it in and we started setting up our whole batch schedule.

I wasn't privy to the technical part of the initial setup, but I think it was pretty straightforward. We just needed to know where to place the agents so that they could connect, and we had to do a file share so that if you're doing a DOS command and a Tidal job, it will have shareability to whatever servers they're going to. Once those were all set up it was pretty stable.

Our deployment took about a month. But we were using the product for the first time. So we were setting up jobs for the first time. Some things were kept out of Tidal until they were ready to be moved in. They were run by developers or the application people, manually. It took about six to eight months to get everything on Tidal. There are so many icons and buttons and things that they had to press on to run something on a desktop and we had to convert that all into executable commands for Tidal in the schedule.

That approach was planned. The initial plan was to get the batch processing of claims in first. That was pretty smooth. There were hiccups every now and then but it was not that bad. While that was going on, all the in-house stuff was done in the periphery on a person's desktop. Those things were set up afterward.

The learning curve is at least one to two weeks, if you teach a person, full-time, how to run the schedule and how to set everything up. It depends on what knowledge they need to have to run a schedule. If it was just a matter of running jobs, it would take less than a week. But if they're constantly being asked questions on what this or that job does, it will take a person longer to get a feel for what all the applications do.

I came from a programming background when I started running these jobs and setting up the schedule, so I had a fairly extensive knowledge of what all the applications do. But you take a person who is just out of the computer room and all he knows is how to do a Computer Associates schedule, he knows the timelines and the flow of everything, but he doesn't know exactly what the applications do. They would need at least a few days to find out what are the major applications or major steps in a daily job schedule are. If some of those steps are very critical to run, they would need to be pointed out so they know which are critical and which ones can be held or bypassed. It takes time to get used to the processing.

We used a Cisco consultant for installation. There were four people involved in the installation. We had the consultant working with our network people, and we had a technical support person who made sure all the libraries were in place to set up for Tidal. And there was me and another person getting all the schedules together.

The only time we've used a third-party is when we were doing a major upgrade of Tidal from 3.1 to 5.2, back in 2015.

The third-party we used was Synertech. Our experience wasn't too good with the consultant they gave us. He was very gruff and it wasn't a pleasant experience. We didn't ask him to come back. But the actual conversion to the new release went well. We used the consultant to show us the technical part of upgrading to 5.2. We also wanted to use him to train one of our new people in Tidal functions, but it never got that far.

I'm not in the financial end, so I don't know what our licensing costs are.

I know that Tidal integrates with a product called JAWS Workload Analytics, which will analyze your schedule, give you graphics and reports, tell you where your logjams are, and analyze all the data going in and out. We asked what the price is on that and it was about $200,000.

There was one option back then, but by the time they wanted to come in for a demo, we had already decided to use Tidal.

The biggest advice I can give is to test Tidal first. Run the whole schedule, whatever you're putting in. Run everything you can and test Tidal before you bring it over to production.

The trickiest thing to do is to change a schedule during the day. Once you associate a job with the calendar, and then somebody comes by and says, "Hey, I want to put these six steps in, and we need to run that today," if you try to change that schedule during the day, you don't realize that, because you put it on the calendar, it's on a schedule. You could be making changes and kicking off things inadvertently. You can't change something during the day without like stopping the scheduler or putting it on pause. We might have done that once in all these years — pause the whole scheduler or pause job launching and then make a change and then turn it back on.

You may think that you can change something during the day and let it go, but then you realize, "Oh, this thing took off." And you realize that because you put that job on the schedule, it picked up the scheduling requirements it inherited from another group of jobs and it will take off on you. That's probably the trickiest part of the learning curve.

When we brought Tidal in there were six people who were taught how to use it but five of them have retired. I'm the last one. About three years ago I had to train another person who came from the mainframe computer room after he took the job as a Tidal scheduler. I got him up to speed. The two of us run the schedule during the day. There are no other users. There are a few application programmers or developers who just want to have Tidal available so they can see what's going on, and we give them inquiry access. But nobody else has any authority to change anything or to set up anything.

Overall, it does what it's supposed to do.

I always get into arguments with the management staff here. They always claim something happened in Tidal and I say that Tidal doesn't process anything. It's a scheduler and it just launches jobs on the servers. If there's a system hung up somewhere, it's not Tidal. Stop. It is the actual program. Whatever processing has been launched by Tidal is the issue, not Tidal itself. I finally convinced them of that. Just because Tidal launched something doesn't mean it has touched anything or changed any data. It just goes to a server and launches a process. A person with the right authority can do the same thing from their desktop.

We are mainly using it for triggering data jobs. It does a lot of ITIL stuff and data movement from systems into Hadoop. We use it because it has the capability of dependency triggering or dependency running. That's the main idea behind it. Also, it helps us to centralize and organize jobs across the organization.

We use Tidal to run Hadoop backup system, SAP HANA, and SAP BusinessObjects. We also trigger a lot of jobs into SnapLogic, Salesforce, ServiceNow, Workday, and Tableau, along with a couple of dashboards. We run a couple of batches from our Unix and Windows machines: the stuff that the developers are working on and want to run in ITIL. But, SAP is the main thing.

The main goal is to use Tidal for managing and monitoring cross-platform, cross-application workloads. The ability to manage those loads is what they do well. I can put a job to run in SAP, and once the job ends successfully, I can run that job in Hadoop. Or, I can run that job in Salesforce.

Tidal enables admins and users to see the information relevant to them. We have something like 50 different teams working on our Tidal platform. We segregate between them using work groups. When a user logs into Tidal, they only see what they have permission for, not other projects. Data engineers are the users of this solution.

A user who comes into Tidal, develops his job, and creates their job in Tidal, then triggers the job or sets up a schedule. An admin is someone who keeps the lights on, making sure the platform is up and running. They maintain the solution and configure it, doing upgrades.

If I just want to monitor my job, that is something that the solution does really well because there is some constant job activity that you can login and see what has happened every day and every minute. That is pretty good. An admin can drill down to processes and data, but I don't think they are doing that.

The solution has helped to eliminate weekend hours. In the past, we had to schedule a job every Saturday. Then, someone had to login and run the job. Now, Tidal has the capability of event-driven jobs. For example, if a job is failing, we can do something. Or, if a job is completed abnormally, we can rerun the job. So, all of these features that they offer help us not to come into the office on a Saturday. We don't need to have a human person do those weekend activities and treat them. They also thought a lot of about outages in the product. You can set up an outage to an adapter or connection, to say, "Between these hours on the weekend, I don't want to trigger any jobs." That works very well.

The job dependency is something that you cannot have in a regular, simple cron job or simple scheduler dependency. The event-driven jobs are core for us, as we really need that. Therefore, we really need Tidal with its ability to run thousands of jobs per day.

We started to deploy Azure, and it's still not fully baked. We are struggling with it. It is not something that has worked out-of-the-box. We haven't installed Tidal in the public or private cloud. We have a problem with security. While we can install the entire platform in the cloud to handle separate work or an entity, if we want to centralize it, then it's a little difficult.

They don't have good reporting capabilities. From the user perspective, I have 6,000 jobs running per day, and I would like to track them to know exactly what is going on. E.g. if a manager asks me, "Can you bring me this data or can you do a dashboard or report?" I need to take a lot of actions in order to do that. It's not easy to compute that data.

We are now testing version 6.5. The speed of this console is much better than 6.2, where the speed has not been sufficient for me. 

Most of my users are doing customer service review these days. So, we are asking the customers what they think about Tidal and what the vendor needs to improve. The number one that we are exploring is the user experience (UX). It has a lot of features, which is one thing that is great. On the other hand, the user experience is a bit old. It is hard to find what you're looking for. The UX is not intuitive for all users. So, if I'm a user, it might take me some time to know where I need to find my stuff.

It takes a lot of time to learn the product. I have admins and developers who are working on the products for the last three to four years and still don't know all the functionalities. Tidal has really great things about it, but people are focused on their day-to-day job and the solution is not intuitive.

We have internal training where we do two weeks of training for three hours each day. So it's approximately 30 hours of training. I cannot say after that users know everything. It takes about six months to ramp up on Tidal to be really good and professional.

I have been using it for the last three years.

In version 6.5, it is very stable and works quickly. The UI works quickly too. Their services load pretty fast. If one of the servers reboot, they have a layout of the high availability. This means that from each component of the product you have two items. If one of them goes down, then the other one kicks in and starts to work. I really like that idea.

In terms of room for improvement, if one of the master goes down, then another one takes a minute to start. While it is not a big deal, when you commit on four nines, one minute is huge. So, I'm pushing the vendor all the time to be better on this.

They still haven't implemented the load balancing-oriented thinking. So, if I have two client managers, I cannot put them behind a load balancer. Or, I can put them there, but the load balancer will never have a health check. That is something that everyone is doing, building health checks, and they don't have health checks on clients for load balancing. Maybe this will come in the future. I submitted a request for having a health check for load balancers.

In version 6.2, they had a lot of problems. One of the problems is the Oracle support. We are using Oracle RAC and high availability on Oracle. If one of the databases would suddenly goes down, the entire system would crash. In version 6.5, we have tested this. They have done significant work and it's working perfectly. It's not crashing and working continuously without any issues. From this perspective, I am very happy with the new version.

If you have enough memory, it is scalable. We are running 20,000 jobs. We just increased our memory. It scales really well. 

The North American technical support is very good. They go the extra mile for you all the time, and we are very happy them. We have had some problem in the past with the Asian support during IST time, while it is night in the North America. However, I think it's getting better. Overall, I'm very happy.

We used local solutions, like scheduling for each platform, such as SAP Scheduler, SnapLogic scheduler, and cron jobs. We didn't have a centralized place.

I was the architect of the initial setup. The initial setup was complex; it's not easy. They have a lot of settings and configuration that need to be done. There are a lot of small things that vary from environment to environment, and they fail to consider every situation. 

The deployment takes a couple of days.

With our first environment, we tested it in a sandbox. I let my admin play with it to see how it behaved and what are the downsides. Then, we created a document. While I know that they have a document for installation, every time that we go to install, we are finding new issues.

I'm behind a firewall and we are in a limited environment. Our infrastructure is built differently from what they probably tested on their environment. So, it's a bit different from what I need to install. I first put it on the sandbox to see all the issues that we are facing, document step-by-step what we did, and then I go and do it in stage. Now, stage is the place where the developer come in and develop their jobs. Once they are ready, we move the jobs into production. 

Stage is really almost production. If stage wasn't available, then the developer could not work nor deliver. We see if it works for at least three weeks. If we don't have issues during that time, then we deploy to production. 

They do a better job in version 6.5, which we are testing now.

We have seen return on investment.

BMC is really expensive. The other solutions are about the same price. I think Tidal is even cheaper than the others, such as CA, Stonebranch, and JAMS.

Our licensing model for Tidal is on an annual basis. It is very good and works well for us. Tidal's licensing is very transparent and simple. It lets you know, for the amount you use, that's the price that you pay. So, we buy X number of licenses, and we know that this is where we are. I'm very happy with that. I saw the licensing modules on other platforms, and I didn't like them. Other companies and solutions would calculate the connections, adapters, and instances. I think that's the reason that BMC was pretty expensive: They just didn't understand what our needs are.

The solution has no hidden costs. It helps me to plan forward into the future. I know that I can add another 100 or a thousand jobs, and that's how much it will cost me today.

We did evaluate other schedulers. This was the best solution.

I was not the one who selected it in the first place. I was the one who asked to evaluate a replacement at some point. There was a time when Cisco was the owner and we felt like Cisco was not delivering the product like we wanted. We sought to move to a new solution and assessed different solutions: BMC, CA, Stonebranch, and JAMS. We installed all of them, running all our tests. It took us six months to do our evaluation. Eventually, we found out that they are very similar from the infrastructure side. I could not see any advantage using the other solutions.

We discovered that we are good with Tidal and what we have. Then, a new company acquired Tidal from Cisco and they promised a lot of things to be better. We felt that the solution was going to a better place. So, we decided to wait and see how much they invest on the stability. We have been happy with the results. They are really focused on the customer and our pain. They are trying to remediate everything that we have issues with. Therefore, we decided to stay with them for now.

Don't be afraid. Just do it. You will enjoy the features of it. It is a great tool.

You need to test Tidal many times. It's not straightforward. You need to test and learn it. 

We have something that is not unique to many platforms. I have five guys who handle the platform. That's costly for us. We would like to see the platform more automated or straightforward. I would like to not need to hire so many people just to administrate and maintain the platform. 

Our capacity has increased in terms of the number of jobs and integrations, but that is a natural thing. I don't think it's related to the solution. When you start to develop jobs, then year by year the number of jobs grow because the organization is growing. 

I'm very happy with the product, but it's not a fully baked product. It requires babysitting. I have worked on other solutions and know what is there. This takes time for us to install, upgrade, and task because there are so many components to the product. If you do one little mistake, then you can screw the system.

I would rate the solution as an eight (out of 10).

Our use of Tidal is mostly file-event driven. We use it to manage our ingestion, processing, and loading of data. Tidal has a hook and it runs ETL for us. It runs jobs and SQL and some of our database appliances like IIAS, the new version of Netezza Teradata.

We have a file gateway that receives a file and drops it in a location. That file event picks it up and drops it over to the ETL tool. The ETL tool will run and aggregate a number of source files and turn it into a properly formatted input file. That file then goes through data hygiene and data analysis. Then it goes through a matching process. It is then put back out and runs an ETL process to stick it into a SQL database. And then there are a number of jobs that are run in the SQL database to manipulate that file.

We don't have a lot of calendared events or scheduled windows.

We have a central location for Tidal in our data center, and then we have client-hosted solutions where we run smaller instances of Tidal, and those are in the cloud. We use AWS, Azure, and GCP.

It reduces our administrative costs. As much as people are in a DevOps model, we can create dashboards for tier-one people to monitor multiple jobs and then alert or call when things fail. It helps us with reliability and managing SLAs.

It has also helped to reduce weekend and overtime hours due to the fact that you can have a single person manage multiple jobs. If we didn't have the single pane of glass and that visibility, people would have to manually look at logs to determine the progress of a job. So it reduces headcount. But when you run 24 by seven and 365 you still have people working weekends.

We run 70,000 Tidal jobs a day. it would take a mountain of people months to run that many jobs manually.

What we find most useful from the operations side is that it provides a single pane of glass for managing that workstream. It also alerts us on failed jobs, so it's our monitoring and management tool for those workstreams. 

Tidal helps administrators and users to see the information that is relevant to them in that single pane of glass. They can see jobs running, they can see job history, and they can see job progression. If you look at alternatives like Airflow and clouds, you'd have to design your own UI to monitor the progress of the different jobs that you've created in Airflow. So Tidal is huge for us.

Most of our stuff is private clouds. We haven't had an issue with its support for private cloud or its migration to the cloud. In our scenarios, we run the masters here and we reach out to agents that are running in the cloud. We also use it to kick off command-line utilities for loading data into BLOB storage and S3 buckets. We use the SFTP utility to move files around.

One area for improvement is the command-line interface and the API to bulk-load jobs. It's a little bit kludgy, but we still manage without it. They're working on it and it's getting better all the time. In addition, the documentation for their API for creating jobs needs to be updated. It has a bit of a learning curve.

We also wish there was a search functionality for assigning actions to events, and users to workgroups. 

Finally, the S3 data mover jobs are still a little buggy.

I've been using Tidal Workload Automation for about 14 to 15 years.

After the 6.2 release, the stability became awesome. With 6.6.1 it was a little bit difficult, but everything after that has been solid.

Scaling is easy. You could run these in VMS. We happen to have physical boxes. 

We haven't scaled it out, such as creating a remote master. In instances where we thought we may have to kick off jobs from our Maryland data center or jobs in our Denver data center, over MPLS, we thought we would have issues but we didn't have any issues. We were fine. We've been able to run things centrally.

The databases scale the way SQL scales, either by giving it more memory or more CPU.

As we have brought on clients we've grown over the years. We have a tendency to overbuy for the Client Managers. Our Client Managers are coming up on four years now. In 2021 we'll likely do a tech refresh. We'll stand it up with another version of Tidal and we'll do the migration onto the new platform. At that time we'll look at scaling up the boxes a little bit. You can put a lot more workload, a lot more Tidal jobs, on these without having to increase CPU or memory.

Their tech support is awesome. We've had Tidal for a long time. We had Tidal when it was Tidal, and then when it was purchased by Cisco. During the time that it was purchased by Cisco, support was lacking. But now that it's part of the STA, it's back to being awesome.

We were using a home-grown solution. It was a cron job manager. It didn't do file events very well; it had monitor CIS logs. It was tough to schedule tasks. It was purpose-built so it didn't have a SQL adapter. It didn't have the ability to run on Netezza and things like that.

We switched because to programmatically create the enhancements for the things that came out-of-the-box with Tidal was just too costly. It would have taken too much time.

We've retooled our environment three times since we first installed it. Our last one was easy, a piece of cake. The ones prior to that were not so good. 

When Tidal sold it to Cisco, and they had introduced the concept of a Client Manager, a type of web interface, there was a time when going from one version to another version was not good. Now that Tidal is back to the STA Group, our upgrades are much easier.

With our last upgrade, we stood up a whole other set of servers — our servers were old — as well as a database. From the time we got the servers installed, loaded Tidal, and did our initial database export, so we could do testing, it took two to three weeks. It was a piece of cake. And then we did extensive testing.

In terms of the solution's learning curve, from an operations standpoint, teaching people how to search and manage jobs, and start and stop them, put jobs on hold and kill them, we can get someone up to speed in less than a week. For developers, it's a little bit more lengthy. There have been several instances where we have a Tidal developer, a subject matter expert — we've only had one or two of them — who has been able to train multiple people and make them serviceable. We've been doing it for 14 years, so we don't use Tidal training. We've created our own training documentation to get them up to speed for how we use Tidal. We can get them up to speed very quickly. I know people who have joined the company and who are writing and creating Tidal jobs two weeks or three weeks later.

For ROI we'd have to figure out how many man-hours am we're saving with Tidal versus not having it or having one of the other automation tools. We've grown up with it. I can't imagine being without it. Back in 2016, when we looked at possibly switching over to another solution, it wasn't a clear path to migrate to any of the other tools. We literally run our whole enterprise on this, so if Tidal goes down, the world stops.

We feel we're getting a pretty good deal with Tidal. It's supporting $600 to $700 million in revenue.

The licensing model's flexibility is awesome. The way it's licensed for us is per master and then per agent. We have an enterprise agreement, so we have unlimited agents, and we have it on 500 devices.

I don't know how it could be easier to budget for Tidal, given that there are no costs for upgrades and other enhancements. There are increases over time, but unless you add functionality, such as buying other adapters, it's very easy to manage costs for maintenance and the like.

In terms of the hardware that we purchased — VMs and storage and networking, and the VMs' SQL licensing — it was a little bit below $200,000. That doesn't include licensing.

The hardware list is includes

• a SQL cluster
• a utility server that we use to migrate jobs from dev to prod
• two masters in dev
• a fault manager in both dev and prod
• three Client Managers in dev and two Client Managers in prod
• for each of those Client Managers we have a database
• 11 VMs
• 12 physical boxes.

So we've got a pretty big environment.

There have been a couple of times that we have looked at competitors, especially when we saw that Cisco wasn't really investing time or money into it. It wasn't clear to us if Cisco was going to continue to invest in Tidal. So we went out and looked at the market and did evaluations. 

We looked at Automic or UC4. We looked at BMC Control-M. Stonebranch was actually interesting, back in 2016.

What it came down to was that Automic was tough because it was changing hands on a regular basis. Stonebranch was more in our price range, but Tidal's price for the way that we use it was cheaper. When we started looking at what it would take to migrate from one to the other, there was no ROI.

The way we evaluated things was we looked at our use cases and ranked them from one to ten, and then costs. All of Automic, Stonebranch, and BMC would do what we wanted them to do. I'm sure, if we had dug a little dig deeper, we'd have found the little idiosyncrasies between them. But the cost for those and the cost of migration was just too much.

We started seeing how Cisco was propping it up a little bit more, right before they sold it to STA. And when STA bought it, they assured us that they would start making improvements. We stopped our analysis of other solutions there.

Tidal's drill-down functionality is one of those things where you get out of it what you put into it. If you program it to fire-and-forget then it doesn't have a lot of drill-down mode to it. If you put in result codes and things like that, instead of using the agent to kick off the SSRS package in SQL, or if you use the adapter, then you can drill down.

We have about 100 users using Tidal in our organization. They are anywhere from developers to operations people to administrators. There are only a couple of administrators. There's a bunch of operators because we use this to run 24/7, 365 for 20 or 30 customers. For each of them there may be a couple of operations people and a couple of developers. As for maintenance, we patch our boxes, our masters, our Client Managers, and our databases every month, and it takes one person.

We use it to call multiple source systems, such as Informatica workflows, Unix scripts, Windows scripts, PowerShell, batch files, and a few SAP web programs. We use it for certain file events and monitors. Tidal, by itself, can't monitor, but we create a script and job for that, then schedule it in Tidal. We use Tidal for multi-purposes.

We use Tidal for our SQL Server, where we call from Tidal any procedures, statements, SQLs, or jobs. We also call a few HANA Stored Procedures from it. As of today, Tidal doesn't have an adapter, but we have some internal scripts which call Stored Procedures from Tidal.

We run around 2000 to 3000 jobs per day.

The infrastructure is in Azure.

Tidal enables the administrators and users to see the information that is relevant to them. 

We do have a logs tab that we go through. The errors point us in the right direction where we need to troubleshoot our issues. Depending on the issue, remediation does not take too long. 

With the varied features in the varied adapters provided, we use Tidal Enterprise Scheduler because we want everything to be scheduled in one place. Tidal provides that for us with its tools and varying platforms in our organization. Tidal provides all the connectors to the platforms. This is very useful because we don't want to look for another scheduler for scheduling certain jobs. We don't want to look at those schedules manually between platforms. With Tidal, we just need to maintain the dependency, ensure the job is on the platform, and make sure the predecessor runs. We just set this in Tidal and forget about it.

Sometimes, it does reduce overtime hours. It's not a full-blown automation tool, but we usually set up monitoring. In the olden days, people used to do this with shadow scripts, cron jobs, etc. Now, we are using Tidal and have a call-in mechanism that is triggered from it. So, we do use Tidal for certain automations.

Tidal's most valuable feature is the ones for adapters, like the Informatica and SQL Server adapters. They have managed adapters for most platforms. We can have integrations running on multiple platforms. That is a valuable feature that Tidal provides compared to other schedulers. That's what's beneficial for us is that it calls jobs, programs on SAP, and processes on Informatica, Windows Box, and SQL Server. Tidal has expanded the platforms that it can support. 

Tidal provides usable information from the logs, its user interface, and Client Manager.

The HANA adapter is not available today. If I need to call a procedure in HANA right now, I don't think Tidal has any adapters. I know that we do not have a ServiceNow adapter either, but I believe they will be coming out with a new release.

With the client, we have had certain issues. The user interface for Tidal is a little slow. A lot of people would love this tool if they had a faster user interface. The drill-down functionality should be much quicker than what it is pulling out now. If I fill out some data, then it takes awhile to get that data back onto the screen. It's not as fast as we were expecting. 

I would like to see improvement in terms of performance, meaning that it triggers jobs at the right time. If Tidal improves their performance with the client, that will be really useful for people who are developers and doing call/production support of jobs. 

We are looking for a cloud offering from STA Group. We keep hearing from STA Group that this is in discussion on their end. We are also looking at SaaS offering that other customers are using.

Seven years.

It is stable. We don't have any issues with the Enterprise Scheduler. It never goes down.

Very few people are required to maintain and administer Tidal because it is very stable. Right now, we need people to administer it when migrating stuff within Tidal because that need to be done manually. We are a team of four because we are spread across multiple geographic locations, but we do other stuff too. E.g., while I am a Tidal Administrator, we do support other platforms.

There are close to 10 other teams using Tidal, and I'm not sure how extensively they are using it as of now. People login to Tidal when they need to check the status of their jobs. When it comes to developers, there are close to 20 users. We do have business folks who use Tidal when they just want to monitor or operate their jobs.

We are still expanding day by day. We do get requests to create new jobs, and the developers will take care of those. We receive those requests once in a while. We are still expanding but it will not be a drastic increase.

Very few issues take long to remediate and we create support cases for those issues. 

The technical support used to be somewhat bad when we were with Cisco. We used to get slow responses. It is better now with the responses we are getting from STA Group. I would like to see more in term of STA support. If they could provide a knowledge base to the customers, that would be really useful. Most other vendors have their own knowledge base. E.g., if you have an issue for a certain customer, they will place that solution in the knowledge base so a new case won't be created for them. Instead customers can go look at their knowledge base to determine if this issue happened before. They can search for it in the knowledge base. If it is available, they will try to implement the solution. If not, they will create a case to the support team.

If STA can have a knowledge base, that would be useful to a lot of customers because most issues are probably repeated across multiple customers and organizations, not just our organization. We might be using the same version, but the same issue can occur with the same version anywhere. So instead of us creating cases and waiting for them, if their technical support resolved an issue on this particular version and the resolution is already available to look at, that will be useful.

Tidal switched hands from Cisco to STA Group. I have been taking the quarterly seminars or webinars from STA Group. We are looking forward to the new version that they will make available sometime in Q1, probably in February or March. We are looking forward to that because STA Group is already aware that a lot of customers had complaints that the client is responding slowly. So, they are aware of that and made some big changes. We are waiting for that new release to see how it will behave. It is good that the solution changed hand since Cisco is a big giant. Tidal was just one part of their business. Now, STA Group has dedicated teams who are working on developing this tool, adding new features, etc. 

We do not use Tidal support for private or public clouds.

This is my first scheduler. I used to send jobs to the Control-M team, but that was with my previous organization.

When I started working for my current organization, Tidal was already available. My team was supposed to support Tidal too.

I was not here for the initial setup. We have been partners with Tidal for a long time, close to 10 years.

I was part of multiple upgrades we did within our organization that were fairly simple. 

For an upgrade, we go to the support site and get the documentation. That documentation is useful. We do not need to go back to the support team asking for more details, as we usually get valid documentation. We just need to follow their steps. Following the steps will take around 30 minutes, then we wont release it to other employees without doing our own validations. Overall, the upgrade takes an hour.

The implementation is straightforward. It is whatever is provided in the documentation. They do provide two ways to do it. So, we choose one way to do it. We copy whatever files are required manually because we want to make sure of what we are copying. We want to make sure we have all the backups available before we do stuff.

Before implementation, it is better to get with the Tidal support guys. They usually assess the organization's features that they want to use. They will provide the specs to use based upon how many jobs needed to configure. So, it is better to work with support, because if they provide certain specs, then it is always better to go with the specs they provided.

We had this issue when we were doing some upgrades. Moving our infrastructure from one place to another because we thought we could reduce. Then, we had issues. So, it is better to go with whatever specs are provided by the vendor.

The time that it saves my staff is not huge, maybe four hours a week.

It has helped our organization by having one scheduler, instead of multiple schedulers, and having resources to support dependencies. It saves both monetary resources as well as fiscal resources. We don't want people to look at the screens on multiple platforms, and say, "Okay, this job is done. Go trigger another job."

The TCO is okay, but not out-of-the-box.

Right now, we are in a good position with the licensing model that we have with the Tidal vendor. So, we won't have any issues. even if we double in our current production. Initially, Tidal provided us some specs where if you have these number of jobs, then you come under this category. They usually provide a range of jobs from 2,000 to 10,000. You can use these specs for your infrastructure. Whether you have 2,000 or 8,000 jobs, Tidal should support it.

This solution is a bit expensive in the current world where everybody is trying to cut down on certain things. 

Transparency regarding cost is okay. There were few changes that happen because of the move from Cisco to STA Group when we renewed our contract.

Our platforms do have dependencies, but not in a single job. We do have two different jobs dependent on each other, but one may run on Windows while the other run may on Unix software or our SQL server. The jobs will not communicate, except one is dependent on one another, not internal data.

They are increasing capacity. However, we probably are not using it because we don't have a requirement, and sometimes it's expensive.

The learning curve is easy. I don't think it's complex. I never heard back from my developers that it is complex. They always complain about the performance of the client. Other than that, they usually say the documentation or help available is fairly useful for them.

The training needed is minimal because Tidal is straightforward. It takes a couple days of training. Of course, with any new tool, you need to read certain documentation. Anybody who is doing the training can't provide every detail of that particular tool, but people can get the feel of the tool pretty quickly.

The best thing with Tidal is its ability to support multiple platforms.

I would rate the product as an eight (out of 10).

We use it to manage our batch processing. For us, it came in as a replacement for a lot of different systems running crontab. In our case it's primarily for Unix/Linux systems that don't have their own mechanism for kicking off all these batch processes. It's the coordinator of all of our background processes and batch jobs that are running overnight and during the day.

We use it to kick off custom Unix/Linux scripts that will launch our application processes. It's almost entirely Windows and Linux shell scripts that it's kicking off.

For administrators, the alerting has been a big plus, in addition to having a place to go and look at the status. They can be notified when there's something happening in a schedule, like things are falling behind schedule, or something unexpectedly fails. It definitely helps speed up the time to jump in and address an issue and get things back on track.

It has also given us a framework for standardizing a lot of our processes. Before we had all these things in Tidal, there were so many custom services and applications written. Tidal has given us a way to say, "Here's a standard way for you to get your jobs scheduled and automated." It hasn't necessarily enforced it, but it has given people an opportunity to say, "Oh, if I use the tool and if I set up my jobs to be able to run in the scheduler, it will be that much easier for me to get this delivered to production, or to test it and validate it." It has helped us put a framework around how developers are going to get their application code deployed. It's not really pushing the code, but it has encouraged some consistency in how they design their processes.

It would be really hard to quantify how much staff time it has saved, but for sure, before that initial move into the solution, some things would take forever. It was just complete spaghetti going through dozens of boxes with different crontabs trying to figure out: "Okay, I had an incident in the middle of the night. What ran, what didn't run? What ran but didn't complete successfully?" and those kinds of things. Tidal has resulted in a huge gain there. I don't think there's any way I could quantify how much it's simplified those outage scenarios. 

And even a planned maintenance was just as hard as an outage before we had Tidal. Now, with a scheduler, we can schedule a big maintenance that's going to require a lot of people to be on hand, one where time is of the essence. The more efficiently we can adjust a schedule for an off-hours maintenance and essentially disrupt what our typical schedule is, the more it helps us with those maintenance procedures. We know in advance that we have the capability to move jobs earlier and to move jobs later so that they're outside of the maintenance window and that we're not going to conflict with anything. When we're done with our maintenance, we're able to just press a button and let everything run and go.

Tidal has definitely reduced weekend and overtime hours. In our environment, there's no way to eliminate those hours, but that's nothing to do with Tidal. That's our own design. 

Our team does the majority of the work with the scheduler. It gives us the ability to do a lot of the scheduling tasks pretty quickly, so that the developers or business folks who are making requests don't need to deal with it. It gives us the leverage to make what they feel is a bigger change to the schedule, and to knock it out really quickly. They don't have to code something or make changes to handle it. We can do a lot of those adjustments from the scheduler itself.

The solution has enabled us to do more in terms of job capacity because, in the past, we had all these different crontabs running around out there. There was really no good way for people to condense jobs together, as soon as the previous one finished, unless they customized every process flow or job flow into a script. Doing so was essentially a custom program or process that they'd have to create for each one, and that's pretty difficult to manage. With the scheduler, we can squeeze those jobs together with their native process runtimes and say, "Okay, we're going to run through steps 1 to 10, allow those things to run in a sequence, and get them done in the shortest window possible. It has definitely helped with that.

Our environment is really different now compared to what it was when we started with Tidal all those years ago, but there's really no way we could have sustained that old model without having the functionality that's in the scheduler get our schedule done quickly. As our company has grown, it's been difficult for us to find maintenance windows or quiet periods. Every minute that we can save reduces the time an overnight batch process impacts daytime business users. The quicker we can get things completed, the better it is for the user experience and our environment.

The first, big thing that we got out of using Tidal Workload Automation was having a centralized view of the status of all of our batch processes across all these systems. We're not a big environment compared to some of their customers, but these are all business-critical processes that we're running and there are at least 100 different systems in our environment. To manage all these processes, it gives us a single point of view. We can look into the schedule at any given time and see if things are running on track or if they are falling behind. We can also see if something failed. The big thing is having that visibility into everything.

We use it for cross-platform and cross-application workloads, although they're not that different from each other. A lot of our workloads are similar, but they're technically different platforms and applications. We have some different OS's, but they're all Unix or Linux systems that are running the same sort of back-end technology. In our world, internally, they're different platforms. It gives us a really simple view into everything that's happening. 

I've been using it for a long time, so to me, it's a pretty intuitive way to, at a glance, look at how things are progressing in the day for the batch schedule. I don't know if that would necessarily be the case for a new user. To me it's intuitive and that is what helped us choose it over some other scheduling technologies in the past. It seemed like the most intuitive way to look at a lot of different batch processes running on lots of different systems.

As far as its ability to allow admins and users to see the information relevant to them, the interface is good, once you have access to it. We have had a little bit of an issue with some browser compatibility, but other than that, it's been a good tool for people to come in and look at where is their process is at from a business point of view. They do have to have a little bit of familiarity with what it is that they're looking for, the programs in the back-end. This is nothing to do with Tidal, but our technology environment is a bit hard to digest early on. Things can be a little bit difficult to navigate in our technology stack, at times. Tidal helps those users who are new to it to get a view of: "Here's the thing that I'm interested in. I know the program name, but I don't know when it runs, or how long it takes." Without having to get into the back-end of our technology, it does give them a way to look at what's happening in the schedule.

Their software installation and update process could use some improvements. I'm pretty sure they're working on that, but that's definitely an area where it could be streamlined a lot. There's still a lot of manual work that you have to do with the schedule when you deploy masters or do the agents. 

The other thing is that the performance of the web interface has not been great. It's feedback I get quite a bit, that the web interface can be sluggish at times. We've got to recycle it to get it to be more responsive. We brought up this issue a while ago. A lot of what we may be dealing with is that we are running on an older version. A lot of the performance stuff, I suspect, has been corrected in the later versions. We are running on 6.2.1 but they have got 6.3.5 out there now.

As for stuff we'd like to have, I'd love to see the database back-end have PostgreSQL or MySQL. Right now the choices are Microsoft SQL Server or Oracle.

I've used Tidal Workload Automation for about 15 years.

It's been rock solid for us. We've had it for 15 years and I have really never had to make support calls to either Cisco or Tidal. The only times I ever really have to contact them are when we do our renewals or we migrate to a new version and we have to get a different license key.

I don't think we've ever pushed a limit of the schedulers, the masters. We haven't really had any kind of scalability issue with regard to the scheduler or the agents. The only thing that we've run into as far as scalability goes would maybe be the web interface, which can get pretty slow at times, so we've got to cycle it. The web client is just sluggish and has an issue where that performance degrades over time. That's why we do the recycle and we notice it helps quite a bit to recover it.

I really don't have to make support calls almost ever.

I'll ask a question sometimes, and they've been great. They've been very responsive. I haven't even had to do that for quite a while now. We set up our current implementation when they were still with Cisco. 

It was a little bit difficult with Cisco to get to the Tidal software engineers who are now their own entity. It's definitely gotten a lot better now that they're not part of Cisco. I can just call in. They know who I am and what I'm asking for right off the bat. When it was with Cisco, there was a whole triage system you had to get through, and a lot of people at Cisco didn't even know what the product was or that it existed.

We only had crontab on a bunch of Unix systems. We looked into Tidal because we were having so many missed processes. Our environment is so much bigger and more complicated now compared to 15 years ago. But even back then it was almost like having things in crontab made it easier for there to be issues because they were all arbitrarily set to run at different times, different users, different systems. If there was some sort of conflict or collision, there was really no way to even regulate the fact that there were too many processes running at given time. 

It actually helped prevent some issues then, and now we have so many things cranking through Tidal. Getting all this to work in crontab would be impossible.

Installing is not terribly complex. I don't have experience with other scheduler products, so I can't compare it to them, but it does have more manual install steps than some other software in general. For instance, there isn't an RPM installer. We use a lot of Red Hat in our environment. We can use RPMs for our Unix platforms and our Linux platforms. It would be nice if it was just packaged like that, so you could run the install or do the configure, perhaps with a few prompts. It's not far from that. It does have a shell script that runs, which isn't too different. But it would be nice to run updates for our scheduler along with all the other OS updates that we do in our environment.

If you know what you are doing, you can really get through the deployment, easily, in under an hour. I don't even know if it would take that long. If you have access to create your database and you already have your OS environment provision, the install and setup is really not very time-consuming. There are just the few manual steps you need to do, here and there, to configure it. But it's definitely doable in an hour. 

Assuming someone has access to do each of the steps that they need to do, one person could definitely do the install. I've done it in a VM lab and definitely knocked it out in under an hour. As long as you can create your database, create your database users, and run the software install, it's definitely a one-person job.

In terms of an implementation strategy, we've really stuck with one model. There's not a lot of leeway there. Essentially, you are going to have three master servers, a client manager, and you're going to have a database somewhere. The only difference might be the choice of operating systems or whether you're going to run on a VM or a physical server. But that's pretty removed from Tidal itself. There isn't a whole lot of variation there.

When it comes to a learning curve for Tidal, I've been using it a long time, so it's pretty intuitive to me. New users need to get their bearings and to know how they can filter, and what they need to filter on to answer the questions they have. It takes them two or three times of logging in and working with it. Sometimes we provide some guidance on best practices to find their program. It can be a bit overwhelming. I don't think Tidal necessarily makes it hard, but it's just the nature of all these processes running and the things that are there. Tidal helps with it, but it doesn't keep it from being a complicated thing to try and follow and to try to understand.

Tidal Workload Automation is a no-brainer for us, given the importance of the processes that we have. The cost for coordinating, managing, and getting all these things to complete, while warning us when things are not running on time, to me, makes it a no-brainer. 

I do not know how to quantify our ROI. We get everything that we pay for in the product, and there are even features that we do not use.

Another advantage of Tidal is that it is a pretty affordable scheduler tool that lets us do a lot. You get a lot of bang for the buck. It has always seemed pretty reasonable to me.

The licensing model is hugely flexible. In fact, sometimes we get a little bit lost on which model should we go with. Over time, it has adjusted and changed. But the current model that we have is to run with enterprise license agreements. We do not have to worry about how many agents we add and remove. That has been the easiest for us.

They have options to do one-, two-, or three-year renewals. You can space out your renewals or do things like an enterprise license agreement. You can dial into, "Hey, I just want to run this many hosts." They cover a lot of options for you. It may not make sense for a smaller shop to run an enterprise agreement. They might just want to run five agents. In their case, having that option is huge.

Given that there are no costs for upgrades and other enhancements, it is really easy to budget for Tidal. We have not had any issues.

When we did the initial implementation, we did a full product comparison. We looked at the top four and did a comparison of the features of what seemed like the best products at the time. Over the years, I've reached out to other vendors just to get an idea of what other features are out there in the product space. We have never really found anything that had a compelling advantage over Tidal Workload Automation that made us want to switch. It has been really stable and has definitely gotten the work done for us.

We looked at CA's AutoSys at the time, but CA has so many schedulers now that it's hard to say exactly which one that is today. IBM had Tivoli Workload Scheduler, at the time. Since then, we have had someone from ISC reach out a fair amount. We looked a little bit at Control-M from BMC Software as well. JAMS was another one that popped up.

Tidal is familiar. We know how it works and what it is doing. It also keeps a fair amount of accessibility about it. One person could sit down, deploy it, do the install, get it up and running, and then it is just a matter of setting up the agents and the workload. I have not looked at the other products in so long now that it is not even relevant today, but BMC and a couple of other schedulers were overly complex, or their user interface just was not intuitive enough for our users.

The big thing I would say to someone who is deploying this new, aside from having a naming standard and the structure, would be to get their security groups right, up-front. That is a pretty big one. Set your owners and who your users are going to be. Think about how you are going to structure it from a user point of view.

We have two core systems here. One is for our loan origination system and the other is for allocating leads and directing leads, and they both rely on Tidal heavily. If the scheduler were to shut down for some reason and we couldn't run it, it would have a huge impact on our business. Thankfully, that's not a scenario that we encounter, but we really rely on it to drive so many of these business processes. In terms of increasing our usage of it, other business areas have started take some interest in it, but we haven't made a dedicated effort to get, for example, our SQL Server systems to be managed by the scheduler, or to do things with Amazon. We haven't really had anyone driving that effort.

In our environment, one person, me, maintains the Tidal software. That's more an organizational question of how many people do you want to have who are capable of supporting it. We have a team of six people, all systems engineers. They're not all as up-to-speed on it as I am, but if I gave them my notes for doing the install, I'm sure they could all do it.

The number of users of Tidal, in our organization, depends on the definition of "users." It touches things that impact every user in our organization. But with respect to users of the interface who log in and use it, it's only about a dozen people. Aside from the system engineers, the next biggest users would be developers or program engineers. They are people who are involved in researching updating a task to a procedure or process and they want to know what the scheduled processes are and when they run. They are also looking at what their rules are for running and how long it takes. Sometimes business analysts will be involved in that as well.

Tidal is a nine out of 10. I would say it's a 10 if we didn't have some performance struggles with the web interface.

We use it primarily to run SAP jobs. 

While there is other minor stuff it runs in, 98 percent is SAP. We have a number of different types of SAP systems. There are different teams who are responsible for configuring, managing, and setting up jobs. They are the ones who define the jobs and schedule them. There is an administrative team who is responsible for maintaining the system landscape and providing training for Tidal. They also provide standards, guidance, guidelines, and jobs.

We use the solution for cross-platform, cross-application workloads within SAP. Therefore, within SAP, we might run a job on one system, but wait for the job on other systems to finish first. That is our interdependency between SAP systems. However, we don't do things like run something on SAP, then go do something on a non-SAP system. We may have a bit of that, but that's not a big part of what we do. It's mostly within SAP systems or within an SAP system.

As far as investigating what ran and when, it is fine for the most part. You can investigate on the GUI and take a look at different things. 

We've been using it for 15 years so we clearly like the product. We wouldn't be able to do many of the complex scheduling that we do today without it. For us, it is a mission-critical app. Because if it doesn't work or has a problem, then SAP doesn't function. It is that critical. So, it's an essential tool for us to manage and run SAP jobs. We depend on Tidal. Without it, we wouldn't be able to function. 

A lot of stuff is automated. You don't need people running things on their own. They can schedule and run it, then not having to worry about it. They can even get alerts if there is a problem. People are just coming into the mix only if there is a problem. They get alerted to see what happened. From the automated aspect of it, you can run jobs based on a schedule, events, or whatever reduces manual intervention.

It just makes our life that much easier because all we have to do is define complex jobs, then they are pretty much on their own. We only intervene if there is a problem. Otherwise, people don't even know it is there unless there is a problem.

We run a very large number of jobs per day. At the end of month, in particular, we can easily build jobs and dependencies, expanding on what we do. It's not so much a factor of what Tidal can do, it's more a factor of what SAP can do. You can easily expand what you do with Tidal, but then you need to be sure that you can do it right in SAP. E.g., what happens after we started seeing SAP to do it? From a Tidal perspective, it is pretty easy now because we have had it for so long and have so much experience with it. It has helped quite a bit in terms of increasing capacity.

We are constantly adding jobs, though not a ton. Sometimes, we take some away, but that's rare. It's more that we add jobs. It simplifies the process of developing an application if I have Tidal because I can around things and automate things easily with Tidal. The solution is very important to us because it does a lot for us 24/7/365.

We use quite a few of the features:

• Calendaring 
• Complex dependencies
• Intra-system and inter-system dependencies, respectively, within a system and within systems.

There are a whole host of features that allow us to fairly complex scheduling which wouldn't be possible otherwise.

Tidal enables admins and users to see the information relevant to them for the most part. It depends on what you are looking at. One of the weaknesses of the product is, when something happens, it's difficult to find out the root cause. There are a lot of logs you can take a look at in Tidal. Sometimes, they are useful, but other times, they're not. That is mostly relegated to the administrative team. Users for the most part don't see that and don't know anything about that. They just know they have a problem, then it's up to the administrative team to see what happened and figure out the problem.

When you need to drill further down to the lower level, that's when it becomes a bit more difficult. At the lower levels, it tends to be clearer. When you get into the guts of the app (the technical level), it is sometimes difficult to find out the root cause.

Tidal comes with two front-ends (GUIs): their Java client and web client. The Java client is a very lightweight client which you install on your desktop and terminal server. The web client just runs on the browser. They are slightly different, and what we are finding is sometimes there are discrepancies and inconsistencies between the two. One function may work in the Java client but may not work in the web client. That is because they have two sets of code with different front-ends, so they are inconsistent. I have asked if they can just use one of them. We prefer the web client because it doesn't require any installs on your desktop. However, we also like the Java client because the usability and look and feel are better on the Java client than the web client. 

We have been using this solution for a number of years, using both front-ends. Sometimes, we see it as an advantage if there's a problem with the web client to go use the Java client. So, you have two ways of getting in. Although it's a pain sometimes, because you when you have an issue you need to check both and they may behave differently. On the other hand, when you have a problem, there is a different way to get in and you are glad that you have two ways to get into it rather than just one. 

15 years.

The stability has been good. We have had the occasional issue here and there, but overall, it has been fine. Obviously, it hasn't been flawless. For the most part, it's been a pretty stable environment.

There is an administrative team at the app layer maintaining it. There is a senior administrator for it, and two other people who cover for the senior administrator, if necessary. At the Unix and database level, there is just one person maintaining it.

You can scale. Today, you can easily scale Client Manager, which controls access to the web client. I sometimes complain about this to Tidal. For example, you can add one or two to the HA, which has a master backup. However, the only way you can scale there is vertically. So, you can make the system bigger. But with the Client Manager, you can scale horizontally as much as you like depending on the volume of people that you have, though I usually find that for us one Client Manager works just fine. The reason we have it down to just one Client Manager is because they use the Java clients, so there are different ways of getting to the system. It would be a good idea to have a second Client Manager in place so you have HA if the Client Manager goes down, then you could just go to the other one.

We haven't really had an enormous increase of jobs that has caused us to scale drastically, short of increasing memory. The CPU has not been an issue at all.

We did expand it to non-SAP, but it's not huge yet. It is being expanded to things like running Windows and Unix jobs. There are a good number of jobs that it runs from a volume perspective, but not as much as SAP.

Most people use the web client. There are 40 to 50 active users in the system. What we call super users use the Java client, so there are five to 10 people now using the Java client with the rest of the people using the web client. 

We have three different types of users: 

1. We have the administrative team. Those are the people who maintain the system, do the training, and set up different components of the application layer, such as user groups or server groups. This is more on the technical side. 
2. The super users usually are the most knowledgeable and capable of using some of the more complex features of the product. 
3. The regular users are the people who set up regular, simple, straightforward jobs with some dependencies. They maybe set up some calendars, but nothing overly complicated.

The technical support hasn't been perfect. Sometimes, it takes a bit of time to come to the root cause of an issue. They are pretty responsive though. 

They have been pretty responsive of late since the company changed. You see the difference compared to Cisco. In general, they have been doing a much better job, especially communicating with customers.

We were using SAP native schedule, which was fairly primitive.

We are running it in version 6.2 and thinking of upgrading to version 6.5. We just recently installed version 6.5 in the sandbox to "kick the tires". We have a very capable technical team who did it fairly quick, but they had some problems. There were some minor problem which required some help from Tidal. However, we just recently installed SP3 and that was smooth. It had no problems.

The deployment took us a bit of time because we had an issue. It took like two weeks. However, if we exclude the issue, it probably took a day or two at most. It depends though on what you are installing, if you are installing in production, and if you are installing it in a quality system, where architecturally the landscape is different. For our purposes, SP3 was done in less than a day.

This was to "kick the tires", so it was not a real implementation as the production system has multiple systems and components. It will be more complex. This was just a single server containing all components of the tool, so it was easier from that perspective. It didn't take that long. Production will be different.

It is not like anyone can do the installation. It has to be a fairly technical, experienced person. The 6.5 version upgrade to the sandbox went well. 

The fact that we were able to install it on our own, albeit with a minor problem here and there at first, speaks to the quality of the software. It has definitely improved from the days when it was owned by Cisco.

One person did the deployment.

The ROI is pretty straightforward. It's a mission-critical app, and if we had to go back and do things the way we used to, it would be impossible. 

It would be undoable because now we would build a whole system that depends on functionality that is in Tidal. For example, to do something like calendars in SAP, they will be nowhere near as sophisticated or high quality. 

Could you do intrasystems dependencies? You could. However, there would be quite a bit of work to make that happen. It would be too complex. While here it is two clicks, and you're done. 

The alternative would be to go to a different product. But how? Migrating to a new product would be expensive, consuming, and complex. I just don't see that happening.

Our annual maintenance cost is competitive for what we have and what they do. 

We haven't bought anything new in terms of adapters or new agents. We did a purchase a few years ago. So, for now, we are good. It's possible that, if things change, we might buy some other stuff, e.g., a ServiceNow adapter. 

I have never had a problem with the solution’s licensing model in terms of its flexibility and its transparency regarding costs. You could debate whether it's expensive. It should be that much or less, but it's pretty clear regarding what you get and what you pay. 

It has been a bit of time since we bought something new. For the most part, the company is pretty upfront, straightforward, and transparent in my dealings with them. I don't have any issues. As far as licensing and new components, we haven't had to do that in a while.

There are project, system, and server costs. Some of the things that they are doing is introducing new products. They are introducing what they call their Repository, which is a way for you to move a job. That doesn't cost anything to us, because it is reusing a tool called Transporter. The repository is the successor to Transporter, so we already own it and are sort of grandfathered in. But that new product requires a server and database, so now we have to go out and get a server and database. So, there is a cost there.

The landscape requires a number of systems for which there are costs. You don't have to do that, as you can just live with it on one system. It all depends on how you want to design the architecture. The landscape, or the architecture, depending on what you do, and if you want to do it correctly, will need a master and backup. You also need a Client Manager. You will need those three systems along with the fourth system, the heartbeat, which is the monitor between the master and backup.

There are costs, from a licensing perspective. It has been okay. We haven't had to add anything in the last three years or so.

Lately, there are costs of maintaining, managing, hardware costs, etc. That comes with the territory. It comes with implementing a tool for managing jobs and SAP RADIUS. Tidal is cheap, not really that expensive, between the licensing, hardware, etc. We certainly have a lot more expensive products.

Going back 15 years when we bought the product, we looked into AutoSys and a BMC product. We looked at three or four solutions back then. We liked Tidal because of the user interface. It had the best user interface. 15 years ago, AutoSys only had command line.

There are new competitors now: Automic and Redwood. 

We haven't had a reason to even consider anything else. The company has used the product for a long time. As far as I know, we have no plans to get rid of the product.

We originally liked the product for the user interface, because of it was easy to use and the features, such as calendaring, dependencies, etc. I don't think the solution is difficult to implement and learn. Though, it depends. It certainly has some very advanced features which require more than cursory knowledge of other products. It takes time for that, and there is always a learning curve for whatever product you do. In general, it is a fairly easy product to install and use, if you are flexible as far as how you want to deploy it.

It's very straightforward to understand and install, but you need to have the right people who have the right knowledgeable and can do this type of stuff. E.g., you need strong technical people. Though, we certainly have dealt with more complex products, deployments, and systems.

The tool is complex because it can do many complex things. One of our requirements is before anyone gets on it that they get two hours of training sessions. This is just to give them a minimum of the basics. Almost right away, people learn the basic stuff: create a job, monitor a job, etc. The more complex tasks takes more time, but are not used by everybody. Most people just do the basic stuff, so learning doesn't take that long. The majority of people learn the tool fairly quickly.

It is a mission-critical app. We depend on it to run our SAP trials. Without it, I don't know how we would do them. It's just that critical. We know if Tidal has a problem, because everybody knows. It's that critical to us.

I would rate the product from a seven to eight (out of 10). We have been using the product for a long time. We like it. We plan to upgrade soon, hopefully this year or next year. The users are very familiar with the product. It has become such a critical tool for us that we depend on it. We have built a relationship with the company now. I believe that the product is in good hands. They want to do right by the customer and listen to them. They are doing a lot of good things.

For most of the companies where I have put Tidal in, it runs everything. It does back office, handles trading, reporting of time, doing a lot of file transfers between vendors and regulatory bodies, etc. We use it to do a whole variety of things.

File transfers are our most valuable use cases because those are the ones where we tend to have service level agreements and potential fines.

Right now, we are just in a traditional installation with local servers.

We use the solution from Hadoop and Workday and are not using adapters from them.

It saves times due to automation. With some files, we do hundreds a day for a particular vendor. This would be hard to do manually. Also, the speed at which we can do this is excellent. We do all types of stuff, like we print checks for customers at the local office, which used to take a bunch of time, but now, we can do it in a minute or two.

Windows and Linux are our servers. We use it there, then we do things between Workday or the business application for Oracle. We can do processes which include local scripts or work with these different tools, then they can blend them altogether with Tidal. It does a very good job of managing cross-platform, cross-application workloads. It lets our command center monitor a bunch of things from one screen.

The solution enables admins and users to see information relevant to them. We do a lot of this as we have different teams who want to monitor their own jobs or be involved with their own support. They can do that. With the different levels of security within the tool, we can allow people to rerun jobs or just view information and different things based on their need and security requirements. This helps us decentralize a lot activity. If users can look at things themselves, or potentially certain groups can rerun jobs, we can offload that from the command center or other support teams.

We need to have less Tidal specific support people and more generalists, as they know their own applications in more depth than any of us. It lets them more effectively do their support, and not need to have other people do support, like in the command center or Tidal team. The solution has increased productivity by getting people's problems resolved faster. It also helps those teams understand how things work a little better, so maybe they can improve their processes.

If we can get the problem solving closest to the people who know the resources, we don't have to bring in the Tidal team since a lot of this stuff is not an actual Tidal problem. It's more a problem with their script or server, etc. Therefore, they can get work on their specific issue themselves. For example, we can't fix their script or if there's a problem with their server. That's not our team's function. They can get to that faster. Or, the people who are monitoring, like the command center, can help get their ticket to the right group faster.

Until recently, I had to be available on call. Now, that has greatly dropped. We have these different groups who take more responsibility for themselves. Before, if anything went wrong, they called Tidal, who would say, "Your script is not our problem." Now, they're able to route those tickets more effectively, and those of us who are on the Tidal team don't have a standard on call anymore.

Customers, in general, tell me that all the built-in alerting capabilities are valuable. If you want to send an email, Tidal knows how to do that, where with other tools you have to write a script. If you want to send an email or do an alert that a job failed, that is all built-in and can interact with industry standard tools to help automate the command center process.

The solution is very good in terms of user-friendliness, as it's web-based. We can use it with a number of different browsers, so it gives us a lot of flexibility.

Our admins use the solution’s drill-down functionality all the time to investigate data or processes. They use Tidal constantly to help debug their own processes without necessarily involving a Tidal person. This is just for everyday operations where we are getting file transfers or something that doesn't work, then the admins can look at the output. They can follow the stream and dependencies. E.g., maybe the upstream job didn't create the file. There are variety of things that they can do themselves.

People seem to pick it up pretty quickly because it is similar to a lot of things that they are used to in Windows with the same sort of structure. We don't give a lot of training, so they generally learn by doing pretty quickly. Creating a basic job is very straightforward. A person can create a basic job in a few hours. It is just learning some of the more nuances about how to use different dependencies and rerunning strategies that they will need to learn over time. 

The new reporting tool, Tidal Explorer, will help a lot of people with tools for looking at their overall design. It is able to drill down and get all types of statistics. It's just a really powerful tool, which has some basic searching functions to find where a variable used, etc. This is the sort of thing that a lot of everyday users are trying to find. E.g., if you don't know how something's used, you can go and search for directory to find all the jobs using that directory. Therefore, it is a really useful tool.

I would like more involvement with the cloud. That is something I know we were interested in, as we are moving applications. One client's management team has told Tidal that they would like to see integration with the new application.

They have been doing a pretty good job on improving it. The update of the client to not have a separate database has been a big improvement because that could add another bottleneck. Right now, it's a much faster process, where it has an in-memory database instead of having to go to a database until you read all this stuff.

About 20 years.

The basics have always been strong. What is useful for most people, the addition of cloud support and different applications which can use adapters. That comes into play. The ability to interface with Internet functions makes it a pretty strong tool.

Deployment and maintenance depends on the size of the organization. One or two people are probably need, but it can even be a part-time function. The roles of these people also depend. Companies can set up administrator type work, which is to set up the environment, providing the care and feeding of it, such as adding new agents or new users. They are just overseeing the day-to-day maintenance and running of it. There is not much activity with that. Then, there is creating jobs, which is sort of the application side. This is usually the monitoring side where somebody is watching the actual status of jobs and responding to failures or other alerts.

The scalability has been very strong. We haven't been able to hit any limits. I feel like with this technology the speed of systems and networks increases, and what might've been a problem 10 years ago, is not a problem now.

The role of the end user depends on the team, but some of them can create their own jobs. In other cases, they will give us the specifics and another team will create the jobs for them. So, it depends on how involved your team wants to be. We'll give anybody read access, so they can see the output of their jobs, for example. But other teams, who have a little more knowledge, might give more access where they could rerun or create their own jobs.

I don't know about specific plans to increase it other than bringing in those cron jobs which are not using it.

The technical support is very good. They are very responsive when we have an issue. The last issue that I worked on was that we had an issue with the Transporter and they got a patch for that.

Their initial response is very quick, less than an hour. Then, depending on how long it takes to work with development, it may take a bit more time to get a patch, about a week. This is for non-emergency cases. For something that is a higher priority, they can get things faster.

Tidal, the organization, has been really easy to work with. They are interested in making the tool and use of it as easy for customers as possible. For example, recently they have added onto the support site and there are all types of video training that you can take which are included in your support. Even if you are a fairly large company, you do training. I would typically be brought in to do training when people are first using the tool. But they don't keep doing the training over time, as they expect people to learn it from the other guys. Having this availability so you can look at a video based on your time, and it's free, helps you to look at some features you don't normally use, use some other ideas, and help you pick up skills that you don't necessarily have time to do sitting down with somebody. You can watch these videos as you need them.

I have worked with other workload automation solutions before, but nothing that is still around. 

Even though we have been a Tidal user for quite awhile, there was still stuff being run with Windows Scheduler or cron. We have been able to pull that stuff in and reduce the workload on teams.

Having done the setup many for different customers, it is pretty straightforward. In most places, if they took the time to look at the documentation, they could do a lot of the installation themselves.

A traditional deployment takes half a day or less. You get the basic Tidal setup going, then you have to start getting your agents. That's going to depend on how many servers you have. However, setting up the basic and backup master, fault monitor, and client manager can typically be done in half a day.

The documentation is pretty straightforward. You first want to install the master and client manager to sort of test your basic configuration. Then, you add on the fault tolerant parts of the operation.

Overall, the TCO is pretty good. There has never really been a conversation where any customers I have worked with complained about it.

The pricing is pretty reasonable. That seems to help a lot versus other companies. There are no other fees aside from the standard licensing fees. There are other products out there where you pay based on how many jobs you run and so on, and I know that's very frustrating for users.

The solution’s licensing model in terms of its flexibility and transparency regarding costs is pretty good. A person can buy the license, and if you decide to stop support, you can do that but still have the product. So, it's not like you're paying constantly to keep that license alive. Certainly, you want to keep support going too. Once you buy it, you own it. It's not like I have to keep paying somebody to keep using it.

If you are willing to shop around to other vendors, you can possibly get a good price on your support license.

The customer's ability to budget for the solution, given that there are no costs for upgrades and other enhancements, is a very positive factor. I have signed on people who have left Control-M because they could not budget accurately because based on how many jobs you run, you are writing a check every month.

I've heard good things about Control-M, but their biggest problem is their pricing. You get everything, so it's expensive to begin with, then you keep paying for your usage. Technically, I hear it's a nice product, but it's more the pricing that drives people away.

I used to work for Tidal and Cisco, supporting Tidal. I'm not an everyday user. I haven't worked for the current Tidal people, but I worked for the original Tidal. When I started back with the original Tidal, Cisco didn't put as much money into it as maybe we could've used. So, it sort of stagnated in some people's view. Now, the new people are putting a lot of money and effort into it.

In some ways, Tidal has kept me from having to learn more about different operating systems or tools because I can automate stuff. I don't have to necessarily know all the internals of different things. It has expanded the areas that I can work in without necessarily having a lot of training in different things. E.g., I don't need to be a Informatica expert to be able to run Informatica jobs.

You now have the ability to start something from the cloud, and that is the most powerful way to go forward. Because there is cloud support, if I was going to be starting new, I would look into doing a cloud implementation right from the beginning. E.g., one of my customers did a major data center move, and we had to rebuild all their servers and duplicate all their software. If that had been in cloud, it would've been just been a drag and drop type of a thing. You wouldn't even know what building you were in.

I would rate it an eight (out of 10). There is room for improvement, but the solution is pretty good. The support has always been very good.