Tidal Automation Reviews

Our largest use cases are for the execution of SAP and JD Edwards jobs. Then, there are a lot of other technologies, however, in terms of the Pareto principle, really that's the bulk of our processing. SAP is what we use for our manufacturing and operational type stuff with the actual products. JD Edwards is a lot more of financial reporting and projections and things like that.

We use the solution to run SAP and JD Edwards. Windows and Unix hosts are probably the second most common use case, as well as web services. Any REST API would apply - and we use a lot of REST API technology. Protocol, really.

Primarily the biggest thing is giving visibility to what, in a lot of places I've worked in, are transparent, like invisible processes. You have this massive batch and, unless you have someone watching that and you have a place to have a single point of truth and say this is successful or not, it makes it very hard to trace things. With Tidal, you can say, "Hey, this is the objective notifications," and all the ones you explicitly want are checkboxes. It's easy to add those things in.

Having a single pane of glass, regardless of which technology we're talking about has been great. A lot of time, I'm in middleware, so what will happen is people will want to say, "Oh, it's this part or that part or the other part." You can see all of them side by side in Tidal.

It talks both to web stuff, which is helpful. Everything you want to talk to is there. If you have stuff that's still more 20th century and you want to run it at a command line, you have that available to you as well.

We use the solution for cross-platform, cross-application workloads. That's the biggest use for us and that's the biggest advantage.

Our impression of the solution's ability to manage and monitor workloads has been good. It does what it's prescribed to do.

The solution enables admins and users to see the information relevant to them. One of the other features that we use a lot is really a part of web services. We talk to ServiceNow. We have specific metrics to go with failures for major incidents and things like that.

The solution’s drill-down functionality so that admins can investigate data or processes has been super useful. It allows you to instrument for teams at their skill level. As an admin, I can say, I don't let you see these certain elements as you don't use the other ones and that simplifies how those technologies work. You don't have to have everyone see everything. That part's really helpful.

The solution has increased capacity in terms of the number of jobs and integrations. For example, in one of the things that we run, we actually had to expand how big the queue was as they wanted to run 300 parallel jobs. Historically, we hadn't run three parallel jobs for the whole company. So the scaling of that was just 15 minutes. Then, boom, everything was ready to go. It scaled pretty easily for us.

The teams that are smart about the Tidal usage, that basically will get it to the point of human intervention, save a lot of hours, especially when it comes to log gathering. That kind of stuff now is automatic for them. That saves a lot of hours.

Honestly, the biggest problem we have with it is people's interpretation of the results. It gives you really good information and people sometimes are just not really good at working with that information.

The GUI, the graphical user interface, gets a little bit busy. You have these flyouts that sometimes are a little tedious to get through. They need to look at just ways to simplify the graphical user interface a little bit. That would be good.

I've used the solution since 2009. That's 13 or 14 years.

The stability is very good. Almost every time where we've had an outage, it had not been due to the software, rather, it was some element of our infrastructure failing. The most common failure for us is we lose connectivity between the database and the application. There's not an app alive that's not going to have some problems when you can't connect like that.

We split users primarily into four roles. The viewers can't do anything other than see what's happened. There are also operators, which are people that can rerun jobs, yet can't modify anything. They're a little bit ahead of a viewer. Then you go into being a developer, which can write jobs in non-production. Finally, my admin team uses it. They keep it all running. The fattest part of the bell curve, the biggest user there is, is the developers. Overall, we're between 1200 and 1500 users. The admin team is six people, and the developers are about 800 of them.

We're worldwide. Unless we get some off-world friends to introduce themselves, I don't have a lot more room for expansion. What we're seeing now is people wanting to stand up more masters for more autonomy. I see us expanding into China, which is going to be a pretty nifty little trick since there are a lot of restrictions on communications there. That's about the only expansion I see for us. Obviously, there is increased job usage. However, in terms of expanding the footprint of the platform, that's only in geographic regions.

Technical support is better than average. It's not stellar yet. They're still working out some kinks. They've got it a lot smoother. I've had predominantly good experiences, just not perfect ones.

Positive

We used AutoSys before. I'm familiar with that tool as well. The big factor in switching was the license model being just a lot more predictable. Then, as a result of that, it was for the number of features that Tidal had. It was significantly more powerful at a lower cost. It wasn't just the cheapest. They were pretty close in cost when we got it all down to it. It was still less expensive, however, also had the more advanced features, in particular REST API, which was super duper expensive with AutoSys. It was a license model that made it very hard to predict the growing cost, versus Tidal. With Tidal, at least in the model that we had, it was very, very stable. We just renewed for another couple of years recently.

The initial setup was straightforward. You essentially need two servers and a database. At its heart, it is pretty simple to set up.

The deployment took three weeks. We deployed in three separate geographic regions. We just did one per week and then gave people time to get comfortable with new steps. We just did it in sequence. We installed, for example, for Japan, then for the United States, and then for Europe.

Learning it is pretty easy. It is a narrow learning curve for operators, for people that are just going to run and monitor. It's a little steeper of a learning curve for an admin to instrument new user groups.

