The Workload Automation Mindset
The Workload Automation Mindset
Construct a system of workload automation to create realistic and predicatble schedules, and be more prepared for runtime anomalies.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
The Schedule Needs to be More Responsive
Until you can bend time, every business process and workload you manage will need to be constrained by a schedule – a fixed cycle that everyone in the enterprise abides by. Regardless of whether processes take one minute or one hour, they all must fit neatly in the schedule, day in and day out. You don’t get to add a 25th hour in the day just because some SAP job is starting to run longer than expected.
Although many of us still use the term “job scheduling”, the new moniker, “workload automation” provides a more accurate description of what we need to accomplish. Job scheduling makes many assumptions:
- Every job’s completion time is consistent.
- Every predecessor completes successfully.
- Every job’s start time is consistent.
- Every server and network connection is reliable.
In the enterprise, however, lots of little issues make their way into a schedule. Taken alone, these issues often have little or no impact. But, as they accumulate, they begin to affect the cycle of business.
The ability to mitigate these issues is what differentiates a “job scheduler” from a “workload automator.” Here, I am talking about a person. Prior to a company's switch from job scheduling to workload automation, there is often the emergence of a champion, someone who looks at the enterprise’s “schedule of jobs” and says, “This may be okay today, but in order for us to grow, scale, and respond, it needs to be more responsive.”
Enterprise computing is imperfect. Sub-optimal conditions are a normal part of IT Operations, as you can see from the numerous guides on troubleshooting SAS and MVS jobs, or jobs run at Ohio’s Supercomputer Center. The sooner you account for these scheduling anomalies, the more reliably you can automate. Keeping servers online and keeping an infrastructure free from bolt-on customizations and workarounds, are the silent victories of the enterprise automator.
How Enterprises React and Respond
Enterprises that have an automation mindset are better prepared for growth, because they don’t get sidetracked by job delays, errors, and failures that occur during the normal course of business. Without a centralized plan for workload automation you’re likely to see lots of costly overreactions.
Consider a job that starts at 1:00 PM, and usually completes within 15-30 minutes. If that job’s runtime exceeds 30 minutes, what should the response be? Depending upon the job the answer may vary, but enterprises that leverage workload automation, are able to respond with greater efficiency, and with a positive long-term impact.
Which reactions would your organization prefer?
Without an Automation Mindset
With an Automation Mindset
“The job has failed. Drop everything and find out why.”
“We just have to build in more buffer time to allow this job to complete.”
“I hope this doesn’t happen again.”
“The job’s completion time is longer than expected. Let’s set a maximum threshold to make sure it doesn’t interfere with other jobs.
“Let’s look at how this job’s elapsed time has changed over the last hundred runs.”
“Let’s set an alert, so that we are aware when and if this issue happens again.”
Purposeful, calculated responses keep enterprise schedules on track. Sure, there will be some extreme events that demand your undivided attention. But, many “issues” that interfere with scheduled business processes can be resolved by adjusting the means of automation. Simply adding a dependency to, or setting a maximum run time for a batch job could keep a schedule of thousands of jobs running as intended.
Opinions expressed by DZone contributors are their own.