Tidal by Redwood Reviews

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.

We're running jobs on a global scale. Being a global company, we're running scheduled jobs and ad hoc jobs across different regions. Jobs cover backend processing, financials, and the like. We're running on an SAP ERP system and we're also running Informatica for data warehouse. We're running BusinessObjects web reports as well as a lot of straight Windows and Unix command-line things. We run FTP processing, PGP encryption processing, and data services jobs. We're running about seven or eight of the different adapter types that Tidal has available.

We have it on-prem. Both our test and production environments are on fault-tolerant setups.

When I started here, they had already been on Tidal for about five years. So I'm not really sure where they were before Tidal. They did a lot of mainframe things in the past. From what I've heard from people here from the "old school," once they globalized and got everything into Tidal, the ability to see everything across the scheduling universe was a huge improvement. They didn't have to give different people different access to different systems and check four or five things, just to make sure something was running correctly.

The solution helped to reduce weekend and overtime hours. We're a 24 by 7 support model. Regarding the Tidal application, the one thing that we try to explain to anybody, from a support or monitoring standpoint, is that jobs trigger through Tidal, but not physically in Tidal. So if we have, hypothetically, an SAP job failure, it's not a Tidal failure, it's an SAP failure. So it goes right to SAP support, which saves time. In the environment I came from, they didn't have that mentality. So if, hypothetically, an ERP job failed, they'd call the Tidal person first instead of the ERP support. That type of understanding, as a whole, really helps from a support standpoint. The admins don't get a lot of calls unless there's an actual issue with the Tidal application itself.

In the time I've been here, we've definitely increased staff availability. From a business standpoint, we've started utilizing file monitors more, for what they call "file events" within the application. In the past, when an end-user would drop a file in SAP, for example, they'd contact our operations team, or send an email saying, "Run in this job." There isn't a real need for that in many cases. We've implemented a lot of file events that will actually only run jobs if they need to, if a file's available. Along the same lines, we had processes that would run a process in SAP, and even though it didn't create a file, there were other jobs downstream that would be hanging out and waiting for a file that never showed up. So not from just a staff availability point of view, but in terms of resource availability, it has definitely improved things a lot. From an operator standpoint, I would estimate Tidal is saving us 15 to 20 hours per week, just in manual interaction with inserting jobs on a request, since a lot of that stuff was implemented at our end.

Regarding job counts, we're pushing over seven million a year. That varies, obviously, depending on request jobs and other things. There are some processes that we shut down for year-end processing, so they stop running for a week or two. But from an expansion standpoint, we are constantly looking to see where else we can use Tidal, for new applications that are coming online or things that people are running on their own where they haven't even thought about Tidal's scheduling. In 2019, we did 7.7 million jobs. In 2018, we were at 7.1 million. In 2017, we were at 6.1 million. So with Tidal we're adding on the order of half-a-million jobs per year.

The feature that I find to be valuable, as I'm working with other folks, is the ability to cross-schedule across platforms, and the flexibility that comes with that. I'm kind of biased, as I've only used Tidal. I haven't used CA or IBM or any of the other scheduling platforms that are available on the market.

From a management standpoint, when using the solution for cross-platform, cross-application workloads, I've never had a problem with the application. It's very interactive, especially with the different security levels that they offer. We have two or three operators who are at a certain level where they can actually rerun jobs. If they fail, they don't actually have to get ahold of a Tidal administrator. The only thing they don't have access to is changing the master settings on the jobs. That flexibility of access is a big plus.

We do have a few developers who will actually set up processes within Tidal, but only in the test systems. They get a little bit more access that way, but they obviously have to have training prior to that, from me, on how to properly schedule things in Tidal. So the security and flexibility are valuable features.

They have a lot of pre-set stuff, but you can actually create something like: "Run the third Wednesday of every third month on a blue moon," going to the extreme. Their scheduling functionality is really advanced enough where we can create a lot of different kinds of customizations, based not only on a regular calendar year, but on fiscal calendars and regional calendars. We have jobs that process files for our EU operation and when they have a bank holiday over there we don't need to run the job. We can tie up those jobs that don't need to run on their local, European bank holidays.

The solution also enables admins and users to see the information that is relevant to them. The admins have super-user access, so they can actually adjust and transport different jobs from test to prod. Whereas the operators can adjust a job that's already scheduled if they need to, based on direction from support. They can change this variable, or change this setting, or change this text. But they don't have the access to actually change the master copy of that job. So, a one-off change is literally just that, a one-off change of the next compile scheduled. Otherwise, it's going to run as it's normally set up.

