IBM Workload Automation Reviews

• Support for multiplatform workload automation in a single solution
• Versatility of plan-based and event-triggered scheduling in a single solution

Our firm supports batch processing across many platforms from mainframe to iSeries and open systems. TWS enables consolidation of disparate workloads in a single database, removing the need for engineered interfaces between platforms and enabling simpler job to job dependencies and end to end management and monitoring of workloads.

Service-level management is a challenge using native TWS facilities. TWS lacks sophisticated predictive analytics capability. The limited analytics it does offer is predicated on user-defined variables such as job run duration estimates, which if miscalculated render outputs unreliable.

Another area of improvement is in job schedule design lifecycle management. TWS lacks robust automation for promoting job schedules up through testing cycles on to production deployment, requiring substantial manual operator intervention to prep schedules for deployment from one environment to another.

I have been using it for over two decades.

Stability of TWS is relatively good. Notably, most issues I’ve experienced personally have stemmed from distributed schedules, i.e., z-centric.

Scalability also is relatively good. Our firm also supports TWS/d schedules, which by comparison are significantly less scalable.

IBM’s technical support is good. We have a good relationship with their L3 Lab in Rome, and there’s frequent engagement through user group events throughout the United States, for example, ASAP. Unfortunately, ASAP does not operate outside the US.

We’ve supported numerous solutions at our firm, such as CA7, Control-M, Zeke. We chose to standardize on TWS for a number of reasons, including the fact that TWS hosted the majority of our workloads relative to other solutions, we possessed ample resources who specialized in TWS over others, and TWS best met the needs of our business.

Setup can be quite complex, especially when on-boarding workload that’s migrating from another solution. In those cases, extensive testing is required to ensure that all logical dependencies are properly defined, particularly where the legacy solution’s constructs do not have a like-for-like construct in TWS. JCLs and scripts also very likely require modification to meet TWS syntax requirements.

Compared with the other primary workload automation solution we use at our firm, CA’s Autosys, which is a purely event-triggered scheduler, the limitation with a purely event triggered scheduler is you must have round-the-clock expert analysts to support 24x7 operations For example, if a new deployment must be installed on a weekend at an odd hour, someone must be available at that specific time to support the activity, load JIL files to the database, etc. There are ways around this limitation, but it requires additional engineering or add-on products, which can be costly. Autosys does feature some advantages over TWS in other areas, which is why it remains a staple solution at our firm.

However, to continue the point, with a plan-based scheduler such as TWS, the scheduler is composed of two unique elements, a Long Term Plan (LTP) and a Current Plan (CP). The LTP is essentially a long-range forecast of future schedules, and the CP contains the present day’s schedule. That configuration enables schedule changes to be staged well in advance and stored in the LTP where they take effect in the CP for the specified implementation date, while the CPs leading up to the change remain unaffected. In a large organization like the one I work at, where we employ a full-scale global command center to support BAU operations, TWS allows us to scale back on expert scheduling resources and have them work a traditional 9-to-5 work day because virtually all deployments can be supported during normal business hours. And our command center employees, who are generally paid less than expert schedulers, look after day-to-day, 24x7 operations.

All workload automation solutions deliver on the basic idea of automating your batch processing. The right choice depends on your unique business requirements, such as the size of operations, mix and complexity of workloads, etc.

The solution comes with a scheduler. It contains a file for receiving things from external sources. We trigger the file, on which basis the subsequent business practices are kicked off, one after the next. This means that there is dependency on the file dependency. The subsequent steps in the business practices kick off, automatically, once the file is loaded. 

The performance of the previous versions could be better. We encountered certain issues with the lower version of it, the 9.2. Things have greatly stabilized since then. However, as with any IBM tool, things are a bit tricky. I would give a rating of four or five out of ten, as we encountered certain issues with the domain controller with the lower versions. 

It would be nice if we could get support for earlier versions. Generally speaking, IBM insists that we move on to their latest one. 

In respect of the dependency diagrams, the job dependencies across the business process should be improved. 

I have been using IBM Workload Automation for three or four years. 

The project we worked on involved the running of nearly 24,000 job instances in a single day, so I would say that the solution is stable. 

We do not have plans to increase the number of users of the solution.

