With its roots in mainframe job scheduling, workload automation is often seen as a relic in today's age of cloud, Big Data, mobile management and DevOps. Do we even still need workload automation as a separate discipline or should we simply roll the management of batch jobs into other automation disciplines, such as IT process automation? Is the market for workload automation software stagnating or is there still potential for growth?
To answer these questions, we need to talk to the people who actually do the work, which is always preferable to theorizing on the white board. When talking to workload automation engineers today, we make a few essential observations:
More business focus: Engineers responsible for job scheduling are becoming more aware of business requirements. They typically know the impact of the jobs they are managing and are concerned to correctly prioritize and safeguard these jobs for performance and reliability.
Complexity is exploding: Business units are flooding the workload department with, often last minute, requests to create and manage the jobs they need to operate their applications.
Tools are the same & budgets are declining: Despite much greater business requirements, workloads are mostly managed with the same tools that were in place before the days of cloud and Big Data.
Is Workload Automation still Critical?
files they require to process critical transactions. Big Data analytics tools are left without some or all of the input they require to produce business relevant reports. Cloud portals are not able to deliver the requested business services in a timely manner. In short, workload automation is the backbone of most of today's mission-critical IT projects and therefore is more important than ever.
Will Workload Automation Merge with IT Process Automation?
While the creation of a central automation discipline seems like a great idea, we need to take a look at today's reality in enterprise IT. Typically, workload automation is regarded as a separate discipline with a separate budget, separate staff and an entirely separate set of responsibilities. The way this usually works is that application owners come running to the workload automation team to figure out what is needed to ensure optimal performance and reliability of their application. Once this is done, it is up to the workload automation department to ensure the ongoing reliability and performance of all of the necessary jobs. Merging workload automation with IT process automation would require a major reorganization of the entire IT department as the problems solved through IT process automation are very different in character from the workload automation ones. While it would be ideal to consolidate all automation disciplines into one centrally governed unit, this is often (mostly?) not feasible today. EMA research will shed more light on this topic shortly.
How Can We Tie Workload Automation Closer to the Business?
proactively manage workloads based on SLAs. If at all, the SLA aspects of workload automation are managed in a static manner, through manually inserted and maintained control jobs. Once there is a failure, the appropriate engineers scramble for a solution, often without the ability to prioritize debugging tasks. Wouldn't it be nice if we could properly tie workload automation into business service management? The better the workload automation department understands the business impact of the jobs it manages, the better it can focus its effort on prioritizing the management of these jobs and the jobs they depend on. The upcoming EMA research study on Workload Automation will investigate how customers can benefit from analytics and SLA management solutions to more efficiently support the business.
EMA Research Will Deliver Detailed Answers
I am personally excited to conduct our EMA research project on the impact of cloud, Big Data, analytics and mobile enterprise management on workload automation. This project is aimed at providing a much needed reality check regarding what customers really need today and in the future. I look forward to blogging about some of the most notable results in June or July.
