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

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

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

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

I can't say I remember a lot about the setup, given that it was that many years ago, but I'm going to say it was fairly easy. At the time, Tidal was a very small company and we got handheld through the process by them. It was a slow rollout. We were very careful with how we did it. I can't remember anything negative from that experience.

There was a fairly large team involved, at the time. We are very siloed into what each of us does. We have a platform team, a storage team, and a network team. We had individuals from each one of those organizations around to stand up servers and set up the network. We needed security to set up our user accounts, not the user accounts for the product itself, but the user accounts for processing. It was a fairly decent size group. But it wasn't like we had a full-time security person working on it. That person may have done 10 hours' worth of work and they were done.

We have three admins who manage the environment and they're in the Tidal GUI all the time, every single day. But the general users in our operations center, who are watching for alerts and for failures, are not using the GUI at all.

It doesn't require that much maintenance. We really can't have a lot of downtime, so when we have to have downtime, it becomes a pretty big effort to plan that out and to validate that the processes we need to run can execute in a different environment. The maintenance itself is pretty easy, but we make it hard based on our business requirements. It's that same team of three who handle maintenance. Normally, one person takes on an upgrade.

I had a technician who did the installation of previous systems we used. When he would do the installation of those other systems, or an update to them, we would always have to hire a consultant to come in and help, whereas with Tidal, we have never had to hire a consultant to come in and help on any update. 

It is super easy to install and super easy to get up and running. I literally showed a colleague once how to create jobs. All you have to do is right-click and then copy and paste. You then make changes to it. He went ahead and did all the other jobs on the system. That was pretty much the level of my training for him. It is extremely easy to use and to set up and get running.

An employee of mine was actually upset with me that I had wasted his time with another product trying to get it to work. We spent over $40,000 having that other vendor come in, and we spent at least two weeks of my employee's time trying to get the integration to work with JD Edwards, the way it should, and ultimately we failed. We were able to do that same functionality within a day with Tidal, start to finish: Load the server, connect the adapter, and submit a job.

We have multiple segments or systems, so our implementation strategy was to get it up and running as a proof of concept on one of our systems and then use that system to show the other segment owners how it works, and what the benefits are. We start off with taking any new requests. For example, "Hey, we need this schedule change." We'll do it in Tidal and it will run there from now on. We'll go back and move all their old jobs over.

In terms of administering it, there is a document out there that walks you through how to install it, so we were able to do that. That document shows, at a high level, how to create different types of jobs. When you get down into the details, it becomes a little harder to know what exactly goes where. That takes a little bit of testing and trying and retrying. For brand-new users the documentation is really good and it gets you to know what you're doing. When you're going to try and do more complex stuff, that's when you start really wishing there was more training.

I wasn't privy to the technical part of the initial setup, but I think it was pretty straightforward. We just needed to know where to place the agents so that they could connect, and we had to do a file share so that if you're doing a DOS command and a Tidal job, it will have shareability to whatever servers they're going to. Once those were all set up it was pretty stable.

Our deployment took about a month. But we were using the product for the first time. So we were setting up jobs for the first time. Some things were kept out of Tidal until they were ready to be moved in. They were run by developers or the application people, manually. It took about six to eight months to get everything on Tidal. There are so many icons and buttons and things that they had to press on to run something on a desktop and we had to convert that all into executable commands for Tidal in the schedule.

That approach was planned. The initial plan was to get the batch processing of claims in first. That was pretty smooth. There were hiccups every now and then but it was not that bad. While that was going on, all the in-house stuff was done in the periphery on a person's desktop. Those things were set up afterward.

The learning curve is at least one to two weeks, if you teach a person, full-time, how to run the schedule and how to set everything up. It depends on what knowledge they need to have to run a schedule. If it was just a matter of running jobs, it would take less than a week. But if they're constantly being asked questions on what this or that job does, it will take a person longer to get a feel for what all the applications do.

I came from a programming background when I started running these jobs and setting up the schedule, so I had a fairly extensive knowledge of what all the applications do. But you take a person who is just out of the computer room and all he knows is how to do a Computer Associates schedule, he knows the timelines and the flow of everything, but he doesn't know exactly what the applications do. They would need at least a few days to find out what are the major applications or major steps in a daily job schedule are. If some of those steps are very critical to run, they would need to be pointed out so they know which are critical and which ones can be held or bypassed. It takes time to get used to the processing.

I was not here for the initial setup. We have been partners with Tidal for a long time, close to 10 years.

I was part of multiple upgrades we did within our organization that were fairly simple. 

For an upgrade, we go to the support site and get the documentation. That documentation is useful. We do not need to go back to the support team asking for more details, as we usually get valid documentation. We just need to follow their steps. Following the steps will take around 30 minutes, then we wont release it to other employees without doing our own validations. Overall, the upgrade takes an hour.

The implementation is straightforward. It is whatever is provided in the documentation. They do provide two ways to do it. So, we choose one way to do it. We copy whatever files are required manually because we want to make sure of what we are copying. We want to make sure we have all the backups available before we do stuff.

It was straightforward. We basically configure the new jobs in Tidal, get them okay, test them out, turn them off in the old schedulers, and turn them on in Tidal. It has been pretty straightforward. The whole deployment has been seamless so far.

I wasn't around for building out the original jobs, but I've had to install it on different systems as we've migrated, and it's pretty easy to install when moving to a new system. You just pick up the database, bring it over, and do a little bit of configuration.

Once you get comfortable with the system, it's pretty easy. It's consistent. There's always a learning curve, but it's moderate. It's not hard but it's not easy because you do have to learn things.