We regularly reach out to technical support when dealing with issues that are beyond our control. 

We did not use a different solution prior to IBM Workload Automation. 

While the installation is fine, it requires the involvement of an IBM engineer. The solution is easier to install for those who are well versed in the IBM world, but this is a bit difficult for someone who has a background in application development. The process is easier for someone who has experience working with IBM tools. 

One can handle the installation on his own. 

Including management, fewer than seven people are needed for the deployment and maintenance. This will always involve an administrator. There will also be a program manager involved, the rest of the team consisting of developers. 

The contract is with the customer with whom we are working, so IBM is not directly involved in this. 

There are approximately 50-plus users making use of the solution in our organization. 

My advice is that the implementation be handled by someone with the requisite knowledge. This will be difficult for someone who is not properly acquainted with IBM products. It should be done by someone who knows the IBM environment, who would find the process much easier to handle. 

I rate IBM Workload Automation as an eight out of ten. 

Product administration with minimal scheduling usage these days. Installing, configuring, and administering distributed agents and integration with multiple services and applications.

Provides a robust, full spectrum enterprise-wide WLA platform. I have practical experience with all of the major "Enterprise" WLA products (Control-M, CA-7, and Zeke). None of them have the functionality and ease of use of TWS.

The DWC, when configured correctly, is a great GUI tool to provide Self-Service Scheduling capabilities to the user community. The variety of agents available allows for an extremely flexible Enterprise WLA solution. The WAPL (formerly SOE) functionality is one of the major things that sets IWA apart from the other platforms. With its use, you can automate tasks that other platforms can only dream about.

This may not be the norm, but slow down on the releases a bit. I fully understand that IWA functionality is increasing at an amazing rate, but trying to keep up with the upgrades is rough. Figure out a way to speed up the DWC response a little.

None! It's indestructible, and if configured correctly, and easily recovered in a disaster scenario.

None! I have supported this product in literally 100s of different environments and its unmatched in its ability to scale to any size.

Let us be honest: It is IBM. They may not have invented arrogant, but they perfected it. 

If you make it clear that you know what you are doing and you get support involved, it is as good as it gets. I have been given direct cell phone contacts to Product Development in Rome (when it was still there). They cared enough to help at that level.

I am currently supporting both IWA and CA-7 while my company decides on which direction to go forward.

With any experience whatsoever, IWA is as simple to install and configure. You basically fill in some blanks and run the setup jobs. They create all of the STC, panels and skeletons that you require.

In-house.

If you are running an IBM Mainframe, why would you want any other product as your z/OS based WLA "hub" ? 

To my knowledge, IWA is the only WLA product that will provide "parallel tracking" capability to assist in upgrading from one platform to IWA.

Not applicable. I have used IWA, CA-7, Control-M, and Zeke in the past.

Having used all of the major WLA platforms, I believe:

1. IWA is the most user-friendly and feature-packed product on the market today. 
2. Control-M is a close second (even though there are rumors that BMC is shopping it around). 
3. As for CA, at this point it's hard to tell what CA's Strategic Vision is going forward. They have ESP, Dseries, and now Automic, yet they are keeping the old dinosaur CA-7 alive because they can't figure out how to get all of the old legacy clients off it without major heartburn.

The event notification feature is beneficial since it allows for prompt and immediate notification in relation to any errors occurring in the system.

The IBM scheduler allows for easy and seamless execution of the automated tasks in order to ensure data processing.

The integration and monitoring within the extended agents such as SAP, PeopleSoft mainframe etc needs to be improved.

Extended agents such as SAP, PeopleSoft, CA-7, etc do not have the ability to trace child jobs or dependencies within the extended tools. The ability to do so would be a great added-feature in the next iteration of the application.

I have used this solution for five years.

8.5.1 is not stable, we've since moved to 8.6 but the front-end GUI was very slow. We've since migrated to a 8.6 back-end with a 9.1 front-end.

The system is remarkably stable on Unix/Linux/extended agents. There were some connection/configuration issues on the Windows machines.

IBM TDWC makes scalability and functionality easy and fast.

One drawback would be the mail server IDs are maxed out at 6-7 servers per ID (IDs are classified as per the alpha-numeric characters A-Z and 0-9).

