Tidal by Redwood Reviews

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.

Tidal is used for workload automation, batch jobs. It lets us run financial jobs, warehouse replenishment jobs, and reporting jobs across multiple applications, such as SAP, warehouse management systems, as well as our auditing system. We run something like 11,000 jobs every day across our enterprise.

The types of application middleware that we use it to automate include Azure Data Factory, data warehouse jobs, Azure Analysis Services jobs, our PDM database system, as well as our warehouse system that handles product reordering, picking and packing, and e-com orders.

The biggest improvement, and the reason that it was brought into the organization, is the creation of a cohesive set of job streams across multiple applications. An example would be if you order a coat on our website. That order goes through our e-com system. Eventually, it gets picked up by Tidal, handed off to our SAP financial system and order fulfillment system, and is then sent over to the warehouse management environment. Those applications enable us to collect the money and to know what we need to replenish. We also use them to get the coat ordered and sent to the person who ordered it. All of that is handled by different applications across our enterprise and Tidal gives us the way to schedule those in a single job stream that can be managed with dependencies and tracked.

Tidal has helped increase capacity, in terms of the number of jobs, but a lot of that has followed the increase in virtual machine and database capacity. We've gone from about 2,000 jobs a day to around 11,000 jobs a day. Tidal has been easily able to keep up with that capacity.

It has the ability to not only schedule jobs, so they run within a certain calendar time, but we can also trigger jobs ad hoc, and we can do that via email and file triggers, and in a variety of other ways. That has allowed me to build out flexibility for different team members and different needs throughout the year, depending on our sales cycles and our retail cycles. It allows people to run a job without even having to open the system.

The Graphical Views feature is also very good for helping us to understand a job stream. It's great for providing a visual overview of the status of a workflow, especially the Critical Path view. That is one of our favorites.

I'm the administrator and I keep the system healthy, but I don't monitor specific jobs. We have different folks who do that and they find it really nice to click on a job that's at the end of a long job stream and get an idea of its health, using the Graphical Views. Not every team uses them, but the folks who do really like them.

Tidal integrates with and connects to different systems to run the different jobs and it does that very well. There are connections from Tidal to SAP ECC, the warehouse management systems, et cetera. Not only does it do a great job running the jobs, but we get very valuable information back into Tidal about the health of a job. Did it run well? If not, what happened? It becomes a nice single pane of glass to find out if things are working the way we want. 

We also integrate it with our ticketing service management system, which is Cherwell. That works very well too. If a job fails, we integrate with Cherwell to create an incident that is then acted on and that has been pretty smooth.

If you have familiarity with APIs, it's a matter of just looking over the documentation and understanding Tidal's way of using the API, and then you can build integration with PowerShell scripts. That's something we're doing with the Cherwell integration to bring data from Tidal into Cherwell.

The ease of drilling down into details using the Graphical Views is moderate because there is a little bit of a learning curve. It could be a little easier, but it's definitely not bad.

Similarly, the user interface is moderate. They've improved it but there is room for more improvement. I'm so used to it now that it's second nature, but I do handle the training for our new users and that gives me an idea that sometimes it's confusing as you start to get into it. The company is working to improve it, from what I understand.

I would also like to see more of a cloud/hybrid solution. I know they're working towards it, but I would like to see that sooner. Currently, it is on-prem and that's fine because most of the applications it supports are also on-prem, but there is potential for more applications to move to the cloud. It would be nice to have a hybrid solution.

Also, when we patch to the next version, there is often a little thing that breaks. It has rarely been a big deal, but I always seem to have to follow up on one tiny issue. It would help if they had some better QA testing of their patches. It could be I'm just too aggressive on patching, but at the same time, better testing would be good. Whenever I do open a ticket, they follow up on it quickly and I get great service, but I'd rather not open a ticket.

I have been using Tidal Automation for eight to nine years.

We have only ever had one system outage related to Tidal that was Tidal's fault. That's pretty amazing for a product that we use all the time.

