Tidal by Redwood Reviews

Tidal Automation can handle batch processing task scheduling and implementation, decreasing errors and increasing productivity. 

Data handling and administration duties such as data merging, migration, and transformation can be automated using the program. It can also automate duties related to IT operations, such as software deployment, server upkeep, and backup and recovery. 

By automating procedures for data retention, audit records, and security controls, the software can help guarantee legal conformance. 

It can be used in a variety of sectors to help companies automate processes, increase efficiency, and reduce errors.

Tidal Automation automates time-consuming and repetitive chores, decreasing employee workload and increase productivity. 

It can also reduce error risk, enhance data and process quality and precision, and provide real-time tracking and alerting. 

It is intended to enable large-scale automation environments, making it appropriate for companies with complicated processes and big data volumes. 

Tidal Automation also offers sophisticated security features and compliance controls to guarantee the security of confidential data and processes. 

It can assist companies in streamlining processes, improving efficiency, reducing errors, and saving money, making it a useful instrument for groups of all sizes.

Tidal Automation automates time-consuming and repetitive chores, reducing employee workload and increase productivity. 

It can also reduce error risk, enhance data and process quality and precision, and provide real-time tracking and alerting. 

It is suitable for large-scale automation environments and offers sophisticated security features and compliance controls to guarantee the security of confidential data and processes. 

It can assist companies in streamlining processes, improving efficiency, reducing errors, and saving money, making it a useful instrument for groups of all sizes.

Tidal Automation is a complete automation program with an easy-to-use interface. However, it could be better in terms of user experience, customization, and cost. 

Some users have complained that the initial setup process is complicated and time-consuming, while others have suggested that the software could offer more freedom in customizing processes. 

Furthermore, Tidal Automation's pricing system may be a barrier for some companies; therefore, the software should consider providing more flexible pricing choices or discounts for smaller businesses.

Tidal Workload Automation Software is primarily used for scheduling, monitoring, and managing critical business and IT workflows across an organization's IT infrastructure. 

This software automates the execution of various workflows, including batch jobs, data transfers, file processing, and application integration, among others. 

The software provides a centralized platform for managing and automating crucial business processes such as report generation and customer service operations. The software can be used in a variety of industries, including finance, health care, manufacturing, etc.

Tidal Workload Automation Software helped my organization to reduce operational costs by streamlining processes, eliminating errors, and minimizing the need for manual intervention. Additionally, automating tasks reduces the need for hiring additional personnel, which can result in significant cost savings.

Tidal Workload Automation Software provides the ability to quickly adapt to changing business requirements.

The software helps organizations to easily modify workflows to accommodate changes in business processes, and it can dynamically allocate resources based on changing workloads.

Tidal Workload Automation Software provides Role-based access control, ensuring that only authorized personnel can access sensitive data and workflows. This feature is essential because it helps organizations maintain security and compliance with industry-specific regulations.

Tidal Workload Automation Software offers dynamic job scheduling, allowing organizations to locate resources based on workload demands. This feature ensures the resources are efficiently utilized, which helps in improving the organization's productivity.

Tidal Software interface could be more intuitive and user-friendly. I felt a little difficult to find the features I need. A more streamlined interface could help improve usability.

With cyber threats increasing rapidly, Tidal could benefit more by improving the security features such as encryption and access controls.

Tidal software could be of more advantage if it gets integrated with popular DevOps tools such as GIT, Jenkins, and Docker could help to streamline workload automation and accelerate application development and deployment.

I have been using the Tidal Workload Automation Software for the past 1.1 years.

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

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

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

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

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

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

The solution could be improved via:

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

The primary use case of Tidal Automation solutions is to automate and manage complex and time-consuming tasks associated with scheduling and reducing manual efforts.

Tidal Automation solutions can streamline these tasks by automating data collection and analysis, scheduling maintenance tasks, and monitoring the performance of environments and the associated system. By automating repetitive and time-consuming tasks, Tidal Automation has helped us save time and resources, reduce errors, and improve operational efficiency.

It was deployed on-premise as a SaaS application.

The solution has improved our organization with:

1. Increased productivity. By automating tasks, we were able to focus on more valuable work, leading to increased productivity and efficiency.
2. Improved accuracy. Automating tasks has reduced the risk of human error, leading to more accurate results.
3. Enhanced compliance. Tidal Automation has helped us maintain compliance with regulations and standards by automating tasks such as audit trails and security checks.
4. Greater visibility. Tidal Automation provided a central dashboard for monitoring and managing tasks, providing greater visibility into an organization's operations.
5. Scalability. As our organization started growing, Tidal Automation was scaled to meet the increased workload and complexity of tasks.

The most valuable aspects of the solution include:

1. Workflow automation. Tidal Automation allows organizations to automate complex workflows and processes, reducing the need for manual intervention and improving operational efficiency.
2. Job scheduling. Tidal Automation provides a centralized scheduling system for jobs and tasks, allowing organizations to manage their workload and resources more effectively.
3. Error handling. Tidal Automation includes features for error handling and recovery, reducing the risk of job failures and minimizing downtime.
4. Monitoring and reporting. Tidal Automation provides real-time monitoring and reporting capabilities, allowing organizations to track job progress and performance and identify potential issues.
5. Integration with other systems. Tidal Automation can integrate with other systems and applications, allowing organizations to automate workflows across multiple platforms and environments.

The solution need to improve its offering via:

1. Artificial intelligence and machine learning capabilities to enable predictive analytics and proactive issue resolution.
2. More advanced reporting and data visualization capabilities to enable deeper analysis of job performance and trends.
3. Enhanced integration capabilities with other systems and applications to provide a more comprehensive automation solution.
4. Advanced job dependency management and scheduling capabilities to ensure that jobs are executed in the correct order and on time.
5. Integration with cloud platforms to enable greater scalability and flexibility.

I've been using the solution for 1.2 years.

It's a company-wide batch scheduler.

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

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

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

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

It's very

• user-friendly
• intuitive
• robust.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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