Another good thing that Tidal has is in regard to the history retention of job failures. Whereas our SAP ERP system usually has an eight-day history retention for jobs, Tidal can actually go back longer than that. So if somebody says, "Hey, why did this job fail three weeks ago?" we can bring up the failure message, which is something they can't do directly in SAP.

For the most part, the drill-down and the logging are really good. But if we take an Informatica job, for example: We have the ability, and the operators have the ability, to actually drill down and see, at a session level, where the failure is. There is, unfortunately, no way to extract that into an actual output email or failure email. It's not that that information is not available, but extracting it into an email would be a nice-to-have. It's minor, but it would definitely be a help. In the grand scheme of things though, you can drill down to session-level failures and get that error message to provide to support. 

Another thing has to do with job events. A job event triggers when a job completes. It sends an email or reruns a job. Right now — and I've even talked to Tidal about this — it will run all the events at the same time. It doesn't provide the logic to say, "I want this job to rerun five times. If it fails on the fifth time, then send an email: 'Out for Failure.'"

The only other thing I would like to see is an easy way to flag jobs running longer than a certain percentage of the estimated time they should take. Right now, you can hard code in a max expected run-time and you can trigger a notification off of that. The unfortunate thing is, in a consumer product-related business such as ours, Q3 and Q4 jobs are going to run longer. So you can't really put a hard-coded expected run-time, because that's going to fluctuate. So it would be useful if we could specify something like "Flag this job if it runs 25 percent longer than estimated," which the solution does track for 30 or 35 days. That's what they usually recommend, out-of-the-box, for keeping track of history.

I have been using Tidal for about 13 years. I used it for about eight years at my previous company and then I came over to this company.

I came on about four-and-a-half years ago here and Tidal has been really solid. The high-availability and the fault monitoring they use is very good. I can think of twice, in the last four-and-a-half years where we've actually had to failover for one reason or another. And the bottom line was that it wasn't even a Tidal issue; it was something to do with patching. One of the patches from Microsoft was a little funky. From a stability and support standpoint, this is a rock-solid app, in my opinion.

It's very stable, especially for those who utilize what they call Fault Monitor or Fault Tolerance. When we do patching, the jobs, in and of themselves, automatically fail over from our primary to our backup. There might be a slight disconnect in the web UI that the operators use, but that maybe lasts a minute because of the cut-over time. But it picks up all of the backend PIDs, and the jobs just pick up where they left off. From a stability standpoint, this is a really good product.

From what I've seen, the scalability is very good. There are companies that I know that run millions of jobs a day. I've been through some user groups that have some people running nine different instances of Tidal, and they're running a lot of different things. So, the 7.7 million a year we run here, coming from where I was beforehand where we were running about 400,000 a year, seems like a lot. But we're still a small fish in the barrel compared to how other Tidal customers are using it.

So the scalability is phenomenal. We're always looking for that next hook and working on trying to tie into other things. We're keeping our versions updated as much as we can, in regard to OS compatibility. Take Informatica, as an example: We're making sure that we're as up-to-date as we can be with the versions that are out on the market.

In my previous company we used the Lawson ERP's internal job scheduler. There were Windows tasks that we had to check on. They were running a lot of VB6 stuff. In my current company, I came onboard years after they had already cut over to Tidal. I know they had some mainframe stuff in the past, but I don't think they converted from something like CA to Tidal. Tidal was their first choice.

I came in at the tail end of the initial setup when I first started with Tidal back in '07. The decision had been made on the application before I got the position of scheduler in the Tidal admin. In terms of the actual setup, I was on the periphery. Once it was set up, I got more involved. But I have been involved since then with the system upgrades and version upgrades.

Upgrades seem to be fairly straightforward. When it comes to hotfixes and partial, mid-version updates, it's pretty simple. You don't have to call the vendor in. When it comes to versioning upgrades, like when we'll go from 6.3 to 6.5 in a couple of years, we do utilize a third-party vendor to come in and assist, because they do a lot of backend database cleanup and scrubbing. We're running in a SQL database for Tidal, and I know just enough SQL to get me in trouble. So we do rely, especially because this is such an enterprise-based application here, on having a third-party come in and take over the upgrade part of it. We work in conjunction with them, making sure jobs are set and that the copies are good.

