By David Crane
Combined with the demand for greater flexibility in delivering infrastructure and application services, my customers are implementing cloud environments, and they’re looking to take advantage of the automation capabilities of those platforms.
Automation, in its simplest guise, offers consumers an “app-store” style experience, where they can browse to a self-service portal for requesting cloud services and select virtual machine templates or blueprints that have been created for them. As part of the provisioning process, consumers can also make changes to the virtual machine properties such as network, storage, compute, and memory within the ranges for which the blueprint they are using is configured.
Part of the provisioning process can be the approval of that request from that user’s line manager, or a budget holder for that service or line of business. The traditional way of automating this step is to allow the approver (again via the self-service portal) the ability to authorize the request.
Consider, however, the typical activities that take place during this step, as shown below:
Activity time that is conducted by a toolset is typically a very small percentage of the overall task time, and those customers who try to optimize this time typically get a poor ROI on their efforts.
Instead it is reducing the activity time that is carried out by people—and subsequently reducing the wait time for these activities to be carried out—where the benefits of automation are to be realized.
Many IT organizations attempt to do this through the implementation of approval policies, which are based on a set of rules around tangible parameters such as service cost, sizing, numbers, and so forth.
The focus then becomes configuring automation toolsets (e.g., VMware vRealize Automation), using these rulesets with the expectation that it should be a simple case of rolling out the approval policy to replace the “people approvers” and all will be well in the world.
However, as my customers are discovering, without careful consideration and consultation of the people element of the process, the carte blanche introduction of approval policies frequently meets resistance and pushback from those people approvers whose wait time is causing the benefits of automation to not be realized in the first place.
Reassurances of “trust in technology” or “trust in policy” usually falls on deaf ears, with counter arguments from the people approvers of needing to oversee and meet compliance, governance, and security requirements especially in those sectors (e.g., financial), where fierce regulation exists.
A compromise is then subsequently drawn up, with SLAs or OLAs determining response times from people approvers when requests come in, or approval policies existing for small-value or perceived low-risk requests, which offer minimal benefit.
While such agreements may suit the people approvers and placate the personal and political problems, they are a blunt instrument and still constrain the agile technology platforms that have been put in place, to the detriment of the business, and to the benefit of competitors that have addressed the problem in a different way.
My customers who have been successful in introducing significant approval policies have understood that one of the core reasons for this pushback is that people fear having their responsibilities cut back and the removal of their charter over the approval of the service requests of their line staff and business unit.
Stay tuned for my next blog, coming soon…I will go into more detail, including suggestions on how to successfully allow those approvers to retain their charter, while still introducing significant approval policies, but also achieving further business benefit through the publication of the cost savings, via approval policy-centric dashboards.
David Crane is an operations architect with the VMware Operations Transformation global practice and is based in the U.K.