If you are an IT manager, have you ever found yourself stuck in the uncomfortable position of having to choose which jobs are given priority access to essential computing resources? Most likely you have as this is not an uncommon problem. Expecting them to invoke the Wisdom of Solomon, enterprises often bestow the power to decide the workload hierarchy on IT operations. But as most IT managers will tell you, this responsibility is typically more of a curse than a blessing.
A recent blog by IBM Tiger Team member, Xavier Giannakopoulos, titled “You are promoted! Priority lanes in workload automation,” discusses simplified methods of using workload automation to ensure execution priorities reflect business priorities. Specifically, the treatise describes how solutions, such as the IBM Workload Automation platform, accelerate the execution of priority jobs by assigning them more resources (such as software, network, and storage infrastructure) at the expense of less important jobs. In fact, this approach directly targets the value of effective workload automation – enabling practices that cut through complex process workflows to ensure the right data is distributed to the right system in the right format at exactly the right time. Unfortunately, though, it is not always clear which jobs should receive preferential treatment over others.
While it’s true that not all workloads are created equal – or as George Orwell would say, “some workloads are more equal than others” – it is often incumbent on IT managers to decide which workloads will receive superior resources and which will be left to run with diminished performance. However, this is not always an easy decision, and often places the IT manager in the middle of pitched internal political battles. Most organizations (and, indeed, most individual business professionals) believe their workloads should always receive the highest priority from IT operations. Bestowing priority to one particular set of workloads simply because its team leader screams the loudest may be construed by others as unfair or worse … favoritism. What’s needed is a reliable metric that can be used to compare workloads and reasonably justify their priority without arousing interdepartmental politics.
The Information Technology Infrastructure Library (ITIL) set of best practices offers some guidance here. ITIL recommends two key considerations in the identification of service priorities that can be adapted to workload prioritization:
- High priority should be granted to workloads that resolve specific business pain points – that is, jobs that directly improve business performance and reliability
- High priority should also be granted to workloads that enable business opportunities that would be lost if performance was diminished
For each of these considerations, assign a numerical value for each workload in contention (e.g. low priority = 1, medium priority = 2, and high priority =3). The rest is simple math which results in an empirical value that will justify the placement of workloads. Naturally, department leads will likely still argue their job ranking on each of the two criteria, but this then becomes a business decision, not an IT decision, and can be escalated to the appropriate business executive to make the call. This ensures workload placement is in-line with business objectives and gets IT managers out of the path of irate project directors. Which, of course, is ultimately what everyone wants – less political wrangling and more focus on achieving business goals. Once workloads have been appropriately ranked, placing critical jobs and monitoring to ensure their proper execution are easily accomplished with solutions such as IBM Workload Automation. Xavier’s blog provides excellent guidance on how to leverage the right level of automation for better business benefits.
For more information on workload automation and to follow the conversation, check out:
Service Management 360 blogs: http://bit.ly/1anzPYI
IBM Service Engage: http://bit.ly/Qh4bGW
Hashtag: #WorkloadAutomation #EMA
And follow my discussions on the topic at:
The Systems Café blog: http://blogs.enterprisemanagement.com/stevebrasen/