The amount of maintenance is pretty low. We patch it about three times, although they have patches that come out quarterly. The patches do two things: they fix issues and introduce new features. I'm usually patching because I'm interested in the new features. We could patch less, but we do it that often as a company choice. But in terms of keeping it healthy, we haven't had a lot of big issues related to Tidal, which is very good. The level of maintenance involved is good. I handle it on my own. It's not a complicated system, from a maintenance and support standpoint. That makes it a lot easier to keep healthy.

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.

We've retooled our environment three times since we first installed it. Our last one was easy, a piece of cake. The ones prior to that were not so good. 

When Tidal sold it to Cisco, and they had introduced the concept of a Client Manager, a type of web interface, there was a time when going from one version to another version was not good. Now that Tidal is back to the STA Group, our upgrades are much easier.

With our last upgrade, we stood up a whole other set of servers — our servers were old — as well as a database. From the time we got the servers installed, loaded Tidal, and did our initial database export, so we could do testing, it took two to three weeks. It was a piece of cake. And then we did extensive testing.

In terms of the solution's learning curve, from an operations standpoint, teaching people how to search and manage jobs, and start and stop them, put jobs on hold and kill them, we can get someone up to speed in less than a week. For developers, it's a little bit more lengthy. There have been several instances where we have a Tidal developer, a subject matter expert — we've only had one or two of them — who has been able to train multiple people and make them serviceable. We've been doing it for 14 years, so we don't use Tidal training. We've created our own training documentation to get them up to speed for how we use Tidal. We can get them up to speed very quickly. I know people who have joined the company and who are writing and creating Tidal jobs two weeks or three weeks later.

The deployment was very simple. It involved the installation of an agent on a server. Nothing could have been simpler to install and use. We do have another data center coupled with our primary data center for high availability, so physically, there are two locations, but logically, they are one.

We currently have two people who work in Tidal, throughout the day, Monday to Friday. At other times, such as overnight and on weekends, we use managed services to work in Tidal.

In terms of major updates, there is only one every two years. There is very little maintenance needed.

The initial setup is a bit complex.

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

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

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

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

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

It was already at the company when I got here.

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

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

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

The initial setup process is straightforward. 

The setup was slightly complex in the beginning. Later on, I got used to it.

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 setup was pretty flexible. We had to come up with our own ways of deciding how to group things and what our naming convention would be. 

When we first came up on the product, one of the issues that we noted was that the default sort for all of the jobs was alphabetical. That complicates the ability of the operators to visualize the order jobs should run in. To overcome that, we came up with a naming convention that puts a prefix on all of the job names with a number. So when we create our groupings, within a grouping it will list the jobs in the order that they run. Half of Tidal's clients wanted to see things alphabetically listed and half wanted to see them listed numerically, in the order that they run. The vendor wasn't willing to modify the product to give the user a choice of one order or the other.

I don't remember the original installation taking that long. It took us a while to actually build all of the job definitions. That was a lot of work. It was done within about a week. Once the equipment had been spec'ed out we had an onsite install here in the computer facility.

We've had to train a number of new operators and I don't think it's been a terribly big learning curve for them to understand how it works. The developers, in fact, self-trained in their environments and they seem to be able to maneuver fairly well. There are times I have to explain things here and there, some ways of handling things that are more convention. Those are things they have learned over time. But they seem to do all right with it. There isn't that much of a learning curve.

The only people who need to have the training would be the operations staff. I think there was a beginner's and intermediate course that we originally took, when we came up on the product. And then we learned things as we went. 

One of the things that would be beneficial though would be some training that incorporates best practices. You can go through the manual and it will tell you, "This feature does this," and, "these are the parameters that you need to put in," and then the delimiters, but it doesn't necessarily tell you the best use case for certain functionality. I've had a few people mention to me "Oh, you shouldn't do this, and you shouldn't do that." Well, where does it say that in the book? It doesn't. And that's the problem. There's a little difference between an instructional manual that gives you the nuts and bolts of how to do things, and something that's more tailored to best practices, or recommendations of things you should not do. And some of that has to do with the architecture behind the scenes. Users wouldn't necessarily know that unless there was some documentation expressing it.

I was the architect of the initial setup. The initial setup was complex; it's not easy. They have a lot of settings and configuration that need to be done. There are a lot of small things that vary from environment to environment, and they fail to consider every situation. 

The deployment takes a couple of days.

With our first environment, we tested it in a sandbox. I let my admin play with it to see how it behaved and what are the downsides. Then, we created a document. While I know that they have a document for installation, every time that we go to install, we are finding new issues.

I'm behind a firewall and we are in a limited environment. Our infrastructure is built differently from what they probably tested on their environment. So, it's a bit different from what I need to install. I first put it on the sandbox to see all the issues that we are facing, document step-by-step what we did, and then I go and do it in stage. Now, stage is the place where the developer come in and develop their jobs. Once they are ready, we move the jobs into production. 

Stage is really almost production. If stage wasn't available, then the developer could not work nor deliver. We see if it works for at least three weeks. If we don't have issues during that time, then we deploy to production. 

They do a better job in version 6.5, which we are testing now.

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

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

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

We have two deployment models, making it a hybrid, because we have Tidal on-prem and Tidal for cloud as well. They are two different tools, but they are linked to each other. The cloud environment is based in different regions including US East and US West. We have Tidal in both.

The deployment was straightforward. It was not that difficult because we installed it in a Windows environment. It took three to four months because there was a process we needed to follow. We had a team of eight people involved.

There is some maintenance needed. Sometimes, we face issues with the Client Managers, which is the UI console for Tidal. We need to clear the cache monthly so that we do not face issues.

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.

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

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

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

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.

The solution’s initial setup is easy.

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

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