IBM Workload Automation Reviews

The TWS GUI was an excellent feature. Job monitoring and scheduling using the front end was extremely easy.

Job scheduling is an integral part of deploying data warehousing jobs. I was a part of the developer team and while coordinating with the support team who did the actual job scheduling, it was easy for them to coordinate with us on what job to release first, what to cancel, what to release dependencies, etc.

If there was a way to monitor SLA breaches from within TWS, it would have been great. The only way to monitor job failures on TWS was to check the GUI for any failed streams. This said, there are ticketing systems associated with batch and real-time jobs that triggered an alert whenever something failed and that works well with TWS.

The one scenario that I encountered (and found a solution to by implementing a script from outside of TWS) was when a critical job does not start running even after the scheduled time, say due to an unexpected outage on one of the dependencies listed on TWS, there was no way to alert the owners of the application. And no ticketing system would alert anyone because technically, there is no failure. Or there was no way to trigger an alert from within TWS for a long running job, that is running way past it’s ETA.

I used the solution for two years.

None that I encountered during my two-year tenure at Chase.

Deployments and issues with the TWS server were handled by a different team. Other than periodic maintenance outages, there was no other major downtime that I encountered.

Individual access setup was relatively easy. But I think I would attribute this to the setup teams, to the on-boarding team at Chase. We had a specialized request procedure and an access team handled the request.

Things shifted after I joined. They evaluated Control-M and decided to pursue Control-M and discontinue use of TWS. Control-M had a far superior user interface and also had a notification system which TWS lacked.

There are multiple factors that would influence my preference to this product. In purely ease of use, functionality etc, I would rate it 8/10. I am not considering the cost of license etc.

The simplicity of the GUI is the most valuable feature for us.

My organization has automated a lot of tasks that were previously being done manually like processing of cheques from multiple banks. This was a three step process wherein a dedicated man resource used to scan the cheques individually, another person then updated a record in the database followed by sending out an email.

All these steps required a lot of time and money and any absence of human resources would result in severe lapses. With the help of Tivoli, all the three tasks were automated into a single jobstream that runs throughout the year without any manual intervention, even taking off days and holidays.

Out of the box reporting and provision for customization/integration with other products are the areas where this product can be improved.

I have been using the product for six years.

We have not encountered any significant stability issues.

We have not encountered any scalability issues.

The support teams at IBM that work with Tivoli Workload Scheduler cases are comprised of people who have tremendous command on troubleshooting issues as well as people who are not that technically capable. So the experience can be good and bad depending on the engineer that you end up coordinating with. I would say overall, the support for this product is above average.

I have been consistently using Tivoli Workload Scheduler as a one stop solution for my various client's job scheduling and automation needs, so I am not aware of any previous solutions.

The initial setup is not very easy as IBM has multiple components integrated with the core product which are mandatory to setup and can be a bit tricky.

This would be one the expensive lines of product in IBM's portfolio, so initial costs can run high if someone is buying it for the first time. The licensing is IBM proprietary, and clients are not charged on the basis of underlying hardware configuration that hosts the installed application - CPU cores and manufacturer to be exact - which goes up as you add on to your processing capabilities.

Over a period, once you are a client, you may get better pricing quotes from your sales representative. Also, there are workload based flexible pricing options available for smaller setups which can always be considered and negotiated accordingly.

The alternatives in this category of products are not many. BMC Control-M and CA Autosys and another job scheduler from Tidal are the major ones. I have evaluated BMC and CA, both are equally capable and perform wonderfully well, the one advantage IBM has over its counterparts is its capabilities with mainframe scheduling for a very long time. Most old companies have had mainframes for 2-3 decades now and IBM integrates seamlessly across their legacy mainframe as well as the newer distributed setups.

It's a very good scheduling product if you have a combination of mainframe and distributed environments that have batch operations and repetitive tasks running on them. The SAP plugin is outstanding and SAP process chains run a like a dream when scheduled using Tivoli.

If you have an environment like the one I've just mentioned, this would unarguably be your best bet. The initial costs are steep but it pays off in the longer run as the product itself is very stable if configured correctly.

• Event-based scheduling
• Support for other applications via connector, such as Oracle, SAP and data warehousing software

If you want to run any Oracle, SAP or data warehousing job, you don't need to install a TWS client on the target server. You just have to install a connector on one of your TWS systems and provide the required parameters such as system credentials in an encrypted format.