We're a medium-sized company at 11,000 jobs and we're using just one instance for that. My understanding is that it can scale out to hundreds of thousands of jobs, depending on how you implement it. We're in a good space and we would be able to scale out if we needed to. I don't see us needing to, but my understanding is that there are companies that use it on a much larger scale.

Over the years, they have built out connections to different types of systems that they didn't originally support. Azure Data Factory is new in the last eight years, and that means that Tidal didn't always need a connection to that system. They build out those types of connections and they work to stay current and to work with the applications that are out there. I see them striving to stay relevant, in a good way.

Tidal does a nice job of continuing to educate its customers on their solutions and what they're modifying or doing to provide new features. They have quarterly webinars that are very informative. I also find that our customer service rep is very informative. If I have a need for a demo of something that is new, I can reach out, get it scheduled, and they'll do a demo for it.

We have the solution deployed in a single data center where we have our production environment. We also have it in separate QA and dev environments. We connect to about 18 applications across our enterprise. Our total number of users is about 150, but on a weekly basis there are 20 to 30 people who use it heavily, people who are always in the system doing things.

One of their strongest areas is their customer service. Many of the same folks have worked at Tidal over the years. I have gotten to know some of the technical support people and we've built up a relationship. I can ask them questions and get answers that I trust. We've had our customer service rep for years, so I see a lot of consistency with their staff and the knowledge they have. 

If you submit a question and they discover it's a bug, they're good about getting it into a hotfix quickly, depending on the urgency of it. I find them to be really responsive and I find them to be knowledgeable and friendly. On the "people side," there is definitely very strong customer service and support.

I rate their support a 10 out of 10, especially compared to other situations I've run into.

Positive

I wasn't around for building out the original jobs, but I've had to install it on different systems as we've migrated, and it's pretty easy to install when moving to a new system. You just pick up the database, bring it over, and do a little bit of configuration.

Once you get comfortable with the system, it's pretty easy. It's consistent. There's always a learning curve, but it's moderate. It's not hard but it's not easy because you do have to learn things.

The amount of maintenance is pretty low. We patch it about three times, although they have patches that come out quarterly. The patches do two things: they fix issues and introduce new features. I'm usually patching because I'm interested in the new features. We could patch less, but we do it that often as a company choice. But in terms of keeping it healthy, we haven't had a lot of big issues related to Tidal, which is very good. The level of maintenance involved is good. I handle it on my own. It's not a complicated system, from a maintenance and support standpoint. That makes it a lot easier to keep healthy.

We have absolutely seen ROI. It's not just that it's critical to our company, but I also feel that there is definitely return on investment because of the good support.

We are satisfied with the pricing of Tidal. It's in the moderate range and it feels very achievable for us.

The base product itself, Tidal Automation, is licensed by the connections that you have to other systems. We review those whenever licensing comes up. If you want to add something like Tidal Explorer, or other modules, there is an additional cost.

They have modified the licensing model a few times and there has been a bit of a learning curve, which is expected, but in general, it seems to be clear and transparent. And they're very willing to talk to you and answer questions if you have them.

A few years ago we looked at Stonebranch Universal Automation Center, and we've occasionally looked at Control-M, to see what else is out there. 

From a cost perspective, Tidal beats them both, and we've had such good support from Tidal that it makes it harder to think about leaving, especially since the product works very well. Right now, we're not looking at anything else, but I always keep my ear open because you never know.

Work with the folks who own the systems where the jobs will run, so that you understand what your needs are, and leverage Tidal's customer support to come out, give you demos, and to help you get started. Their documentation is actually pretty good, it has improved over the years, so if you want to read it you can, and it will be helpful.

As the only support person for Tidal in our company, I'm very motivated to stay on top of things. That means I do a lot of training to make sure that my users, the people who build out the schedules, are knowledgeable and understand how to respond to issues.