As for the learning curve, a lot of it depends on the individual's knowledge of the particular systems. Windows is fairly straightforward. If you know some Unix commands, you can help set them up really easily within the application, when you're setting up a job to run from the Unix command line. If you don't know SAP or whatever the ERP system of the company is, at least a little bit — enough so that you can navigate through it — there might be a little bit of a learning curve. But it's really not as big as one might think. Take the SAP ERP as an example. I came from a Lawson background. I came into the SAP environment here, which I was totally unfamiliar with. But within about a month, I was able to set up SAP jobs without an issue.

There are some little things involved in understanding how to up jobs if you want to overwrite certain variant settings. Learning to do that, and making people feel comfortable doing that, was probably the biggest learning curve.

The other thing is understanding using API hooks within Tidal to other processes. That's one thing they could improve on as far as their training materials go. I've talked about that with them during the past couple of user calls that I've been involved in. At this point it's still a little rough, but hopefully that will get better as time goes on.

The amount of training a new user needs in Tidal depends on the level they're at. We have a training program in place for our operators who do a lot of the manual reporting and failures, running jobs on request, etc. We'll start them with just an inquiry only so they can see everything that's happening, but they can't act on it. That way they can get a feel for the application. We'll give them that for about a week or so, and they'll work hand-in-hand with an operator who's been onsite and using the application. Then we can roll them out to a test version with test-operator access, for another week or so. By that time, they're through four weeks of Tidal acclimation and they're good to go with everything. Because of the operator's schedule — they work a four-on, three-off rotation, it's not like they're working five eight-hour days of straight Tidal — plus all the other things that are on their plate for their job requirements, they're not going to see every single potential issue that could come up. But they have a pretty good grasp at the end of that time.

We'll usually get a feel from not only the trainee, but also the person who is working with them, about how they are doing and if they feel that they're ready to start doing stuff in production. Generally, within a month, they're up and running as an operator, in both test and prod environments.

Developers are a different story because of all the different things that they have access to regarding scheduling and building schedules. We haven't brought on a lot of developers since I've been here. It would probably take a good two to three weeks for developer training, if someone wanted to know how to set up a job in Tidal. We'd really try to hand-feed them little things, so they don't inadvertently schedule a job, or an entire job group that runs hundreds of jobs, which could really bog things down from a systems standpoint.

The partner we use is a Tidal partner called BLUEHOUSE. They've always been very helpful and very flexible in terms of scheduling. The way we do it here is we'll have them come onsite to update our test system. We'll bring that up online and run that on the new version for two months or so. Then they'll come back and we'll do the production update. The whole time onsite, between test and prod together, is about four or five days. But they do a lot of the prep work for production, while we're doing the test upgrade. When we're ready to go to the production, they're only here for a day or a day-and-a-half at the most for the production cut-over. When it comes to initial support right after the fact, they're very receptive to fielding the questions.

I would say we have seen a return on investment by going with Tidal, and not only because of the volume of jobs we're running, but because of the variation of jobs that we're running. It gives us the ability to manually adjust processes on-the-fly, and having that visibility and quick reaction to failures has been a big plus for us.

At my previous company they looked at IBM, CA, and one other solution. The reason my old company went with Tidal back then, was that it was the only one that offered integration with Lawson.

As with any product you're looking at, first of all, don't get pigeonholed into it. Don't have a laser-focus on an individual product. But with Tidal, especially now that they're rebuilding the customer base, reach out and work with their salespeople, and network with current users. One thing I found, especially being on some of the network boards — they used to have a Yahoo Group for Tidal — people aren't afraid to say, "Hey, this works great and this doesn't." I'll be the first to tell you what works great and what still needs some work. And now that Tidal has put its own forum together, the company is monitoring and responding to concerns and questions a lot quicker than they used to when they were under Cisco's umbrella.

The biggest lesson I've learned from using Tidal is that it's always growing. In user calls that we've had since Tidal went back to its own environment, they're really looking to rebuild and invest in the application, and make sure that things are up to date and validated. They're working on making sure they're as current as they can be with certain connections. 

It's like they have a renewed vision since Tidal was divested from Cisco. They seem to have a real yearning to get back into the way things used to be in the pre-Cisco days. I'm not trying to knock Cisco, but it is what it is, because I worked with Tidal before Cisco acquired the product. Now with the STA Group and a lot of the older Tidal developers and folks "back in the saddle," there seems to be a renewed interest in rebuilding, making it a lot easier, and opening up a lot more process availability for users and customers.

