What is our primary use case?
It's used for all of our SAP applications. We have ERP, CRM, and data warehousing. It's used for our PeopleSoft, and it's used for some of the other corporate internal applications. Informatica Data Warehousing uses it.
I don't build jobs. I'm part of the team that did the version and the infrastructure part of it. Our teams go through the process definition and the chain definition for the most part, and I believe they do not use the visual process editor.
In terms of deployment, the core of it is SaaS, and you still have some internal servers. It's never 100% SaaS.
How has it helped my organization?
Going to a SaaS solution has eliminated some of the down times that we needed to install some of our patches. For our agent servers, we're able to create redundant servers so that we can take one down at a time and not involve any downtime. So far, the various upgrades that we received had extremely short outage durations of one or two minutes. The ability to stay up-to-date and current, both from a security standpoint and from an application enhancement standpoint or bug fixes, has been fabulous as compared to an on-prem solution, which would take a long project to upgrade. That's probably been the biggest benefit. Moving to a SaaS solution has a lot of advantages. When you're running factories and projects 24 hours a day and seven days a week, uptime is very important, and you try to minimize any downtime, even planned downtime.
It has dramatically reduced the time and effort that our organization spends on deployment, updates, and maintenance. With our other application, it would be a six-month project to do a major upgrade. So far, with the upgrades that have been done by Redwood, the downtime is only for a few minutes. There is a gigantic difference.
We're pretty heavy into SAP. They have a good SAP interface where we're able to create and utilize jobs even from SAP, which gives us some additional features. It's about the same on the other applications that are simply running command-type batch jobs, but the SAP interface gives us a lot of flexibility. Some of it's similar to what we already had, but it has a positive impact on us.
What is most valuable?
It's a very powerful tool. It has a lot of flexibility for how you can define jobs and build them. There are different ways in which you can construct jobs depending on your specific needs and requirements. It has a lot of features for different ways that you can build jobs, which is great for power users but a bit confusing for newcomers because there are a lot of different options.
What needs improvement?
It lacks some of the common reporting features. I'm a bit surprised that there aren't some standard reports to be able to extract any data on usage. They've described to us that customers have different reporting needs, so they let them develop those, but reporting is a common need. It would be helpful to have it as part of the solution.
For how long have I used the solution?
One of our business groups has used Redwood SAP BPA for at least 10 years before I started working with it, and then the rest of our teams moved over from AutoSys to Redwood over the last year and a half.
What do I think about the stability of the solution?
It has been pretty stable. Performance-wise, we've had to work on it a bit simply because of our volume. That's more with database performance. We haven't had any problems with any jobs because of any bandwidth performance.
What do I think about the scalability of the solution?
So far, it's been good. It scales. As we did the conversion, we did probably eight different deployments or eight different sub-projects to bring various applications live. That part of it scaled very well, with the exception of some of the performance of the database tuning, which took some time, but part of it had to do with the high volume of jobs that we run.
It's deployed across a broad list of applications, across multiple data centers. Its users include business people, developers, and schedulers for jobs. There are hundreds of people who use it.
How are customer service and support?
I have contacted them. I would rate them an eight out of ten at this point.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
Over the last year and a half, we've migrated from AutoSys to Redwood. We switched because of their roadmap and their commitment to keeping the product fresh by patching on a regular basis and providing regular updates. Looking at other competitors, there was also the cost-benefit.
The future of AutoSys was unclear. It was a product that we had used for almost 25 years, but the roadmap was unclear on whether that was going to be a viable product going forward. It put us onto a SaaS product that is definitely more stable and gives us a roadmap into the future for enterprise-wide job scheduling.
Redwood is a little more complex than the AutoSys application we used before. It creates some challenges from the standpoint that there's a two-step process. You build a job and then you schedule the process to run. You build a process definition or a chain definition, whereas, in AutoSys, you do it basically in one step. That part has been a little bit more difficult, but it has given us a lot more flexibility, specifically in terms of the ability to write some very complex calendaring that we couldn't quite do before for the scheduling portion of it.
How was the initial setup?
It was complex. We had a high number of jobs, and we had a percentage of jobs that were very complex in terms of how they were built. Also, we were moving from a system that had been in place for over 20 years. So, you don't always have experts around who understood why it was done that way, but the conversion pretty much brought everything over the way it was executed before.
We spent a year. Part of that was the volume of jobs that we have and the number of teams involved. We've got multiple job scheduling teams by application. We don't have one central team, which made it more difficult from a conversion standpoint. There were a lot of people to train.
As a job scheduling tool, Redwood has reduced the footprint for what's needed. There are still process servers that are required to be inside in order to communicate with SAP and keep the communication inside, which is good from a security standpoint, but the core application is in the cloud. So, we're not responsible for patching the database or patching the core components of the application. This means our upgrades have become very simple because it's a small agent that gets updated during any software release. So, the actual upgrade process is just a few minutes of downtime, which has been a huge benefit. Server-wise, we probably have the same number of internal servers because there are some gateway servers that are utilized, and we've duplicated them and made them redundant so that we can take down and patch them one at a time to minimize any downtime and failover capabilities. Our net is probably similar, but the planned downtime is significantly or exponentially less.
Being hosted on SaaS has reduced the patching requirements that are needed. Any of the connectivity and vulnerability requirements are pretty much handled by the application now, so we don't have to deal with that internally. When you move to a SaaS solution, you're at the wind of the internet, if you will, for final connectivity, but it's not quite as important in job scheduling because your jobs, once they fire off and run, continue to run on the application servers if there is any outage. So, it's not like other applications that are more chatty or require a persistent connection.
What about the implementation team?
We used the Redwood migration team. Our experience with them was good. They are sharp people, and they know their product very well. Alex Borders was the most helpful. He was our lead for the conversion. He had a huge wealth of knowledge.
From our side, there were two of us who worked on it from a standpoint. I worked on it from the technical side, and the other person worked on it from the governance side in terms of whatever we had to change internally process-wise, but each application had its own teams involved in it. So, there were hundreds of people involved in it. Most of it was from the testing and training standpoint for the job support and job processing teams, basically our developers and schedulers.
What was our ROI?
We're not even a full year into running it yet, so it's a little hard to provide any input about the ROI.
What's my experience with pricing, setup cost, and licensing?
It initially surprised me because we went from an application that was priced by connection to agents/the number of agents to an application that was priced based on the number of job executions. At that time, many of the products we looked at were also priced on job execution. That seems to be more common in the business or in the vendors that provide solutions out there, but that was probably our biggest difference.
Which other solutions did I evaluate?
An evaluation of other products was done, but we had already used the SAP version of Redwood. So, we were already familiar with its capability. The fact that we already had people who were familiar with supporting it weighed pretty heavily into it.
What other advice do I have?
It's important to do a PoC, take some of your complicated processes, and ensure that your expectations are met.
For the people I work with, the time freed up from using this solution is about the same because we were already using an Enterprise job scheduler. It's probably the same workload. Similarly, the reduction in service interruptions and process failures is the same, but we've drastically cut down our planned downtime.
I would rate it a nine out of ten.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.