I have also set up a lot of alerts that give me an idea of things that might have issues. All of that is done using Tidal's tools, which is great, to keep me on top of things.

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 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.

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).

For us, the calendaring system is very robust. Some of the teams have very specific requests for when they need jobs to run. That's been really valuable, because a lot of times, when people run scripts, if they run on a holiday, they're going to fail. We've even started adding some European holidays and other times when scripts should not run because they're going to fail, because they try to connect to external exchanges that are closed on a holiday. For things like that, things you can't do in a lot of built-in scheduling tools, Tidal has been very helpful. A couple of times a month it probably saves us work and the necessity of logging in from home and checking to make sure everything's okay.

Especially in the newer versions of Tidal, the segmentation of user permissions enables us to give people operator permissions for their jobs, to rerun jobs, but view-only for other groups' jobs. We're able to keep people from hurting themselves or other groups accidentally. The permissioning is really good. We have 20 different root-level job groups that hold all of the jobs for each team underneath it, in our shared space. I can set it so that the database group only sees database jobs, if that's all they want to see, so it's not cluttered with everyone else's jobs. But if there are teams that need to see all the spaces, we can do that as well. We can let them see only certain servers or certain users to run jobs. You can edit it too so that people don't see too much or don't get confused and lost in this sea of the thousands of jobs that they could be seeing, when they only need to see their own. That's been nice to set up over time.

In the past year, in particular, the client has gotten tremendously better. If you asked me three years ago, I would have said that the client was the biggest problem with Tidal. The backend was always really solid, but the client was pretty bad for a while. In the past year, with the new company taking over and putting a lot of development effort into the clients, especially the web client, it has really made people a lot happier when having to use the client and work with it. In the past, they begrudgingly used the client, but now they're happy to use it, which is a big change.

Because we've been with Tidal for so long, I can't compare it to the way things were before Tidal. Back before Tidal, there was much less electronic trading.

But an example of how we benefit from it is that we have Tidal jobs that load all of the trading symbols into our database every morning before trading opens. That's mission-critical in terms of getting ready for the traders to start trading on a specific day. If they don't have that updated information through the database, they can't trade.

There's a lot of overnight, big-data processing that happens, things that need to run all night. That's launched through Tidal and monitored as well. It's pretty much a 24/7 operation in terms of uptime, and we've definitely used Tidal to meet that goal.

The solution has increased productivity by saving staff hours. We have an operations team that's here 24/7. We have a runbook that says, "Okay, if this job fails, do this." I'd say 80 to 90 percent of the time the operations team is able to resolve a problem by following runbook and steps without having to contact someone overnight or on the weekends. But Tidal does save the person who owns the Tidal job from having to do work in off-hours especially.

What I like about the new company is that if you ask for something, and they feel like it would be a valid improvement, they're willing to push it out, even if it's a few months out. They make sure to provide it at some point. It doesn't just get lost in the mix.

I work for a financial trading company: stocks and options. The use cases depend on each group that is using it. We have a compliance group, HR group, and a bunch of trading groups and technologists. It's used for a thousand different things depending on the group. It's all to support a financial trading firm, and the processes that happen before the market opens and after the market.

We have a pretty good mix of Linux and Windows boxes, a good 60 percent Linux and 40 percent Windows. We launch trading scripts to start processes up, to stop processes, and to pull in data from third-party vendors; we have FTP jobs that do that. We run an Oracle backend.

From talking to the Tidal people, we have a lot of agents connected to masters, compared to most other firms. But we're probably middle-of-the-road in terms of how many jobs run per day. We're only slightly over 100,000 jobs per day, throughout the whole space.

The biggest problem for us was the Transporter tool that works through the API. It's like a GUI into the API where you can transfer and compare jobs between two Tidal spaces. Up until the last few months, the Transporter tool that was offered was not really good at all. It was hard to take a job in development and promote it to production. There was no really good tool to do that. They offered a tool, but it wasn't that good.

