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.

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.

The solution is used to automate and manage intricate and crucial business workflows across numerous systems and applications is the main use case for the Tidal workload automation software solution.

The workload automation software from Tidal is especially helpful for sectors like banking, production, transportation, and healthcare that have high volumes of time-sensitive processes. Any delay or mistake in finishing tasks can have serious repercussions and affect the bottom line in these sectors.

The software solution from tidal can assist organizations in achieving regulatory compliance and supports compliance requirements.

Tidal Automation offers extensive monitoring and reporting features that let users keep track of the status of their workflows and quickly spot any problems. 

The tool's high degree of adaptability also enables users to design processes that are tailored to their particular company requirements.

The Tidal software utility offers a wide variety of automation features, including exception handling, sophisticated dependency management, and event-based scheduling. Helped our organization to meet SLAs.

Tidal Automation can assist businesses in automating their processes, lowering the need for manual involvement, and boosting productivity.

It offers cost savings, quicker working periods, and greater accuracy may come from this.

Users of Tidal Automation frequently laud its simplicity, adaptability, and dependability

The product offers a user-friendly interface that makes it easy for users to generate and plan tasks.

Tidal Automation is a flexible option that can be tailored to meet various company requirements because it supports a large number of platforms and apps

Tidal's adaptability and user-friendliness could be increased by integrating it with additional programmes and platforms.

By enhancing its analytics and reporting tools, Tidal could make it simpler for users to monitor and evaluate their tasks.

Added security elements may raise the product's general security posture.

Also, Tidal's adaptability could be increased by integrating with cloud platforms, which would also make managing tasks in these settings simpler.

Users may be more likely to adopt and use Tidal if the setup and configuration process is made simpler.

Tidal Automation uses advanced algorithms and machine learning techniques to analyze real-time data from tidal turbines and adjust their settings to maximize energy output while minimizing maintenance requirements. This can help increase the efficiency and reliability of tidal energy systems, leading to cost savings and improved environmental sustainability.

Overall, the primary use case for Tidal Automation is to help manage and optimize tidal energy production in a variety of settings, ultimately contributing to the growth and success of the renewable energy industry.

One of the main benefits of Tidal Automation is increased efficiency and productivity in tidal energy production. By automating the process of turbine management and optimization, Tidal Automation can help reduce downtime, improve turbine performance, and ultimately increase energy output. This can lead to cost savings and improved profitability for organizations in the tidal energy industry.

Tidal Automation can help improve the reliability and safety of tidal energy systems. By analyzing real-time data and making adjustments to turbine settings, Tidal Automation can identify potential issues and prevent equipment failures before they occur. This can help minimize the risk of accidents or other safety incidents.

One of the key features of Tidal Automation is its ability to collect and analyze real-time data from tidal turbines. This includes data on turbine performance, energy output, and environmental conditions. By leveraging machine learning algorithms, Tidal Automation can use this data to optimize turbine settings and improve overall efficiency and performance.

Another valuable feature of Tidal Automation is its ability to automate turbine control and monitoring. This can help reduce the need for manual intervention and monitoring, which can save time and reduce the risk of errors or accidents. By automating tasks such as turbine startup and shutdown, Tidal Automation can also help reduce wear and tear on equipment, which can prolong its lifespan

The solution could be improved via:

1. Integration with other systems. Tidal Automation could be further integrated with other systems used in the operation of tidal energy systems, such as weather forecasting tools, energy management systems, or asset management software.
2. Customization. The ability to customize Tidal Automation's algorithms and settings to better fit the needs of individual installations could be added in the next release. This would allow for greater flexibility and adaptability to different environments and operational requirements.

We use it for a host of standard/general stuff, like batch workflow automation, in the front and back offices. We have also centralized all of our SQL Server maintenance that is running on it. Instead of having SQL Server maintenance plans or jobs running on 300 or 400 disparate servers, we run them through Tidal so we have consolidated administration and reporting that feeds straight into ServiceNow.