IBM customer service is great. Dedicated account managers make support and technical assistance very easy.

The PRBs with IBM make support and troubleshooting easy and efficient.

We have not used any other solution. Although, we've upgraded 3 times.

The application comes packaged from IBM. Once your Oracle db (or DB2 db) and network connections are configured, you are essentially set and running.

Research your needs versus the cost and scalability of the product.

We looked at other solutions namely Skybot by HelpSystems, Tidal by Cisco, CA-7 from Computer Associates and Control-M by BMC.

Research your needs versus the cost and scalability of the product

• Seamless integration with different applications like Oracle, SAP, Hadoop, JMS etc.
• Web console with single sign on feature.
• TWS as a tool has features that integrate with different applications and backend technologies, as mentioned, to run the jobs more native to the platform. Say, for example, if I would like to trigger a SAP job from TWS scheduler, I can specify most of the parameters from the TWS forms. As an enterprise scheduler, I have more control over most of the enterprise applications to which it is connected to.

Improved migration/upgrade features helped us to reduce the time of upgrade.

TWS is evolving from V 8.3 to V9.3 on the features and no major changes on the architecture. The user experience side of the console is being improved in all these versions, however, the console is not very fast as expected.

It would be good if the TWS consoles and front end reporting explores different users like business, technology and application teams and seamless and faster experience like mobile apps.

If these supported applications would be provided without additional licenses, it would be good.

Yes - UNIX installation, we encountered issues due to not having sudo root access.

In some windows installations, we faced issues with a gap in the path name, ex: "C:\Program Files\IBM".

No.

No.

3 out of 5 - in cases of high severity production issues, the SLA for PMRs (Problem Management Records) is 2 hours. However, from a business standpoint, I would not be happy to have my business down for 2-3 hours.

No

Initial setup for TWS 9.2, I find it complex, since there are number of components needed to be installed with no clear understanding of why those components are used and what is a pre-req for what.

However, I did find the installation for TWS 8.6 to be pretty straightforward.

In-house.

Seems very low and rate of realization is too slow for simple networks. However, good for high investment and complex scenarios.

There is a general perception that pricing and license costs are too high with the conventional model, like per CPU based prices.

However, IBM is trying to use the per job pricing in the cloud model.

No

Yes, IBM has to review the non-cloud low pricing models and invest in architecture based revolutions.


Additional integration to IBM Watson for analytics would be more helpful.

Workload automation (WLA) these days is no static business. It’s all about running the right workload sequence, at the right time, often triggered by a variety of possible (combination of) events. For instance, we use this principle for running a daily Oracle backup workload batch, which (per backup) involves different systems that in real time have to exchange certain real-time information to be able to successfully end and register the backup in RMAN. Therefore, we use complex event rules that monitor events during the backup process, take care of passing the desired info from one system to the other, and dynamically submit certain jobs that cannot not be defined in advance.

ERP (SAP) connectivity: Thanks to this technology, we were able to fully integrate SAP OS, ABAP and BI (proceschain) workloads with non-SAP workloads, so that a complete business process involving SAP and non-SAP systems could be modelled within one TWS batch. Example: a non-SAP MFT job delivering data @ SAP-PI; in-time PI channel trigger modifies the data for next job; SAP ABAP job works the data into the system involved.

Conditional Branching: WLA often is about critical paths that determine if a batch will be able to end just in time. For instance, C.B. makes it possible to dynamically decide if parts of a predefined batch can or should run in sequence or parallel, depending on the outcome of a certain measured condition, therefore able to meet end-time requirements, even when parts of the batch encounter delay.

HA-DR implementation: No system engineers are required to realize value from these resources @ the application level. TWS makes it possible to use resources, provided at the Application Management level, to meet business requirements for high availability and disaster recovery (HA-DR). We use these resources a lot, not only in case of disaster (e.g., scheduling plan breakdown on master manager; switch to backup-master manager management), but also when TWS management systems in one DC need technical maintenance. In that scenario, we simply switch all our TWS management activities to backup counterparts in another DC, that silently have received up-to-date data from message broadcasts within the TWS network.

