Workload automation, IT’s little secret
Content Copyright © 2014 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
Workload Automation is one of IT’s best kept little secrets. I’m not talking about one-off scheduling tools for individual applications—which are hard to manage and often lead to increased complexity and consequent errors—but proper workload automation suites such as CA Workload Automation AE, formally CA AutoSys, which provides visual maps for the orchestration of an operational workload. Not a lot of people know this, apparently, but one of the best ways of optimising throughput from parallelised workloads (and gaining insights from operational metrics) is an optimised job scheduler, with open APIs to allow integration with other tools. Well, the people running big datacentres are aware of such things but the business often isn’t; and all too often, neither is business-level IT. Nevertheless, Workload Automation is often a really good way of delivering business outcomes cost effectively, by orchestrating what you already have.
The comparatively low profile of Workload Automation may change as one of the results of the DevOps revolution. DevOps is all about removing bottlenecks by breaking down silos with cross-silo automation; and as DevOps increases its scope to encompass the holistic delivery of business outcomes, instead of just faster software delivery, it will find that Workload Automation is a key part of the message.
Karthik Mahadevan (Sr Principal, Product Management, Workload Automation) of CA technologies says that: “business is driving a lot more of the IT spend these days, and one effect is that IT and Business are working more closely together than ever before. IT automation is one of the largest components of DevOps along with other areas such as Agile development, service virtualisation etc.”. So CA Technologies is increasingly selling Workload Automation to the Business—a good thing, he says; and I’d agree.
We were talking about the new integration of CA Workload Automation AE with SAP Solution Manager. What this means, in essentials, is that people working in SAP Solution Manager can call on the power of the CA Technologies product without any need to learn to work in a new environment. It’s all part of enabling the CA Technologies vision for using DevOps-influenced efforts to break down automation silos and allow its customers to work effectively across functional areas of the organisation. Note that all CA Technologies workload automation engines have a SAP agent, but only CA Workload Automation AE has integration with SAP Solution Manager
There are two basic use cases:
- To extend workload automation (job scheduling) into a SAP-centric user community. This could involve simply providing a SAP-centric user interface for scheduling a simple stand-alone job or the creation/modification/deletion of a sophisticated job schedule, possibly driven by business users, and fully integrated with SAP Solution Manager and change management.
- To empower business users to monitor/manage job execution within workload automation, with at-a-glance listing of job executions and proactive rule-based SAP BPmon notifications for detailed business process monitoring.
CA Technologies claims that adding its Workload Automation will reduce the cost and complexity of managing mission critical SAP jobs and eliminate any need to manually import CA Workload Automation AE jobs into SAP Solution Manager. This should reduce operational cost associated with automating workloads and increase staff efficiency, as well as improving job documentation; although we imagine that it will be of most interest to enterprises relying on more than just SAP, especially if they already deploy CA Technologies workload automation tools.
We also took the chance to review the CA Technologies roadmap for cross-platform (including the mainframe) workload automation, which has been rationalised over the last few years, from 9 automation engines to 4. Will it rationalise further? Probably not, I’m told, because there are significant customer communities for each engine and few obvious benefits from moving any of them to a new tool. As always, further rationalisation would be driven by customer demand, Mark Warren (Sr Director, Product Management) assures me; in the meantime, CA Technologies is providing middleware integration across all 4 tools for those that need it
The CA Technologies workload automation engines are now:
- CA Workload Automation DE, which offers multi-platform scheduling that lets you manage and visualize a business process end-to-end across all your platforms (including the mainframe), from a central point of control (it is hosted on a distributed server). It supports dynamic critical path, automated alerting and notification (to enable management by exception) and seamless integration with major business applications. Advanced simulation and visualization help you understand the business impact of failures and also help you to coordinate troubleshooting efforts.
- CA Workload Automation ESP, which does everything that DE does, but which is hosted on the IBM z mainframe platform. It uses passive event sensor technology to dynamically initiate workload processes, so you can adjust workloads depending on real-time infrastructure status, available computing resources and service priorities.
- CA Workload Automation CA7, which has similar capabilities to the other tools but is really a mainframe product, although it has cross platform capabilities.
- CA Workload Automation AE, which is another multi-platform scheduling tool with cross-platform capabilities, but which takes a particularly event-oriented approach. It can dynamically respond to business events in real-time; and can map workload processes to SLAs while enabling monitoring and automated service recovery. As well as the SAP Solution Manager integration, CA Workload Automation AE will have SAP business intelligence integration in future
It seems to me that there is considerable overlap here but presumably the user experience and user loyalty is sufficiently different to support different customer communities. There are also differences in SAP support and the SAP APIs intended for all 4 engines are only partially available just now. Also in the future, is SAP process integration (all engines), support for SAP HANA, and integration with the SAP Financial Closing cockpit.
My view is that this all represents a rich workload automation capability, from a vendor who has the vision to exploit its possibilities. However it will need to send clear messages as to the best use cases for each engine, as the differentiation isn’t entirely clear to me today.