Last year, we made a step change with our DR recovery process. We had a bunch of people running manual scripts and different things where you have networks: Wintel, DBAs, or application support teams. They were running their own separate scripts to do application failover. This is different when it's active-active or active-passive replication. What we did was integrate it with different command line driven jobs, like PowerShell commands, to effectively failover applications and infrastructure into a sequenced set of dependant jobs. Therefore, if we need DR, we were not relying on a mix of SMEs saying, "Where was that script or how do we fail this over?" Instead we can just push a button and the thing fails over, which is beautiful. 

Additionally we do compliance reporting from within Tidal and like many people we are regulated from PWC. Everyone has the technology control frameworks that they have to evidence. Instead of people taking screenshots, we will effectively find out what information PWC need and build the job using CLI which runs on either month or quarter end. The job will go off, collect that evidence, come back, and be formatted. Then, we just drop it in SharePoint or use Tidal to save it to a file share, sending an email off to say, "Your evidence is collected. You need to review it, then sent it onto audit."

We use it for a vast array of housekeeping jobs. It is not that Tidal is a monitoring tool, but automation is basically as far as your imagination can take you with anything that runs by a command line, which is virtually anything you can do. 

We previously had a use case for it to give us a quick alert for when some of our infrastructure became unavailable. We just had it running every minute. Typically, it's not an enterprise monitoring tool, but if you have some deficiencies or things that you need to enhance, or give a different sort of dimension to, we've used it for that in the past. We also run it against our infrastructure using PowerShell to pull a whole host of reporting from our infrastructure daily, which is useful.

We use Tidal to run SQL Server and Windows. There is not really any Unix.

Since we start using it, they do more stuff in AWS. They now have a whole bunch of different cloud capabilities. We are moving towards private cloud. We're in the sandbox at the moment.

The product helps our company in the way that we've engineered it using bespoke jobs that we've written in a clever way. There's nothing directly at the moment. That might change as we move into the cloud, depending on which cloud we go with or on the adapters that they use, e.g., if they have native S3 adapters or events that can fire Lambda functions, which are a bit more interesting to us.

There are many valuable features. I would struggle to say that there is one more useful than another. Job Events and its email capabilities are good. 

We have integrated Tidal with other automation platforms. You can integrate legacy platforms, as the integration is easy. Overall, we have good impressions of its ability to manage and monitor workloads.

They have a bit of work to do on the ServiceNow Adapter. At the moment with 6.2.1, we can send an SNMP Trap to ServiceNow in order to create an incident fail. However, there is so much scope for a CLA API interface between the Adapter and the stuff that you can do with it. I would have other use cases for different things within ServiceNow potentially if that was the case.

The reporting is kind of lacking and not super awesome. They have a product where the administrative overhead isn't that straightforward. Maybe, we're using it wrong.

The ability to express jobs as code is something I wanted for years now, especially as we move into the DevOps space. We have been doing one-touch deploys in terms of our CI/CD pipeline for a while and we have releases and code deployments that go through environments with a single tool for deploying. Therefore, SQL code, SSIS packages, and registry entries can install something all at once. Tidal can't do this for jobs, because they use a Transporter mechanism, which baffles me because the product is a SQL Server on the back-end. We would like it for a developer to be able to push a button saying "Script", which exports a script for the injection from one environment to another. This is what it needs instead of a clunky Transporter tool to take it from one environment to another. If they could just rip out the code that they were going to insert into the next phase, then we can express those jobs as code and dive into our consolidated release process. For me, in the DevOps space, expressing jobs as code would be the way to go.

The solution’s current drill-down functionality is alright because the Client Manager is an actual database. With the next version 6.5.3, they put that into a memory database. Therefore, you have no real ability to go through and have a look at it. I think there's a gap there.

10 years.

It has been super stable. There are no complaints on stability. We would not be using it if Tidal wasn't stable. You can't have an automation system that is unstable because it is too critical. If it's fallen over, everything is delayed in the morning. The business impact will be significant, because potentially your front office can't trade. If your automation platform doesn't work, you're in bad shape.

Two people are required maintenance.

We have had no scalability complaints. It is all pretty straightforward.

We're looking at rolling this out a bit more globally. We have some people in India, North America, and elsewhere. The rate that the skills get picked up can depend on the region, but it also depends on the skill sets that you already have. If you already have some knowledge of an automation tool or orchestration tools, then it's quite intuitive. However, if you have somebody who has never seen it before with no knowledge on the information system, then it might take them a bit longer.

