What advice do you have for others considering Tidal Automation?

I would recommend Tidal Automation by Redwood as the first priority for users looking for any automation tool. Overall, I rate Tidal Automation by Redwood a nine out of ten.

I rate Tidal Automation an eight out of ten. It is a very good container if you are looking for a single enterprise-level scheduler to control the entire operation.

It's a great workload automation software that will simplify a lot of manual tasks.

This is a great tool to use for big IT tasks. It makes the process fast and easy.

The ease of use of Tidal for automating is moderate, if you have the proper knowledge and training on how to schedule a job. A new person will need some training on how to get a job scheduled in Tidal. They have multiple new features coming up in the future. They are going to come up with repositories, for example. If you are going to use Tidal, I would recommend going through their documentation in-depth and only then start using it, so that you are aware of everything. When I joined, I was not experienced with Tidal, so I had to go through the documentation, and then I started working with our live production.

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

If you need a scheduler that's easy to use, dependable, and versatile and that doesn't require a lot of complexity, then I would recommend giving Tidal a strong look. Cost-wise also, it has been very reasonable. So, evaluate your needs, and if the needs involve versatility, scalability, and ease of use, then Tidal is definitely a suitable one. I would definitely give it a 10 out of 10 because I've been working with them for many years at many companies, and I would recommend them to anybody looking for a scheduler.

Some top features:

1. The high availability of the scheduling engine is second to none.  Completely hands-free failover of the scheduling node occurs when unforeseen events happen (network outage, server issue, patching minutiae).

2. Built-in application-level load balancing between job execution nodes (agent lists) provides for inexpensive fault tolerance and can be utilized for disaster recovery

3. A large number of adapters are present, which provide for GUI-driven job development.  It is not necessary to drop down to the command line to develop jobs when using these adapters (MSSQL, Oracle, Informatica, PeopleSoft, Cognos, Oracle Apps, JD Edwards, Amazon S3)

4. Operations staff do not necessarily need to be command line experts to develop jobs and manage the product.   Management tasks and basic job development/ maintenance can be done via a very robust GUI.

5. Over 50 out-of-the-box triggers can be incorporated into jobs and job sequences for event-driven workload automation.  (i.e, job fails --> run this recovery job; job has not run by time X --> perform these actions;  job is running longer than typical --> perform these actions)

6. Flexibility in creating calendars. Whatever wacky calendar your business may require, if there is a logic to it, you can develop a representative calendar for it in Tidal.

7.  Product support is very good. It is entirely possible to call in and be with an advisor in less than 5 minutes for priority one issues. The US-based support team is professional, very well-trained and will make sure to stay with you until your situation is stabilized. The company has a high bar for their training staff...there are no newbies.

Work with the folks who own the systems where the jobs will run, so that you understand what your needs are, and leverage Tidal's customer support to come out, give you demos, and to help you get started. Their documentation is actually pretty good, it has improved over the years, so if you want to read it you can, and it will be helpful. As the only support person for Tidal in our company, I'm very motivated to stay on top of things. That means I do a lot of training to make sure that my users, the people who build out the schedules, are knowledgeable and understand how to respond to issues. I have also set up a lot of alerts that give me an idea of things that might have issues. All of that is done using Tidal's tools, which is great, to keep me on top of things.

My biggest advice would be to review all of your jobs to determine why they have to run how they run. For example, we had jobs that ran every five minutes. We started asking why it needs to run every five minutes, and we were able to change it from running every five minutes to only running when needed. So, if you can change your every five minutes job to be more of an on-demand or as-needed, then you can make better use of Tidal. There is a lot of flexibility in Tidal to do more on-demand or as-needed things or event-based scheduling instead of just time-based. It is extremely easy to use. We've been able to have developers, BAS technical people, and sometimes even a couple of non-technical people go out there and make use of the interface. We're able to give them a little bit of training, and from that training, they're able to go forth and do what they need to do. The only complexity I see is that the users can get hung up on the uncertainty of job statuses. For example, if I do X, what will the job status become? That's probably more of a comfort level than the simplicity of use. If I take a job that has errored out and I right-click it and resubmit it, while it is going to try to resubmit it, it'll go to a processing status. Some people don't want to mess with that one. They want to insert a new one. It is about thinking about what you're trying to do, and there are dependencies. How complex you make the job schedule controls how people feel about the interface. We are using its Graphical Views feature, such as Gantt, Kanban, and PERT, in the case of more complex processes, such as our MRP process. For some of the processes, it doesn't make a lot of sense because they're only run if needed. We don't need to really see the Gantt side of stuff. So, it is used only when it is a highly complex process. For example, for a sales update process for doing invoicing at night, I could make use of the Gantt and other similar charts. Our MRP process is a very complex and long-running job. We use it for that, but for the rest of the jobs, it is not really used. I would rate this solution a nine out of ten.