But they just put out the Tidal Explorer tool, which is basically a replacement for the Transporter. That looks promising. I haven't really gotten to use it yet, but it seems to be a better system. That's what people have been requesting for a while now: an easy way to promote and review changes; something like a script repository-type of system, where you can promote something or pull it down, compare it, and then, if you like it, push it. If it doesn't work, you can back it out to previous revisions. It looks like it offers all those features, but I really haven't had a chance to dig into it. I set it up and it does look promising for the future. It's probably something that we're going to try to integrate into the day-to-day processing once it gets released. I don't think it has even been released as general-availability yet. It's still in beta. But once it gets to be production-ready, we would definitely love to use it. It's something that's been on our radar for a while now.

Tidal also had a cache database, which was a copy of the master database, that the web client used. They got rid of that in the latest version, and that is something we had been asking for, for a long time. The way it had been set up didn't really seem optimal.

It looks like they're trying to put forth a better tool for certain places that were lacking.

On another topic, we have to set up ways to send a job event that finds a job that completes abnormally. What we do is send it to an SNMP trap that gets aggregated into one space and we can see those errors. We try not to use Tidal for monitoring, as much as for job launching and tracking. We have a Nagios setup so that if something fails, the error can be sent to Nagios and checked there. If a job is a long-running job, like an eight-hour job, we don't want that job active in Tidal for the whole time and taking up a job slot. We'll kick the job off in Tidal and it will show that it has completed normally. Then we'll hand it off to another tool to monitor that the process is running for the specified amount of time. I don't know if Tidal wants to get into the business of monitoring long-running jobs, but that could be a feature for the future: a job launching and monitoring tool. Using Tidal for monitoring doesn't seem like a good fit, but if they could offer something that did that as an add-on or include it, it might be helpful.

Finally, the solution is a little tough to learn. Talking to people who are new to using the Tidal interface, it's difficult. But I don't have anything to compare that to. They have said it's not as difficult as Control-M or some of the larger scheduling systems that people have used. It's not as hard as that. Tidal has worked to prevent new users, especially, who aren't exactly sure what they're doing, from hurting themselves too much, which is good. They've put a lot of restrictions in place to prevent people from doing things that weren't intended. There is a learning curve, but I don't think it's steeper than any other new scheduling system. In the past, we've downloaded some other options and they had a learning curve too. If you've never used it, there's always a curve, with the terminology, etc. But I don't think it's any harder than any of the others.

New users of Tidal need at least a month of working with it a little bit each day. I give people a three-hour introductory course. Every quarter I provide an overview for new users of how things are set up. Luckily, in our company, a lot of these new users are joining groups that already use Tidal on a daily basis. If they have any questions after the initial course, they can talk to their team. Over time, the teams that use Tidal are resources for the new employees. That takes a little bit of training off of my plate. Within a few months people are confident and moving along. It takes a few hours to pick up but to be fully confident it would take a few months to really feel that you know what you're doing in the space.

We've been using Tidal Workload Automation for 15 years.

I'm really confident in the stability.

Cisco owned the company for a few years and I felt that it was something of an afterthought for them; it wasn't really their business. They didn't really put the time and effort into it. It seemed like, for a couple of years, nothing was getting resolved and people were pretty unhappy. We ended up staying in a version that was years and years old, compared to what we should have been on because we were not confident in the solution that they were providing, to give us what we needed. 

In the past two or three years, since the new company took over, we have much more confidence. People are much happier with the direction that Tidal is going and the features that they're releasing.

Our usage of Tidal goes up every year. That's not even from planning to increase usage. We have a few holdouts, people who still use Task Scheduler or cron, but over time they've all been folding into the Tidal space to have a better overview and a cross-platform way to see everything and rerun everything and be alerted. They've come to the conclusion that it's a better method, especially for overnight. We have an operations team that manages things overnight, so that if something fails in the middle of the night, that team can handle it, which they would not be able to do if it wasn't in Tidal, along with thousands of other jobs.