We have about 100 DBAs, testers, business analysts, and automation developers using it. At one point, we had nine live environments.

I have been through many different iterations of the company. They used to be owned by Cisco, then Tidal was moved to somebody else. Now, it's with STA Group who seems very responsive and customer-driven, which is nice. They are making efforts to listen to their customers and see what they want, which is great. It's still in the early days to see how reactive they are in terms of development.

I've never called the technical support. My guys are the ones who have to speak to the tech support. I've not had any complaints.

We went from AutoSys (formerly CA) to Tidal. We switched because of CA's expensive licensing. They were also behind the curve.

The initial setup is fairly straightforward. There are a few nuances or a couple of bugs, but as soon as you report them, they are fixed as STA Group is fairly reactive.

We are in the process of an upgrade, but we have a whole lot of other work going on and are not under any pressure to get it done. We just took our time with it. Therefore, it's not like we're doing just this upgrade. Though, you could install an instance in a couple of days.

The amount of people involved in an upgrade or deployment depends on how your infrastructure stands up. If you have a small IT department and you have one guy who administers Tidal, builds the servers, does the installations, and has nothing else to work on, then it is pretty quick. If you work in a larger organization where you have teams working in silos where everyone is maxed out with BAU and projects, then you may have to wait three weeks for your servers and a bunch of other stuff. It depends on how siloed your infrastructure setup is. Once you have the servers, then you can install the thing with probably two or three guys. Though, it depends on how complex your setup is. E.g., if you're doing HA between different regions in AWS, then you will need more people from information security along with network specialists. 

If you can automate things that people are doing, you will save time and resources because people can be doing more value-add work than manual stuff. Broadly speaking, if you start automating all of your clients' compliance evidence and collecting, it becomes standard, then the people who are doing that can do something more useful. If you extrapolate that, then that is time well spent and saved.

I have had no issues with the licensing.

The solution enables admins and users to see the information relevant to them, but this is bundled as an add-on that we would have to pay for. I am attending a webinar on this feature next week. It remains to be seen how much it costs and what the value is. It's touted as giving you all the analytics that you want. We have had it 10 years and got by without this feature. Instead, we have DBAs who can write queries to pull out whatever we need from our SQL database. There are ways around everything, as there are a million ways to do stuff.

We have evaluated other solutions. 

I would rate the product as a seven (out of 10). I love the product. It's pretty good. There are more reporting analytics that I would like to do and see out-of-the-box. I would also like to not have to pay for it. Our implementation has been super stable, and it really kind of ticks all of the boxes.

The Adapters that they provided are quite good. We have SQL, Oracle, and other ones that we have used in the past. I'm looking forward to using two or three adapters and being able to do harsh cloud native capabilities with Lambda. These are particularly interesting as we go into the cloud space. I haven't used them yet.

I have three installs of Tidal: production, qual and dev. I have a portfolio of 12,000 unique job definitions in production, 13,500 definitions in qual, and about 8,000 in dev.

The Tidal adapters I use are for Windows and Linux agents, as well as Informatica, Cognos, and mSQL.

With the portfolio of jobs that we're talking about, it's continuing to grow. There is way more work being added to the system than there is work that is being retired from it. That's just the way the animal works. It's been able to handle, perfectly fine, the complexity of the interrelationships between the processes.

We actually ported off of Maestro. Maestro was the scheduler that we were using, enterprise-wide, and it was very inefficiently used when I got here. When we came up on Tidal, we didn't convert anything. We built all of the definitions that exist in Tidal. So over the 15 years, that portfolio has grown.

As a whole, we're trying to automate as many things as we can to alleviate the manual processes. One of the things that Tidal has helped us with, because it is cross-platform: We had a number of different schedulers in this organization and we've been porting everything that was running out of these other, unrelated schedulers into this scheduler. That has afforded us the ability to set up direct dependencies between processes that couldn't talk to one another before. Over the 15 years, we've definitely gained a lot from that. What had been manual controls have become automated controls, by using this tool to replace a number of schedulers.

The automation aspect of the solution is the most important. I'm able to construct groupings that have dependencies which automatically allow the proper jobs to run in the proper sequence. That's the strongest selling point of any scheduler.