We've got a handful of developers, five or six people, who actually have the ability to create jobs in our test system. We have a team of six operators who have access to Tidal as well. They do the 24-hour monitoring and ad hoc jobs, etc. And we have two Tidal admins. We do have some other folks who have inquiry access into our production system. We'll give people who might be developers in our test system view-only access to prod. Overall we have 15 to 20 people who have access to the system, with varying security levels. I'm responsible for maintenance, upgrades, job migration, and production. I also work with people who don't have access to Tidal and on helping them get jobs set up properly. I also make sure we get the email notifications correct.

For what we're using it for, and what we have, it's very good.

We use Tidal to run jobs across multiple application platforms, such as SAP, ECC, PDN, and Informatica, as well as jobs that run in Azure cloud. We also use it for several warehouse management jobs with OS/400 and AS/400 connectors. We have a lot of different types of connectors, then we are bringing all these jobs into Tidal so we can set up dependencies between jobs that run, e.g., an SAP job and a OS400 job may be dependent on each other in some way, allowing a cross-platform job flow.

We are currently on the most recent version.

We are using it for cross-platform workloads. That is probably the biggest reason that we are using it. The solution is generally good. Over the years, we have needed to do our own learning about how to manage it in terms of understanding dependencies and successors, then setting up times and so forth. However, this is the type of stuff you would have to learn with any scheduling app. We find it to be really useful. I'm hoping with the Explorer tool that they'll have better reporting so we can do some full cross-platform job stream reporting that they haven't really done much in the past. Therefore, we should be able to see some of that. In terms of managing it, I find it very useful other than the learning curve.

We use cross-platform management for so many things. We use it a lot for our warehouse management replenishment type things: to and from SAP. Once we implemented our job stream flow, things gets sorted out of house for delivery and can be update in SAP (and vice versa). Having the job stream has been helpful. Also, having it all automated makes a difference to replenishment. 

We use the ability to enable admins and users to see the information relevant to them specifically in our production environment. We can, but don't always, limit someone to only seeing data that they need to see. Then, they are not overwhelmed by other data. We do allow most of our users to see all the other data just for information and to understand the environment. However, you can begin to narrow in on what you need, if you're using policies and work groups correctly. Depending on how we use it, especially in production, it lets users only be able to do what they should be doing in production. They should only be managing their jobs, possibly see other jobs, and understand if there is a delay upstream which could be impacting them. They won't be able to manage those jobs. They need to contact the right people who understand those jobs to manage them. The solution lets them work within their lanes and do the work correctly without having a negative impact upstream, and hopefully, not downstream. 

There is an awareness that we are scheduling across the multiple applications and understanding that all applications don't live in their own silos. There is an impact across the organization. It gives us that holistic awareness, in general.

In the past couple of years, I have done education and we have leveraged creating alerts that go to the right people. It has allowed us to do that. Therefore, I don't get alerts for something that I shouldn't be dealing with. Now, people who own the jobs get the alerts and they can figure out if there is a problem with the application that they need to work with or if it is something with Tidal. Then, if necessary, they can elevate it up to me. Fortunately, that doesn't happen as much anymore, which makes me very happy. It gives us the alerts in time so we can handle things ideally before they become critical, and hopefully, we're doing our jobs so the right people are contacted.

I love the "where used by" feature where you can find out where a particular job action, job event, or even a connector is being used. That is really good. 

I've seen a lot of improvements in the logging. It has become more useful. 

I'm looking forward to working with Explorer and Repository. I haven't had time to implement those yet, but I'm pretty excited about both of those tools. 

We get a lot of use out of variables within Tidal to help schedule jobs, help track things, create alerting, etc. I find those variables have a lot of use.

The solution’s drill-down functionality, so admins can investigate data or processes, depends on what we are looking at. In some places, it is better than others and getting a lot better. In the five years that I've been supporting this solution, I've seen them get much better at allowing us to get more detailed information in the logs and job activity. 

I'm still hoping with Explorer to be able to see end-to-end job streams. That's not really something that's easy to see today in the web client. However, I haven't worked with Explorer yet. One of the things that we have found frustrating is not being able to see an end-to-end job stream across multiple applications within Tidal. We use jobs for that right now, but I have high hopes that we'll be able to see that in Explorer.

The reporting piece needs improvement. They are working to improve it but this is the piece that they can continue to work on. By reporting, I mean things like end-to-end job streams, historical reporting over the long-term, and forecasting. Those are some areas that I've expressed to them where they need to up their game.

We have the transport functionality where you move ops from one system to another. Right now, it's a manual process. I would love to be able to have more automated transports. Then, I'd love that to be able to tie this into our ITSM system so we can have change approvals, which are then approved, then transports automatically happen. 

