Workload Automation terms have gone largely unchecked over the last few years. What was once simply referred to as “batch processing” has now evolved (or devolved) into a multitude of terms such as “application automation,” “runbook automation,” “resource automation,” and more.
What are the differences?
Largely, there are none! Whether you’re running Hadoop shell or pig scripts on Linux, scheduling batch processes against SQL or Executables on Windows, or simply running Workflows of predefined steps against multiple environments, these terms all hark back to the core concept of batch processing:
- Scheduling a process to execute at a specific time;
- Ensuring that pre-conditions and SLA’s are met; and
- Sending notifications when there’s an issue.
Another term you might hear added to the mix is “job scheduling.” Traditionally, job scheduling tools were on their own on a platform-by-platform basis, typically built into operating systems. But the difference between workload automation and job scheduling depends on the capabilities of your solution. Workload automation encompasses an advanced, more flexible form of job scheduling.
Why the Jargon?
So why the recent and increasing fragmentation? One source is the analyst community. We’ve seen a rise in analysts attempting to differentiate their research from that of other analysts. In some cases, individual analysts even compete for turf within the same firm.
Focus on the Stalwart: Workload Automation
Technology professionals who use these analyst reports to support important decisions need to read between the lines. While their newly minted terms may initially cause excitement, they fail to recognize the maturity of the discipline of workload automation. Born in the ‘80s on OpenVMS, JAMS has weathered the jargon and the evolution of batch processing.
So, whether you’re looking to automate “runbooks,” or have large amounts of data to transact, or need to set up processes to run across multiple platforms while hooking into a multitude of APIs, you’re still fulfilling those same batch processing requirements that JAMS has been handling for years. Sure, we have improved performance and efficiency, added multiple APIs and application integrations, but we still prefer to call our solution what it is: a workload automation solution.