In terms of the number of jobs in Tidal, it's been increasing at between 10 and 20 percent a year. It's going up. It's definitely not going down. Initially, it was probably 50 percent a year because everyone was adopting it. Over the past five years, since it was already utilized by everyone, there has been a general 10 percent a year increase because of new jobs that need to be created and new processes that need to be started and stopped.

We're somewhere around 95 percent in terms of adoption of Tidal. There a few small groups that like to do their own thing and use open-source products, but those are groups that maybe only run Unix and that's it. They're happy with Jenkins or something open-source that only needs to run a few hundred jobs. It's only one platform, and it does what they need to do a little bit better than Tidal. But for groups that need an all-in-one solution, they've all gone to Tidal. If they need to do what Tidal offers, they're going through Tidal to do so. It's pretty accepted here.

Tidal was here when I got here. It's been around for a while. But over the past 15 years, I've been the one who researches the new patches and service packs and revisions and I've done all the upgrades.

The upgrading process is straightforward for me, but I've been here so long that it's just something I know. It has gotten much better with the new company. We're on a Unix backend, so a lot of times, with a simple hotfix or service pack, you can just run a shell script and it replaces all the files. It does everything it needs to do. It places everything in the right location, and then all you have to do is start and stop the backend process and it picks up the new revision. That's been really good. In the past, it was a more manual process. In the past couple of years it's gotten much easier in terms of being able to do things with one script.

The releases have been good with very few bugs or installation problems. There were some in the past, a few years ago, where you would try to run something and it wouldn't take into account your environment and it would fail. You'd have to tweak some of the script. That was a lot of manual work. The upgrade scripts, recently, have worked pretty seamlessly.

We have an enterprise contract, so if we want to add another agent, or if we want to add another master, we don't have any restrictions on those things. Other vendors don't have that flexibility. For me, as an admin, that makes it easy because I don't have to think about what a new master is going to cost or what a new agent is going to cost. If someone needs a new agent and they need to run a job from that agent, we just go ahead and do it. If we're in Dublin, Ireland and someone wants a new master because there's a group over there that wants to adopt Tidal, we can just say, "Sure, get a new license, create, and you're fine." For the license that we have, the flexibility is great.

I don't know if other people aren't happy with the licensing model because they have a non-enterprise license where they have to think about everything they change.

We're negotiating our new license now for April, which is when we have to renew. We've usually gone with a three-year license. The numbers that the new company has put forward haven't really changed significantly from our past renewal. People here are pretty happy with that. It's not like the new company came on and jacked the prices up exponentially. The new prices that we've received seem reasonable and comparable to the marketplace.

Because our environment is older, it's a little tough to integrate some of the newer features that they're offering. That's because of the way we had to configure our environment for older versions that didn't have these newer features. In terms of how you delegate permissions, how you set up calendars, who you give permissions to, my advice would be to figure out how the permissioning structure works before you set up your environment, and stick with a standard. A lot of the time, we're having to go backwards to make things standardized. If we started over right now, I know how I would set up a Tidal environment. It's hard to do that after the fact, and after things have been set up differently in the past. So try to develop the best system for standards and then keep that.

We don't use any of the Tidal adapters that they offer, just because we're heavy on development here. A lot of the people here, in the past, felt that they could write their own wrapper scripts to do the same thing that the adapter jobs do. That's ingrained in our environment now. We don't even look at the adapters too often, just because we have an in-house solution to those.

The vendor is starting to offer tools such as Tidal Repository, but that's going to be an add-on cost. I'm still evaluating whether it's something that we want to try to get a price on and use. It would allow us to see if certain jobs are running longer than they usually run. We could also see if queue levels are hitting their limits often and what we could do about that. The Repository seems like it's going to be a tool to gives you the drill-down information, like seeing how calendars are configured and a lot of the information that you're trying to get at. It's more like an admin dashboard where you can drill down. Right now, I just go directly to the master to search the logs, or we have all the master logs sent to a repository. I can search them there. We're doing things from our side with other monitoring tools we have and log aggregation tools.