As for the solution's ability to enable admins and users to see the information relevant to them, the security model that I use is fairly simple and straightforward. For developers and other folks, an inquiry-type access is more suitable for the production environment. I've added functionality for people in both the qual and the dev environments, based on their roles. But I haven't restricted anything, meaning that anyone who has an account can see everything. There is a lot of flexibility in the way that things can be configured with Tidal. You could restrict it down to the point of people only seeing those things that are applicable to them specifically. I found that that would be too restrictive, and result in a lot of overhead to manage. So I went with a much simpler model, but the flexibility is there.

There are certain things I can put in play, triggering events based on statuses. For instance, if I have a certain job type where a number of the jobs are going to "waiting on resource" in the middle of the night, I can configure alerts so that I can assess those and then determine if I have to raise the job limits on some of those resources to make sure that we're not having things held up on necessarily. By the same token, if we're having long-running processes, I may want to tailor that down so we don't have so many processes running concurrently. There's some flexibility in that. I haven't had to rely on it a lot, but there are some features there that can be tapped into.

From an administrative point of view, I wouldn't give really high marks to the solution. I actually entertained getting the JAWS application at one point. One of the shortcomings with the scheduler is the reporting capabilities. At least at the time, JAWS was the best that they had for a third-party integration. I think they've got things in the pipeline to help alleviate that gap.

Also, one of the things I'm concerned about is that, with the security we have, there's a hazard that somebody could go in and accidentally delete a master grouping of definitions out of Tidal. Right now, I don't have an easy way to recover from that. It looks like a couple of things that are in the pipeline with Tidal are going to allow for that kind of recovery. There should eventually be a replacement for the Transporter tool. That sounds like it's going to have the capability of doing copies out of Tidal. If I scheduled that once a week, it would give me a copy of definitions out of Tidal. If it turned out that one of the operators, who had the rights, accidentally deleted a grouping of definitions, I would have something that listed definitions that I could go back to and recover.

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

The stability has been fine.

In fact, we're going back to using the master and the fault monitor. We had it disabled for some time, but we've gone back to setting it up with the fault monitor and the master, and the backup. There was a problem with it. There was some kind of a fault status that kept getting triggered. The network person who was in charge convinced us to disable the redundancy that we had set up, and we've just recently gone back to it. And it's been working fine.

We haven't hit any roadblocks with volume, but I think we've been sized properly too, behind the scenes, with each upgrade that we've done. It's been scaling fine. That's the bottom line.

There are systems out there that are larger than ours. We try to get to the user conference, here in Boston once a year, to do some comparisons to other organizations and the way they're using the tools. It's an information-sharing session.

Whenever we go for an upgrade, we look for an assessment of whether we need to provide more horsepower or not. If any of the configuration has to change, we watch that carefully with each upgrade. There's a formula that Tidal provides on whether you should have a small, medium, or large installation, based on the number of definitions that you have. They help with calibrating that.

We consider Tidal to be an enterprise scheduling application, so any new process that comes along is first looked at to see if it can be run from Tidal, whether that would involve purchasing another adapter or whatever else would make it work from here. We want it to be an automated function as opposed to being run manually and not integrated with the scheduler.

The technical support is much improved. That's over the course of 15 years. Tidal has gone to great lengths, with the transition to STA, to strengthen its support capabilities and also strengthen the relationships it has with its clients. STA seems very interested in trying to focus on a direction, advertise that direction, and make the current clients comfortable. That, in turn, will help them take on new clients.

As I mentioned, we came off of Maestro. Back in 2004 or 2005, when we were looking at schedulers, Tidal was one of the solutions we demoed. Universally, we all decided that Tidal seemed to be the better candidate.

The setup was pretty flexible. We had to come up with our own ways of deciding how to group things and what our naming convention would be. 

When we first came up on the product, one of the issues that we noted was that the default sort for all of the jobs was alphabetical. That complicates the ability of the operators to visualize the order jobs should run in. To overcome that, we came up with a naming convention that puts a prefix on all of the job names with a number. So when we create our groupings, within a grouping it will list the jobs in the order that they run. Half of Tidal's clients wanted to see things alphabetically listed and half wanted to see them listed numerically, in the order that they run. The vendor wasn't willing to modify the product to give the user a choice of one order or the other.