It supports almost all of the different groups in the organisation for automating their tasks, such as finance and accounting, transport department, procurement department and several others as well.

Whenever we find any bug/vulnerability, we immediately inform IBM and they provide us a fix, so I can say it is being continuously improved.

A few things are missing but I can manage without them, such as a cross-reference report. For example, if you want to find particular job script, it is very difficult to do so from the TWS command line or from the TDWC (Tivoli Dynamic Workload Scheduler) tool. On the other hand, there is a Germany-based company Horizont, which has a very nice tool, TWS/WebAdmin, which provides such a facility.

The second thing is that there is no built-in facility to run SFTP/FTP file transfer jobs. You have to create your own SFTP/FTP scripts to run these types of jobs.

An internal change management tool is also not available in IBM TWS, but other scheduling software do offer one.

These are a few flaws in TWS, but operation-wise and handling-wise, it is a superb tool as compared to other batch job scheduling tools.

One thing is true: You will not get all of the facilities in one tool, so I recommend you go with TWS for smooth automation delivery.

I have used this solution for the last seven years.

We never encountered any stability issues. If your TWS administrator is very good with TWS, then he/she should always keep your TWS landscape stable.

We never encountered any issues with scalability.

We used BMC Control-M first, but later we changed to TWS due to its efficiency, accuracy and scalability.

If you have strong knowledge in TWS, then initial setup is just like bread and butter for you.

I heard it is very expensive compared to other job scheduling tools.

Go ahead and use the TWS solution. It is really a very good product.

The whole product is valuable because it is a tool for batch automation.

There should be more custom documentation, specifically around Java APIs. There should also be more training.

In terms of features, we are currently using only 50% of its features. We don't use all features that are available, but there is always room for improvement in all of the tools. 

I have been using this solution for 15 years.

It is very stable.

It is extremely scalable. We run more than 80,000 jobs a day across multiple platforms.

Their technical support is fine. We have a contract with them to assist us.

It is simple to install.

It is about one-third of the cost of a controller.

I would rate IBM Workload Automation a seven out of ten.

We use it at the Bank for the portfolio management system. In 2001 and 2003 I created all these jobs for the portfolio management system for collecting data from the backend system.

From 2015 I use it as the tool that collects the resources within the IT system that reports the use of different resources, file system resources, storage resources, and so on.

The most important feature is the creation of folders. It's a really great feature because you can organize the process with naming conventions. 

Other solutions like Control-M are better than this solution. IBM should have better integration with the cloud. 

It should support other schedulers that aren't IBM products. 

We have been using IBM Workload Automation since 2015. 

It's very, very stable. The support is quite good. I was totally astonished about the life cycle of this IBM product because a lot of colleagues told me that Control-M is the best scheduler but I have found that it's not true. IBM does a really good job with its product.

It's better than the solution that Control-M offers. Within Deutsche bank they are using Control-M for the investment banking and they are using different timezones, for every console you need a separate installation with Control-M. With IBM, it's not necessary. 

IBM uses also has different plan options, from monthly plans to weekly plans. This is a problem with Control-M. It makes maintenance very, very costly because you have to configure different environments for different timezones.

The scheduler is a little bit complex. They have different concepts, they use event mechanisms for their workforce. 

With Control-M you have a lot of server components. In the meantime, you can install them with Kubernetes as well which is a big improvement.

I would definitely recommend this product. It's an interesting option in terms of schedulers. 

I would rate it an eight out of ten.

• Alerting on ABENDS: When a job abnormally ends (ABENDS), the solution notifies us when the job did not complete successfully. This is a nice feature for job streams that require successful completion of one job before it moves on to another. It’s still “reactionary” in nature, but allows us to run a job stream again. This occurs, in some cases, before the end users of our data services know there’s a problem.
• When changing a cycling ID, we only have to change it once.

• Moving jobs from Dev to Prod only takes a text file script, which is straightforward.

It has over complicated things.

• It is complex to use
• Lacks scalability
• It is difficult to set up jobs to run
• We need to be able to elevate privileges like Task Scheduler

With Windows Server 2012, there is a setting for User Access Control. UAC is a security feature that prompts the user, and even administrators, when running a job that requires a higher elevation because of its interaction with the Operating System.

When you’re trying to automate tasks and run them in the background, this prompt still comes up and asks if it’s OK to raise the privilege level. That hangs the job.