We use Tidal to automate all the jobs within our IT applications, especially for our ERP, which is JD Edwards, as well as Oracle, and Microsoft. Currently, we execute 12,000 jobs per day through the platform.

It helps us make efficient and maximal use of our servers, from four in the morning until eight in the evening, with the maximum number of jobs executed automatically. We produce lenses for glasses in our factory and it's a 24/7 operation. The automation enables that, according to our requirements. Otherwise, we would need people to take action due to various dependencies, and it helps us avoid errors. 

We have to run about 12,000 jobs every day and the majority of them need to be launched from our ERP, JD Edwards. The native compatibility of the Tidal platform with JD Edwards dovetails with our greatest need. It's directly connected to the heart of our IT system. We couldn't work without it.

Nowadays, the UI is easy to use. Over time, with different versions, it has become better and better and now it's easy. It's very different than it was some years ago. It has improved.

We have never needed to use the REST API. The plugins provided by Tidal meet our integration needs completely. It integrates perfectly with our ecosystem, whether it's SQL Server, Windows, or our ERP.

One thing I would like to see improved is that, currently, when an action is executed and finishes in Tidal, it's marked as either "success" or "failure." I would like more options that would flag a job according to multiple options, rather than just "good" or "bad." We would like to be able to define five different types of results and proceed differently according to each one.

Tidal has told us that it's possible to do so through the product or with a workaround.

I have been using Tidal Automation for about 12 years.

It is very stable, fortunately. 

The scalability is fine for us.

We have not used their support very much over the last eight years. During that time, we may have submitted two tickets, because we are using the product in a very standard way. Generally, when we do need help, we call our partner.

Positive

We had a different scheduler before we started using Tidal but that was 12 years ago. We are very happy with the results of our switch. The product we used previously was Open Scheduler and we switched for two reasons. One was the cost of ownership of that product and the other was the set of requirements around our JD Edwards ERP solution.

The deployment was very simple. It involved the installation of an agent on a server. Nothing could have been simpler to install and use. We do have another data center coupled with our primary data center for high availability, so physically, there are two locations, but logically, they are one.

We currently have two people who work in Tidal, throughout the day, Monday to Friday. At other times, such as overnight and on weekends, we use managed services to work in Tidal.

In terms of major updates, there is only one every two years. There is very little maintenance needed.

We use a certified Tidal partner to help with upgrades and to be sure that everything is okay. It's so important that everything work perfectly that we prefer to use a consultant, even though we could do it ourselves. Our scheduler is in use 24/7. It never stops. It is the central piece of our IT operations. If it does not run properly, everything stops including production in our factory.

We have had a very good experience with our partner. We have been working with the same partner for 12 years and everything is working perfectly with them. We will be using their services again soon. They also help us with level-one requests.

The ROI is okay and that is why we continue to work with Tidal. Overall, the price is fair for the service we receive and the way it meets our automation requirements.

The most important measure, and our basis for comparison, is to look at the number of people who would be required to do the same thing.

There have been pricing increases, but with the reduction that our company obtained from Tidal this year, the pricing has become very acceptable for this type of product. It is fair, today, for what we use it for. If the price is increased, we may have to review things. 

We looked at other solutions but there weren't a lot of choices at that time because only two, Open Scheduler and Tidal, worked natively with JD Edwards. We went with Tidal mainly because of the way it works, with plugins, with JD Edwards.

Because my team has been using it for 12 years, they are used to it and have no difficulty using it. But in general, there is no problem using it daily.

For us, using the Graphical Views feature is the exception. It's not the easiest feature to use. We use it to present job flows, and the way they are organized and their dependencies, to our new people, because it makes things clear for them. But in general, we avoid using it and use the main screen. We know our applications well, so the tabular view is sufficient for us. It's more complicated to use the Graphical Views feature, for us, but that's based on what we have become used to using, day to day.

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.