Depending on how fast they read, new users can get up to speed in between one and two hours. We have a one-hour interactive training platform called EdCast. They do a one-hour EdCast that says how it works and then there are two other documents they read that specify and call out how their specific technologies work.

We did use a third party for deployment assistance. Our experience was very good. They are very knowledgeable about the product. They were a good partner. They helped us sort out the boundaries between when there's an error and when you've misconfigured it, and it's just telling you about it. They were very good in that regard.

We have seen ROI in the sense that it's primarily about our ability to stay flat in cost while constantly increasing our volume. That's the biggest ROI that I see.

For me, the key aspect was the linear predictability of costs. I know what handles I have to do, what things cost what. When we renewed having a regular cycle of renewal and re-evaluation kept us on track. For the years that we've been using it, we've had an increase in growth, yet we haven't had exponential increases in cost, which is really good.

Just say from 2009, when we started with it, up to now, we've gone from 5,000 jobs to fivefold. We're at 25,000, 30,000 jobs. However, it wasn't like my costs went up fivefold or tenfold. That was really good for us. That was really important.

The total cost of ownership, given its capacity for jobs and our ability to control infrastructure costs, have been very good. Having stood it up in AWS and having a group that's very active and having those sizings be very easy, what I'm finding is that the hardware requirements and thus the cost stays pretty low for the amount of stuff we're doing, and Tidal seems to respond well to our ability at the AWS layer to change that hardware without really having too many problems.

We are a customer and end-user.

I don’t know if the solution helped reduce or eliminate weekend or overtime hours as that doesn’t really apply to me. We're 24/7. There's no such thing as a weekend for us.

I'd advise new users to not underestimate the way that people will want to blame a tool for something they don't understand. Tidal will display errors from other systems and you need to be prepared for separating a Tidal error from Tidal reporting an error. That's the biggest learning point that you want to have in your head at the beginning.

It's a good idea to define the lanes of responsibility. That's been almost the entirety of my career, maintaining the lanes of responsibility through Tidal, as it's cross-platform, it's cross-technology, it's cross-team. You really have to be able to sort out the difference between a psychology versus a technology problem. It's the way someone feels about what's on their screen. It's been very helpful for that, however, it's probably a similar problem for anything like this. Tidal just makes it so easy to see those things yet oftentimes it gets blamed for stuff.

I'd rate the solution nine out of ten.

It's a company-wide batch scheduler.

It runs tons for us. It runs Windows, Unix/Linux. We connect with a lot of databases: Oracle, SQL, Sybase. We have BusinessObjects BI adapters, we scan emails, and we incorporate it with TriZetto Facets healthcare solutions. There's so much. It's our core enterprise scheduler.

It helps because we have brought in a lot of other applications and systems where we're able to use an enterprise-level scheduler that is consistently monitored and backed up and has a ton of redundancy so that we don't have any downtime. We're pretty close to 99 percent uptime on our scheduler.

It has reduced some of our weekend and overtime hours. For us, it's all based on the programming around the scheduler. For some teams, it has greatly reduced weekend and night hours, but for some people it hasn't because they babysit the process.

Tidal has also helped us increase capacity in terms of the number of jobs. Over the last three years we've added between 10,000 and 15,000 jobs.

It's very

• user-friendly
• intuitive
• robust.

Most people, once you give them a quick tutorial on it, can figure out how to use Tidal. For the basic user and developer, it's very intuitive. I don't think it's very hard. I teach users how to use this in a quick, 30-minute conference call, and people are usually very quick to learn it. For a basic user, 30 minutes should be fine.

We use the solution for cross-platform and cross-application workloads. That's one of the core reasons we chose it. It's one of a few things in the industry that can be used for cross-platform integration. It has the schedules to monitor the workflow. We have a 24/7, 365 department that monitors the batch schedule. It's fairly easy and intuitive and we could easily set up the alerting systems around it.

Admins can do more because they have more access but you can set that up the way you would like it. That's all configurable, at least in the GUI. In the back-end, obviously, it's only the admins who have access. But both admins and users can see the schedules.

The drill-down feature makes the GUI interface and the scheduling interface load faster because you don't have as much to load into the screen. I personally use it more, but I do know a lot of users don't. It's all dependent on user experience and how much they choose to use it.

Before STA bought this product, Cisco owned it and, unfortunately, they did not update things as well as they should have. We're just now seeing improvements to the product and bug fixes.

The biggest improvement they need to work on is doing better QA checks before they release new patches and service packs. We do find that you can't trust getting the new product right away, as they have to get some bug fixes out. They do tend to have some bugs in the first iteration.

In addition, something that they already know about is that speed can be a little bit of an issue in the environments and the viewers.

And while everything is nice in the GUI interface — they recently upgraded it — they could take it a step further. I would like it to have more flexibility and the overall look of the product could be better. Before this recent patch that we're doing to 6.53, in the 6.5 series it still looked like a product from the 1990s. They recently did a mini-refresh on graphic user interface, but it still looks a little bit clunky. It doesn't look as smooth as I would expect from a 21st-century product, but it's getting there. But this a secondary item, versus the speed and working on bug fixes.