It feels like forever. We have had it at Columbia Sportswear for seven years. I have been supporting it for five years.

The stability has gotten a lot better. Every time that they level a version up, there are a few months where it is a little rocky, especially because they are trying to make some real changes on the back-end. Sometimes, I'm guilty of being a bit too cutting edge with the patches that I put in place. I have learned to hold back a little and give it a couple of months. Usually by that time, they have worked out the bugs and things are pretty stable. I would say this about any system.

I'm the only one who supports Tidal, then I pull in a dev person. There is usually one person involved with setting up the VMs. However, they have that automated so it is just a request for a standard set of servers. They just push a button and the servers are built. When we get to where there is QA testing, we're usually trying to align that with a lot of other QA testing. Therefore, people are naturally testing the system as they would with any other work that they are doing. Essentially, this is all of our schedulers, which are 15 to 20 consistently. I'm not asking them to do anything that they are not already doing, except tell me if there are problems.

I have a very loose backup person but I'm very motivated not to get calls on the weekends or vacation, which is why we built in our alerting systems. We try to keep them strong, so before anything gets to me, it's been vetted by the people who can solve the problem if it is job-specific. If Tidal itself goes down though, I'm the one who gets called because I'm the one who can fix it.

Tidal does a good job. We periodically have them do a performance review every six to nine months by sending them our logs. I open a ticket, then send them a bunch of logs. They take a look at them and we do any necessary tuning. We have discovered over the years, going from a small to medium to high-medium organization, that Tidal is very responsive in terms of helping us figure out how to tune systems so we have the best performance. It can handle very large scale organizations job-wise. It is just how you tune your servers, and they're very willing to help with that. The best thing that a person can do is work with Tidal support to find out exactly what is necessary on the back-end to have their system scaled out correctly. It can be done. We run about 8,000 jobs in production, but I know there are some systems which run tens of thousands of jobs of production. We haven't hit a scalability issue at all.

Regularly, 20 to 30 people use it in our organization on a week by week basis. We have about 100 users in the system. Their roles are developing, creating jobs, QA, testing job scenarios, events, and actions; everything around developing a job or job stream. Then, we have our service desk people who do the transports from QA into production. There are about four people who do this.

In production, people from each scheduling team are responsible for the health of their jobs, which can include if there are issues with the jobs running, maintenance that they have planned, setting those jobs on hold, asking me to put an outage on an adapter, rerunning jobs, or disabling/enabling jobs. It is general job development and job management.

The standard tech support at Tidal is very good. You can call or open a ticket, if you get stuck on something. They are usually quick with answer or at least quick to respond to you with more information. When I have gotten stuck, I have always been able to get help and get out of it. I once spent eight hours on a weekend call with one poor guy. 

The reality is you will always have issues that you have to escalate. That is just the world that we live in. 90 percent of the time, I have had a very good experience and gotten what I needed. I have been able to get support people on the phone. If we find something, and they haven't seen it, they are good at pulling in development. They are good at saying, "Okay, this is new. We will put it in a development." Now, with their new website where you can see your tickets and track things, they make it a lot easier. If you have a bug that is in development, you can track where it is and when it will probably be released. Now, there's a lot of transparency that makes it comforting to know your stuff is being worked on. These are improvements that they made as they moved away from Cisco. 

When it was supported by Cisco, it was okay but it wasn't as good. Since Tidal broke away from Cisco two years ago, that was when we saw the most improvements in terms of things that we had been asking for and the delivery on them. 

I think we had a variety of solutions that were sort of stitched together.

Its setup is around mid-level complexity. You need to do a little reading to understand how Tidal works. You need to understand things like connectors and the whole fault tolerant environment, but the data is all there to get to.

Whenever we are moving to a new operating system, I work with my infrastructure team to get new VMs built up in the right OS. I start to set them up with all the things that I need in order to build Tidal. At this point, I usually get a demo license from Tidal as I'm doing the build. This way, I can build and test but not take up a license. Then, when I'm ready to go live, I always go live in development first to QA, then production. So, I have a cut-over from the old system to the new system, then we migrate our database over. I work with my DBAs to do that. Then, I do testing in development to make sure everything is right, doing the same thing in QA. I also do more rigorous testing with the schedulers, then eventually it goes into production. It is about six weeks from development to production.

The migration to the cloud has been an extensive project. It is going generally well. A lot of what was running in the Informatica environment has now been shifted over into the Azure environment over the last couple of years. That is where some of the migration has been occurring.

