Tidal Automation Reviews

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.

We primarily use it for scheduling our JD Edwards ERP software batch jobs.

The solution runs on Windows. It also integrates with our Unix & AIX systems. We use it for automating EDI transactions, so it reaches out to FTP sites as well.

The solution’s drill-down functionality is really good. It can be limited to just seeing a specific job or a group of jobs, depending upon the person's location.

We utilize Tidal for updating other computer systems used within the plants with JD Edwards transactions. This functionality alone saves a lot of time so personnel didn't have to manually run jobs to update the other systems. 

The ease of scheduling is its most valuable feature, and how easy it is to actually schedule something. One of the best things is the calendars and how flexible the calendars can be. Or, you can create your own calendar to match whatever schedule you want or need the job to be run. That is huge for us.

We use the solution for cross-platform, cross-application workloads. The solution’s ability to manage and monitor these workloads is very easy and accurate. We use the job dependencies feature A LOT... meaning one job doesn't start until the last one finished successfully and so on. Another fabulous feature is the file dependencies. A particular job does not start running until a file exists in the location specified but that file is on a completely different server. So, it is cross systems.

It's pretty easy to understand and learn. I did not go through any training for it, we have a test environment so I 'played' a lot there and learned the capabilities of this powerful scheduler. Some guidance as to how the solution is setup and configured today is needed, so users stay within those boundaries. It takes less than half a day (four hours) to onboard new administrators.

I know they are working on improving this already, but there needs to be better reporting. Currently, there are only like three or five reports that we can get off of the system. They already have a solution to this in the new version. I.e., a schedule of all the jobs running for one day, specifically calling out what dependencies that a job relies on. It would be like a flow chart of how the day's jobs would run.

Over 14 years.

The stability is excellent. There are days we don't even log into the product because it just continues to run seamlessly.

We don't have it open to our users and don't actually see a need to do that at this point.

The system administrator is the regular user of the solution. They do the maintenance of the solution, if needed.

We have jobs that run every 2 minutes all throughout the day as well as hourly jobs that run.

Luckily, I haven't had a need to use the technical support.

Except for one time, when Java got accidentally upgraded, and it slowed our performance terribly but they were absolutely amazing and great to work with!

In my past job, I have used HelpSystems Robot. At the time, HelpSystems only ran on an AS/400 or iSeries while the Tidal solution runs on various platforms. They are pretty comparable though for functionality.

It was already at the company when I got here.

We upgraded earlier this year, but we used a business partner (Blue House) because I did not know how to do it.  Since I watched them, I could probably do it myself going forward, as the process was fairly straight forward. We were done within just a couple of hours.

Blue House was great to work with and the process itself was easy. 

We have seen ROI from savings in time. We run on average about 2,200 jobs a day. This is a cost savings for us due to the fact that our users do not have to run these jobs manually since Tidal will do it for them.  As an estimate, this has probably freed up 10 full-time people, in the various departments, about an hour or two a day.

We pay maintenance annually through BlueHouse of about $9,000. That i's for our two environments: production and test and some adapters to integrate with other systems.

My company did evaluate other solutions. They chose Tidal because it was one of two solutions which ran on the hardware that they had at the time, an AIX platform.

It's a great product. I endorse it because it is stable, and that is a big thing for us!

Give it a shot. Get a trial. Test it out. You'll come up with probably the same thing that we did and purchase the product.

I would give it a nine (out of 10). There is a little room for improvement, but overall the solution is exactly what we need and rely on.

This solution does enable admins and users to see the information relevant to them, but we do not have that enabled for our users.

Because we run 24/7/365 and are open all the time, the solution has not really reduced weekend hours for us.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I'm really confident in the stability.

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

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

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

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

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

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

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

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

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

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

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

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

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

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