We are a customer and end-user. I don’t know if the solution helped reduce or eliminate weekend or overtime hours as that doesn’t really apply to me. We're 24/7. There's no such thing as a weekend for us. I'd advise new users to not underestimate the way that people will want to blame a tool for something they don't understand. Tidal will display errors from other systems and you need to be prepared for separating a Tidal error from Tidal reporting an error. That's the biggest learning point that you want to have in your head at the beginning. It's a good idea to define the lanes of responsibility. That's been almost the entirety of my career, maintaining the lanes of responsibility through Tidal, as it's cross-platform, it's cross-technology, it's cross-team. You really have to be able to sort out the difference between a psychology versus a technology problem. It's the way someone feels about what's on their screen. It's been very helpful for that, however, it's probably a similar problem for anything like this. Tidal just makes it so easy to see those things yet oftentimes it gets blamed for stuff. I'd rate the solution nine out of ten.

I would rate this solution a seven out of ten.

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.

The main thing is to look at whether you really need an enterprise scheduler in general. After that, implementation is very important. Setting up standards from the beginning for the scheduling and the jobs is very key. My biggest advice is to analyze all these processes and come up with a good plan for how to incorporate everything into your scheduling. That would be one of the most important things for Tidal or for any scheduler in general. From the admin side, for the technology itself and the technical stuff, work with and trust Tidal support at the beginning to get to a certain level of how to scope everything out, and then go from there. I'd rate it an eight out of 10. The main thing is whether or not they come out with a better rollout of their upgrades and patches so that they are less buggy. Unfortunately, they still do come out with a consistent number of bugs. They also need better documentation at the admin level. Those are the two core areas that they're truly lacking in, and a little bit on speed. However, the newer version that we're still testing is supposed to take care of that. We'll have to see when that comes into play.

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

One piece of advice I would have is that if you get into a product, try to keep it upgraded. It's to your benefit, support-wise to be, maybe not on the cutting or the bleeding edge, but close to the current version. That's been a pain point for Tidal, to try and get their clients up to speed. Stay on the latest version because of the functionality. It's not only relevant to just this tool, but to many IT tools. It's just like the next generation of laptops that are coming out; they're coming out more quickly. The same thing is happening with the functionality that is being added to all of these products, including the scheduling application. It's important to go through the pains of staying up to date. It's been a good product. We could have done a lot worse. This is a heck of a lot easier to use than some of the other schedulers that I've used in the past. But, then again, it's been proven as a solution, as well. Other solutions are all moving targets. Everybody is making changes in their products. At the time that we made the selection of Tidal, it was definitely constructed a lot better. It was easier to use than the other option. In terms of the number of users in our organization, I honestly wouldn't mind if everybody in the company had an account to log into Tidal with inquiry access. But I think we've got around 300 accounts set up in each instance. They could be used by managers, developers, operators, and all the other IT folks who have accounts. For deployment and maintenance of Tidal, since we're doing a 24/7 staff, we're talking about eight people, and three or four other people who are going to be part of production control and/or an IT server ops-type of functionality, because you need that level of support as well from time to time. So we have twelve or so people in one capacity or another maintaining Tidal. I would give Tidal a solid eight out of 10.

The biggest advice I can give is to test Tidal first. Run the whole schedule, whatever you're putting in. Run everything you can and test Tidal before you bring it over to production. The trickiest thing to do is to change a schedule during the day. Once you associate a job with the calendar, and then somebody comes by and says, "Hey, I want to put these six steps in, and we need to run that today," if you try to change that schedule during the day, you don't realize that, because you put it on the calendar, it's on a schedule. You could be making changes and kicking off things inadvertently. You can't change something during the day without like stopping the scheduler or putting it on pause. We might have done that once in all these years — pause the whole scheduler or pause job launching and then make a change and then turn it back on. You may think that you can change something during the day and let it go, but then you realize, "Oh, this thing took off." And you realize that because you put that job on the schedule, it picked up the scheduling requirements it inherited from another group of jobs and it will take off on you. That's probably the trickiest part of the learning curve. When we brought Tidal in there were six people who were taught how to use it but five of them have retired. I'm the last one. About three years ago I had to train another person who came from the mainframe computer room after he took the job as a Tidal scheduler. I got him up to speed. The two of us run the schedule during the day. There are no other users. There are a few application programmers or developers who just want to have Tidal available so they can see what's going on, and we give them inquiry access. But nobody else has any authority to change anything or to set up anything. Overall, it does what it's supposed to do. I always get into arguments with the management staff here. They always claim something happened in Tidal and I say that Tidal doesn't process anything. It's a scheduler and it just launches jobs on the servers. If there's a system hung up somewhere, it's not Tidal. Stop. It is the actual program. Whatever processing has been launched by Tidal is the issue, not Tidal itself. I finally convinced them of that. Just because Tidal launched something doesn't mean it has touched anything or changed any data. It just goes to a server and launches a process. A person with the right authority can do the same thing from their desktop.

