IBM Workload Automation Reviews

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.

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.

Automation capabilities with dependencies, long-term plan and modifying current plan, and ease of use are the product's most valuable features to me.

When there is a holiday or emergency closing, we query the Long-Term Plan to identify what will or will not be running during the closure. Application owners review and sign off of the plan, making everyone aware of the scheduled jobs for that time frame.

We are using an outdated version. We had issues with the file dependencies. We are uncertain if it was due to application setup or the product itself.

I have used this solution for 6.5 years.

This has been a dependable product for us.

We did not encounter any scalability issues.

We have not utilized technical support in six years.

As with any new application/utility, make sure you have good training; if possible, request a trial version to become familiar with product; and ensure it meets your needs.

• 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 introduction of the TDWC (Tivoli Dynamic Workload Console) was nice to have, preventing additional code installs for the JSC.

It gives end users the ability to monitor their jobs/workflows in real time, which helps with MTR when they experience issues.

When deleting jobs from the database that have interdependencies within other job streams, there is no warning about those dependencies, which could cause other job streams to have issues later on.

We starting using it back when it was named Maestro 5.X.

I did not encounter any stability issues. It’s been a very stable and reliable product.

We have not had any scalability issues.

I rate technical support 9.5/10. I have not opened any cases over the past 1.5 years. They have always been very supportive and helpful in the past.

Initial setup was fairly straightforward. However, configuring and setting up the TDWC was somewhat of a challenge; we had to consult with Level 3 support several times to get things working properly.

Consult with a third-party vendor to assist with price discounts.

I did not evaluate other products before choosing this one. However, they are asking us to look at other solutions, due to cost for licensing the TWS product.

I would have to recommend installing the TWS Master/Backup Masters on a Linux platform, not Windows.

TWS has two command line interfaces to help manage items in the active plan and database. This allows you to create custom scripts to make mass updates to job definitions in the plan\database. You can even schedule these custom scripts to make the updates at a later time (e.g., holding a set of jobs prior to a planned outage and releasing after). It also has an event processor that lets you define custom rules based on certain events (e.g., when a job fails, when a job hasn’t finished within a certain time or within 30 minutes of its predecessor, when a file is available, when a job is stuck, etc.).

Aside from basic scheduling features and Windows/Unix job types, this product gives us a lot of options to integrate with other systems:

• Custom plug-ins (SAP, DataStage, PeopleSoft, Cognos)
• Database & integration job types (Oracle, MS SQL, Web Services, J2EE)
• File transfer and remote command job types

It is a great way to centralize your enterprise workload to provide better visibility to support groups and better cohesion between applications. Mobile app features are also available to empower users to monitor\manage their workload on the go.

The web UI is a bit cumbersome in terms of navigation, although it seems some improvements were made on the most recent release, v9.3. Also, scheduling is driven based off of a Symphony file, which is a flat file that outlines scheduled work for the day and its progress. This file is prone to corruption during networking/hardware issues. TWS also has a daily refresh process that refreshes the Symphony file each day. Any permanent changes to the TWS network are dependent on this process.

Time zone management can also use some improvements. We have to schedule creatively to account for the hard-coded plan start/end times with other time zones. Ideally, it would be a seamless effort.

I have used it for four years.

None; overall the product is very stable, but can give you odd results if the environment is unstable (hardware\network issues). Once the environment issues are resolved and job scheduling has resumed, you might still experience strange behavior with dependency resolution and cyclic job functionality, which typically clears up with the next daily refresh.

None; we’ve had no issues with scalability other than time zone management, which requires some creative scheduling scenarios to account for the hard-coded plan start/end time and time differences between master server and remote agents.

7/10; technical support is virtually impossible to get via direct phone call. You have to rely on trouble tickets and wait for a return phone call, which can take several hours depending on what time of day you are calling. You will need to keep constant follow-up on your ticket, as well, because it can slip through the cracks and go unnoticed for days. However, once engaged, especially on a conference call, the team is knowledgeable, courteous and very helpful.

Initial setup was somewhat complex, although it might be because we installed on Linux. Windows might have been a bit easier using the installation wizards.

It can get costly, as expected; IBM uses a Processor Value Unit (PVU) licensing model, which can be cumbersome to maintain.

I’ve used BMC Control-M in the past, at another company.

This product is a great product overall, but can behave strangely if any environmental issues occur (hardware/network). A lot of the issues we face, however, are supposed to be resolved with the later version. I’ve seen some demos of the latest release and it seems like large improvements have been made in terms of functionality and user experience.

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