The tool made it possible to automate the technical workflow within complex business process models, within a heterogeneous network hierarchy, consisting of fault-tolerant distributed agents, managed by (master-)management agents.

The tool made it possible to fully automate actual job-workflows that represent complex end-to-end business process models (BPM’s). Those workflows run on systems that reside in a distributed, heterogeneous, logical agent-network (fault-tolerant, ‘extended’, SAP R/3, SAP BI and even cloud/dynamic (e.g. Salesforce, Microsoft SQL) brooker agents).

This agent-network itself is managed by (master-)management fault-tolerant agents that periodically provide all the agents in the network with a static (predefined) scheduling plan for a certain future period of time, and also house a so called event-processor, that is able to have the master-management agent submit just-in-time defined workload into the actual running BPM, as a result from detected events within the network.

Today, TWS (TWA) has evolved into version 9.x and the product is now also available as a cloud-provided service (the management parts, from IBM SmartCloud).

I think that is a good and modern development, but the first v9.x releases (and maybe also the latest, I don’t know) lacked the event-driver WLA functionality that was already available for years in older on-prem versions of the product.

That doesn’t help IBM have customers migrate from older on-prem versions to these modern cloud-provided versions, when they would like to migrate.

IBM should have its cloud service deliver at least the same functionalities as their on-premise service has been delivering for years.

I have used it for more than 10 years.

No, but it it has been a joint effort with IBM Tivoli L3 support, PostNL IT RHEL and Windows administrators and a dedicated WLA coördinator / TWS administartor.

I have not encountered any stability issues at all. No other IT infrastructure @ our company has proven to be as stable as our TWS v8.5.1/8.6 network and all its components.

I have not encountered any scalability issues at all.

Very high. Excellent support, dedicated to their customer

I receive very good support from a real product specialist.

Over the past 10 years, I frequently contacted IBM to have a ‘PMR’ registered concerning bugs, problems during admin operations, advice on best-practice batch modelling and in one case, for detailed help during a complex scheduling-plan recovery procedure that did not lead to the desired result. I encountered my own knowledge limitations, but was not given the time to acquire that extra knowledge first.

We did not previously use a different solution. We started implementing a WLA infrastructure in 1996 and bought the Maestro 7 product from Unison. That product evolved into TWS 8.2 / 8.3 / 8.5.1 / 8.6.

Initial setup was complex; it involved automating huge complex business process models for (nowadays legacy) order, contract and invoice management applications, although limited to mainly workloads for the HP-UX operation system. Later on, the models became less complex, but the agent landscape became more heterogeneous (Solaris, RedHat Linux, SUSE Linux, HP-UX, Win 2003, Win 2008, SAP R/3, SAP BI).

Implementation has been a joint effort with IBM Tivoli L3 support, PostNL IT RHEL and Windows administrators and a dedicated WLA coördinator / TWS administartor

No idea how to calculate the ROI in Euro's or Dollar's, but for sure it was worth the investment.

Make your TWS infrastructure auditable by IBM (or to its partners) to be able to benefit from sub-capacity PVU licencing when your networks use a considerably amount of virtualization technology, but above all, when possible, move to cloud-provided TWS management services, to benefit from more modern ‘pay-per-use’ licensing models.

We considered starting with Redwood Cronacle for WLA on SAP, but decided to stay with TWS because of the better integration between SAP and non-SAP workloads, and the minimal amount of effort we had to put into education.

Just contact IBM sales and make the first implementation of the product at your site a joint effort between IBM Tivoli L2 personnel from Rome and your WLA administrators.

The most valuable feature is the job scheduler.

I would like to be able to access the return value or result from one job, in the following job. This is a feature that other solutions have and is very helpful. I had to create my own workaround for it because the capability is important for me.

It would be helpful to have a mobile app that could be used to follow the job schedule. Most IT applications now have mobile app support.

I worked on IBM Workload Automation for close to 10 years, although I have recently changed companies and no longer use it.

The stability is good. 

We did not need to scale this solution. We had close to ten people who used it.

Technical support from IBM is very good. I have worked with different vendors and I know that it is sometimes difficult to get a good level of support, but there were people supporting this solution who were very good and always helped.

The implementation was done by external consultants.

I would rate this solution an eight out of ten.

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