IBM Workload Automation Reviews

• 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 API is a valuable feature as it allowed us to integrate the inventory, change and ticketing systems to fully automate most of the monitoring processes for new devices, decommissioned devices and during approved changes.

The new servers automatically get monitored with the alerts going to the server administrator or application developers, without the need for someone to submit a request.

The alerts automatically go to a command center, when a server is classified as production in the inventory system. The alerts get automatically suppressed during an approved change.

A lot of the automation that we added to the product should come built into it, so that every customer doesn't have to reinvent the wheel. This will eliminate the need for us to modify our code, in order to make it compatible with each future release.

Below are examples of automation that we developed which should be built into the product:

• Integration with the inventory system, so that alerts go to the proper teams. For example, alerts for servers classified as development would go to the apps support team or alerts for servers classified as production would go to the monitoring center. Also, alerts would stop when a server is marked as decommissioned.

• Integration with the change management system so that alerts would be suppressed during the change window for approved changes. Thus, alerts would begin for approved changes adding new servers.

I have used this solution for five years.

There were some stability issues but we lit a fire under IBM's feet and they corrected them.

There were no scalability issues; we managed to deploy over 85,000 server with no issues.

The level of technical support is top notch. If the support team can't fix an issue, they don't hesitate to engage the product development team.

Initially, we were using a home-grown product that didn't scale as well and had no ability for cross-product automation.

The setup was very complex and required on-site support, mostly due to the cross-product automation that we implemented.

Talk to your IBM sales representative to see what they can offer you.

We did not evaluate other solutions.

Talk to other customers using this product, who are similar in size and configuration, so as to get feedback, ideas and what to watch out for.

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.

The FTA agents feature is most beneficial, as it easily resolves local dependencies on the workstation, even when there is a network disconnect between the MDM and FTA.

I belong to a part of the delivery module in our organization. We implement TWS in the customer’s environment. It has definitely improved many different processes in our organization.

There is need to add any type of utility which can convert workload definitions of other syntax to the TWS syntax, during workload migration and conversions. Currently, there is no utility as such with TWS.

For example, there could be one scenario, where the customer wants to switch from the existing scheduling tool to TWS. Every tool has its very own syntax for defining workload definitions.

During migration project activities, it gets very difficult for converting the existing workload syntax to TWS syntax. We need to create our own scripts or different methods, that helps us in achieving this task.

If I remember correctly, the BMC Control-M tool does have such utility of converting any workload definition syntax to Control-M based workload definition syntax, i.e., upto a certain extent. Hence, this is one area where TWS can be improved.

I have been using this solution for more than a year now.

I have not had any stability issues.

There were no scalability issues.

I’ve not had such a good experience with the technical support. At times, I have seen long delays in getting answers/responses.

I started out with implementing the TWS solution only.

Initially, it was complex; during implementation, I faced many challenges.

For licensing, you should proceed with the monthly job executions. Earlier, it also used to have the PVU (Processor Value Unit) license model as well. I am not sure, if this is still there.

Get clarity from IBM and accordingly proceed, depending upon the requirement.

TWS is very much stable on the Linux platform but this doesn’t mean that it can’t go well with Windows. Looking at the OS maintenance and other patching activities, it is better to go with Linux.

Scalability is not an issue with TWS. Make sure you have all the pre-requisites met before implementing it. It will work all fine.

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

With FTA (Fault Tolerant Agent) on remote servers, you have Agents to run jobs. An FTA does not need a network connection to do the job, except when the master sends the daily production plan to the FTA. This feature is very nice because POF is only one time a day. So FTA removing POF from the final schedule is very valuable.

Have a more simple GUI for end-users. This is simply because I am used to using the command line. The GUI is not easy for non-technical users.

I have used the solution for 15 years.

We had stability issues when managed by not enough skilled people.

There were no scalability issues using DM.

Technical support was excellent.

Initial setup was simple.

It is expensive.

Spend time to define a robust architecture, and day-to-day operations with a specialist.