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.
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.
- Business Process Automation
- Market Guide for Workload Automation
- Magic Quadrant for Job Scheduling
- IT Process Automation: Embrace IT Process Automation Technology As Your Foundation To Industrial IT
- Workload Automation: Is BSM The Future Of Workload Automation?
- Ensuring IT Efficiencies Through Enterprise Process Automation
- EMA Radar for Workload Automation
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.
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 started off handling on OpenVMS back in the 1980s. 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.