I don't remember the original installation taking that long. It took us a while to actually build all of the job definitions. That was a lot of work. It was done within about a week. Once the equipment had been spec'ed out we had an onsite install here in the computer facility.

We've had to train a number of new operators and I don't think it's been a terribly big learning curve for them to understand how it works. The developers, in fact, self-trained in their environments and they seem to be able to maneuver fairly well. There are times I have to explain things here and there, some ways of handling things that are more convention. Those are things they have learned over time. But they seem to do all right with it. There isn't that much of a learning curve.

The only people who need to have the training would be the operations staff. I think there was a beginner's and intermediate course that we originally took, when we came up on the product. And then we learned things as we went. 

One of the things that would be beneficial though would be some training that incorporates best practices. You can go through the manual and it will tell you, "This feature does this," and, "these are the parameters that you need to put in," and then the delimiters, but it doesn't necessarily tell you the best use case for certain functionality. I've had a few people mention to me "Oh, you shouldn't do this, and you shouldn't do that." Well, where does it say that in the book? It doesn't. And that's the problem. There's a little difference between an instructional manual that gives you the nuts and bolts of how to do things, and something that's more tailored to best practices, or recommendations of things you should not do. And some of that has to do with the architecture behind the scenes. Users wouldn't necessarily know that unless there was some documentation expressing it.

I don't really have metrics for ROI. It's more of a feeling because we've been able to consolidate from all these separate scheduling products into this one scheduling tool, allowing us to have direct dependencies between things. That's an efficiency in itself, but I don't have any statistics to support the number of hours saved and the number of dollars saved. Overall, it has improved our business model with automation.

My experience was that it was very difficult to figure out the licensing cost on an annual basis. I don't know if they've changed the model, but I remember it would take a month to reconcile if we were being billed the proper amount because it was based on the number of CPUs; if they were test CPUs or production CPUs. I recall, and this was probably five years ago, that it was very difficult to reconcile the annual statement with what we had, and to verify that they were components we were using.

Our ability to budget for the solution is a fairly easy aspect of it. One of the difficulties that I have internally has to do with the specialized adapters. I don't think it's well known within my company that I can't just snap my fingers and get an adapter. There's a cost associated with it and the license key has to be updated after we've made the outright purchase of it. I don't think there's familiarity, within our company, of budgeting for the coming year if it involves these additional Tidal components. That's nothing to do with Tidal. That's just an internal struggle.

There were five solutions we looked at in total. Two were ruled out right away. When we went to do demos with the three of them, the third one couldn't even do the demo, so it came down to Maestro and Title.

One piece of advice I would have is that if you get into a product, try to keep it upgraded. It's to your benefit, support-wise to be, maybe not on the cutting or the bleeding edge, but close to the current version. That's been a pain point for Tidal, to try and get their clients up to speed.

Stay on the latest version because of the functionality. It's not only relevant to just this tool, but to many IT tools. It's just like the next generation of laptops that are coming out; they're coming out more quickly. The same thing is happening with the functionality that is being added to all of these products, including the scheduling application. It's important to go through the pains of staying up to date.

It's been a good product. We could have done a lot worse. This is a heck of a lot easier to use than some of the other schedulers that I've used in the past. But, then again, it's been proven as a solution, as well. Other solutions are all moving targets. Everybody is making changes in their products. At the time that we made the selection of Tidal, it was definitely constructed a lot better. It was easier to use than the other option.

In terms of the number of users in our organization, I honestly wouldn't mind if everybody in the company had an account to log into Tidal with inquiry access. But I think we've got around 300 accounts set up in each instance. They could be used by managers, developers, operators, and all the other IT folks who have accounts.

For deployment and maintenance of Tidal, since we're doing a 24/7 staff, we're talking about eight people, and three or four other people who are going to be part of production control and/or an IT server ops-type of functionality, because you need that level of support as well from time to time. So we have twelve or so people in one capacity or another maintaining Tidal.

I would give Tidal a solid eight out of 10. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using it for the last three years.

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

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

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

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

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

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

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

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

The deployment takes a couple of days.

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

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

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

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

We have seen return on investment.

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

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

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

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

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

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

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

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

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

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

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

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

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