Don't feel ashamed that you'll wonder why you waited so long. I've used so many other products, gotten them up and running, but I don't know of any other product that works as easily as Tidal does for scheduling jobs for J.D. Edwards. I'm sure there are other people who use Tidal for other stuff, but J.D. Edwards is what I mostly know. I think it's the only scheduler you should use if you run J.D. Edwards. The biggest lesson I've learned using Tidal is don’t wait so long. It took me five years to convince my boss that he should let me buy Tidal. He even brought in another product, and I sat there the entire time I was getting that other product up and running, saying, "I sure wish I had Tidal." Another lesson learned is to be prepared because the more people see the functionality and the abilities of Tidal, the faster they're going to want to make use of it. Another lesson learned is that it is truly a product that the end-user can run instead, of IT supporting it. To me, it's no different than somebody logging into production and submitting a job in production. Why shouldn't they be able to submit it through Tidal? If I can give them an easy way to do that, all the better. I rate Tidal at eight out of 10, because everybody else in the industry is about a five. For Tidal to get to a 10, they need more traction in the industry and to be recognized as the leader of scheduling in J.D. Edwards. I think they have the product for it. Now, they just have to market it and get it sold. They also need to work on the people who make use of it. The more training opportunities, the more hands-on, the more interactions with it, the more people will see the value of it. There is a lot of room to for Tidal to grow, but over time they'll get there.

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

The big thing I would say to someone who is deploying this new, aside from having a naming standard and the structure, would be to get their security groups right, up-front. That is a pretty big one. Set your owners and who your users are going to be. Think about how you are going to structure it from a user point of view. We have two core systems here. One is for our loan origination system and the other is for allocating leads and directing leads, and they both rely on Tidal heavily. If the scheduler were to shut down for some reason and we couldn't run it, it would have a huge impact on our business. Thankfully, that's not a scenario that we encounter, but we really rely on it to drive so many of these business processes. In terms of increasing our usage of it, other business areas have started take some interest in it, but we haven't made a dedicated effort to get, for example, our SQL Server systems to be managed by the scheduler, or to do things with Amazon. We haven't really had anyone driving that effort. In our environment, one person, me, maintains the Tidal software. That's more an organizational question of how many people do you want to have who are capable of supporting it. We have a team of six people, all systems engineers. They're not all as up-to-speed on it as I am, but if I gave them my notes for doing the install, I'm sure they could all do it. The number of users of Tidal, in our organization, depends on the definition of "users." It touches things that impact every user in our organization. But with respect to users of the interface who log in and use it, it's only about a dozen people. Aside from the system engineers, the next biggest users would be developers or program engineers. They are people who are involved in researching updating a task to a procedure or process and they want to know what the scheduled processes are and when they run. They are also looking at what their rules are for running and how long it takes. Sometimes business analysts will be involved in that as well. Tidal is a nine out of 10. I would say it's a 10 if we didn't have some performance struggles with the web interface.

Tidal's drill-down functionality is one of those things where you get out of it what you put into it. If you program it to fire-and-forget then it doesn't have a lot of drill-down mode to it. If you put in result codes and things like that, instead of using the agent to kick off the SSRS package in SQL, or if you use the adapter, then you can drill down. We have about 100 users using Tidal in our organization. They are anywhere from developers to operations people to administrators. There are only a couple of administrators. There's a bunch of operators because we use this to run 24/7, 365 for 20 or 30 customers. For each of them there may be a couple of operations people and a couple of developers. As for maintenance, we patch our boxes, our masters, our Client Managers, and our databases every month, and it takes one person.

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

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.

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.

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

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.