I, myself, have been using Tidal for six or seven years. Our company pretty much runs all of our core processing through scheduling. Tidal is the default and has been the default for many years. So it's hard for us to come up with numbers for how it's improved our operations because we're not a company that just brought Tidal in, brand-new, and it suddenly revamped our company. We've been using it for close to 20 years and I enjoy the product very much.

Tidal is pretty stable. We haven't had any major issues, at least in the last three years that I've been working here, and especially since we upgraded. We haven't had many major issues, and we do have redundancy, which is great. We have redundancy for the primary master backup master, and fault tolerance. That that helps with keeping things stable. As of mid-year 2020, I am decreasing the product stability from 8 to 6 stars due to the amount of bugs we are constantly facing.

It's very scalable. As the company grows you increase the resources. I've worked at a small company that has Tidal and I'm now working at a pretty big company that uses Tidal and it all works pretty seamlessly.

It's pretty extensively used in our company. We have 25,000 jobs in production, and we keep growing. We keep adding jobs.

We have about eight engineers who create jobs and we have about 10 people who are operators who monitor the production schedule. And we have 200 to 300 other users who are developers. They create code that integrates with Tidal and they work with the engineers to create the jobs in Tidal. They access Tidal to view and check their jobs.

We have an architect and two admins to keep the environments up and running. We have the eight engineers who create, monitor, and edit the jobs and the general environment. They are on-call as well. That's the core team for Tidal. And the NOC manages alerts if something happens, to reach out to the on-call people

Technical support is great. They're fantastic. They're very responsive and detailed when we ask them questions. A big thing that I like since STA bought it is that their support has been very responsive and very quick.

Each upgrade has gotten a little bit better. I remember back in the day, when I first started working Tidal, upgrades were a pain, but they're slowly making improvements on the upgrades. One thing I would like to see them improve a little bit on is the documentation, because some parts of the upgrade are not exactly clear and I've had to go through support to help me on what to fill out in certain parts. But their support is actually fairly quick and they have been able to help me with it.

We've done major upgrades, and that's always a multi-month process because you have to do the change-process testing. That depends on the corporation. But the recent upgrade that we're doing from 6.35 to 6.53 has been going really well and has been pretty fast in terms of the actual setup and installation. Other than a little snag that I had to work through with support, it has gone very well. To upgrade each environment has taken an average of an hour-and-a-half to two hours.

There is some very complex strategy for updates. The main thing is to start with the lower environments and back up everything, the database and the servers, and go through each environment in a slow and steady process. We come up with a testing plan before moving on to the next environment. We have to make sure we test each environment thoroughly, over time, before moving to production.

When we did a major upgrade about two years ago, we used BLUEHOUSE to help us, when we went from 5.31 to 6.3 That was a major change. But ever since then, we have been handling each integration or upgrade in-house.

We purchase a seven-year contract. Once that's up, we'll look at renewals and costs and compare them again.

The main thing is to look at whether you really need an enterprise scheduler in general. After that, implementation is very important. Setting up standards from the beginning for the scheduling and the jobs is very key. My biggest advice is to analyze all these processes and come up with a good plan for how to incorporate everything into your scheduling. That would be one of the most important things for Tidal or for any scheduler in general. From the admin side, for the technology itself and the technical stuff, work with and trust Tidal support at the beginning to get to a certain level of how to scope everything out, and then go from there.

I'd rate it an eight out of 10. The main thing is whether or not they come out with a better rollout of their upgrades and patches so that they are less buggy. Unfortunately, they still do come out with a consistent number of bugs. They also need better documentation at the admin level. Those are the two core areas that they're truly lacking in, and a little bit on speed. However, the newer version that we're still testing is supposed to take care of that. We'll have to see when that comes into play.

We primarily use Tidal Automation to schedule batch jobs. 

We are a solution provider and the automation that we implement is for our clients.

Using this solution has improved the way our organization functions because support is available whenever we have problems.

The most valuable feature is the job scheduler, where you can schedule thousands of jobs to execute at specific times. It will schedule dependencies as well.

There are several improvement points that our team has provided to the vendor. 

Our client has been running Tidal Automation for more than three years. We started taking care of it for them between two and three years ago.

This is a stable tool and we use it extensively.

We have thousands of jobs that are scheduled in a batch and run using this tool. It is scalable, and there are a few hundred users.

Our usage may increase to some extent but maybe not because there are competing forces.

Our team is in touch with the product team and whenever there is any problem, we reach out to support and they take care of the issues.

As we are working for a client, we have an arrangement such that we can raise tickets with the vendor. Once we do so, the problems are addressed.

Overall, the support is good.

We did not use another similar solution prior to Tidal.

The initial setup was completed by our client's team.

We do not maintain the system, aside from the case where an upgrade is needed.

It does generate ROI but I do not have specific metrics available because it is known by my customer. When a customer continues to use the same product for a number of years then it seems that they are happy with the return on investment.

I would rate this solution a seven out of ten.