When running the solution, there’s no way to get around that prompt. Any job that requires that elevated privilege sits and waits for the user to answer it.

With Windows Task Scheduler, there is a check box in the Scheduled Task that says “Run with Highest Privilege”. If that’s checked, then it automatically bypasses the UAC prompt, and completes successfully.

The only other way to get around that is to lower the UAC restriction on the server, making it more vulnerable to malicious code.

I have been using this solution since November, 2010.

We have not have issues with stability.

We had to write a scripted solution to be able to change jobs behind the scenes. The solution runs with a specific command fed into it. We fed it this script: “CSCRIPT

Our company has our own internal support.

We used Windows Task Scheduler. We switched because the new SSIS servers were going to be managed servers.

The setup was very complex. Our environment is very large. Setting up Workload Automation on our set of servers required the following:

• Setting up the agent
• Setting up the notification lists
• Filling out various forms for job stream scheduling. (It just goes on from there.)

This was the new corporate standard and we were not given a choice.

Look into ALL options. Verify that you can run your application servers with UAC turned to "do not prompt when using an admin account".

Dynamic scheduling: This is one feature which helped us achieve some important business objectives without the need to install TWS on a server. Some of the servers in our organization have restricted access and dynamic scheduling helped us schedule jobs on these servers without the need to install TWS.

• Monitoring
• Reporting

TWS doesn’t have in-built monitors to capture and report READY/INTRO state jobs. In our environment, we use TWS to schedule jobs in SAP and without an in-built monitor to capture these, we use custom-built scripts to report jobs stuck in READY/INTRO state.

I have used the product for seven years.

There were real stability issues. The WebSphere process gets hung on TWS masters running TWS 9.1. WebSphere is used heavily in our environment and a restart of WAS is really required at least once in a month.

There were no scalability issues.

Technical support was not always the best. You need a little bit of patience until the PMR is routed to the right layer of support.

Initial setup using the GUI was straightforward. However installing/upgrading a TWS master using the silent approach is a little bit tricky, as the details and the steps have to be collected from many other documents. There was no single document to help us to install the TWS, WAS, and IBM Installation Manager using the silent approach.

I would recommend other users to definitely consider TWS, as it has proven to be a powerful tool in our environment so far.

The features most valuable to us are the diverse array of scheduling options, including run and exclusion calendars (holidays). The dependency management system allows us to build just about any scheduled batch process imaginable. Tivoli consistently runs jobs as scheduled and precisely as defined. This is critical, as we need our scheduler to be dependable and consistent.

We can also export job and schedule definitions to a flat file and then import them into a higher environment. This is critical for treating jobs and schedules as code, checking the definitions into version control, and deploying them cleanly. We can manage jobs and schedules ourselves without needing to turn to a designer in production.

Tivoli Workflow Scheduler provides a centralized tool for all scheduled jobs, including design, monitoring, and support. With thousands of jobs running each day, this would be unmanageable using Windows scheduled tasks, cron jobs, or a home grown scheduler based on Quartz or similar framework.

One area of improvement is the user interface. While it is extremely functional, it’s not very user friendly and it’s difficult to visualize the flow of a complicated job schedule. A visual flow would be very useful to see how far a schedule has progressed, where it failed, and why.

We’ve been using Tivoli Workload Scheduler for 4.5 years.

We have had no issues with scalability. However, we have less than 100 batch servers across all environments, so our environment is not very large.

I can’t rate technical support. I have never worked with IBM technical support on an issue with TWS. However, our number of support requests has been low due to the reliability of the product.

I have not used a previous solution. TWS was already in use when I started working here.

The initial setup is somewhat complex when taking into account the following factors:

• the supported\recommended database types are Oracle or DB2 for Windows shops
• deployment of agents across all batch processing servers
• security configuration
• load balancing and redundancy on the MASTER

Upgrades are also complex as all existing jobs, schedules, and other entities must be ported over and tested.

I have not dealt with pricing or licensing.

I did not evaluate other products as TWS was already in use when I started working here.

Before purchasing Tivoli Workflow Scheduler, check out Automic One Scheduler. It’s much more expensive, but it does a lot more than just scheduling. If you are using TWS, make sure you provide training to your batch developers. Design a model for promoting jobs and schedules between environments. Utilize “composer” extracts and check your jobs and schedule definitions into a version control repository.