The initial setup was done by somebody else who no longer works with the company. Since then, we have moved to new operating systems over the years. These are always new systems that we build up, then migrate from the old system to the new system. I've set this up several times, so systems that we are currently running are the ones that I've set up.

Thinking of all the people involved in checking jobs on a daily basis, manually running jobs or auditing them through standalone tools, and trying to connect them. We have saved hundreds of hours weekly, which is substantial.

I am able to create something predictable and manageable in such a way that we know that we will get alerted if there's a problem and know how jobs are going to run. People can see and manage their jobs on a daily basis without having to talk to me about them. The return on investment is scope of jobs, making it so the management of jobs is not something that is handled by one team. It can be parsed out to the schedulers who know and understand those jobs so they can have some control over them, then I don't have to worry about all the different jobs streams. I just have to look from above and be able to help make sure that the system itself works. 

Our yearly licensing costs are between $10,000 to $20,000. They have always been reasonable with us. I like that non-production licensing is about half the cost of production licensing. Licensing is by adapter typically. We have had scenarios where we have had to take an adapter from one environment to another, and they've allowed us to do that. They have made it a very reasonable process. There's definitely a feeling that they will work with you.

Budgeting is pretty predictable. They changed their model last time, which is why I'm not sure exactly how much it ended up costing. I know that our licensing guy did make a decision to license us in such a way that now we have a lot more flexibility based on adding VMs that can connect to Tidal and run jobs. So, it's not a problem to budget for it. 

We have on occasion looked at other options simply just to be aware of what is out there. We don't plan to change anything right now that I'm aware of simply because we don't have the time or budget. I'm not even sure we have the need. Every once in a while, we do look around because it's useful to go out, compare, and ensure that it's still something that fits our needs.

Depending on how you will roll it out, engage people who will be managing the jobs earlier in process so they are aware and can help plan how Tidal is used across the environment. That is something that I wish the people who had rolled it out had done. I don't know if that was even a consideration back then. There were definitely things that I would love to change about how we do our scheduling which are just so baked in at this point that it would be such a large change. Also, make sure that you engage and use Tidal's resources. They have some great resources and know what they are doing. Work with them, as they can help you figure out how to use this tool.

There are ways that it makes life more convenient in terms of ensuring the right people get alerted for issues. We are able to see job health, jobs over a couple of days, and have some predictability, but not as much as I would like to see in terms of forecasting. If we were to stop using it, we would go to something similar simply because it's so useful to have an overall scheduling application.

I have developed some training specifically for the learning curve. The basic job stuff is pretty quick, especially because we have a lot of people who can be leaned on. When you start drilling down into things like using variables or more ad hoc type settings, the learning curve is a little higher. However, we have a lot of people using those features or settings who help each other with learning them. While it's not incredibly steep, there is a learning curve. I do an hour to two hour sessions, which are either classroom led or recorded. That is usually enough for most people to get started. Sometimes, people will come back with more questions, which I totally encourage. Then, if they start to get into some of the deeper things, like ad hoc variables, I have additional sessions that they can attend. These are usually about an hour long and get them going down the right path. I know that Tidal has developed some training, but I had put some stuff in place before they did, as I wanted to train everybody so they could do their job and not have to talk to me.

The biggest lesson that I have learnt from using Tidal is train people. Make sure that the people who manage jobs understand what they are doing and educated to the best of your ability. That has been one of my key takeaways from this. Also, don't go to the latest patch when it first comes out. 

There is a lot of power within Tidal, probably a lot that we're not even using today in terms of managing jobs as well as how we can set up alerting. Also, they have great support, so I can usually get what I need.

It's pretty extensively used right now. We might shift some of our job scheduling to more on demand, then still leverage Tidal for more of the batch scheduling. At least for now, we will be using it as we are continuing to have systems added in. I even have a ticket open because we have an adapter that we just added in that is not quite working right, potentially due to me not understanding the adapter. Therefore, we're continuing to add job streams, but it will always be dependent on what applications we are adding.

Two years ago, I would have given it a six (out of 10). Today, I will give it a nine (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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use it primarily to run SAP jobs. 

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

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

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

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

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

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

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

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

We use quite a few of the features:

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

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

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

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

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

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

15 years.

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

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

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

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

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

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

We have three different types of users: 

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

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

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

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

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

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

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

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

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

One person did the deployment.

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

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

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

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

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

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

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

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

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

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

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

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

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

There are new competitors now: Automic and Redwood. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

About 20 years.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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