In my previous post I wrote how organizations can follow ITIL Framework guidance to drive continuous improvement of ITIL Service Management Processes, through the application of Lean IT thinking. In this post I will explore this further by discussing how the role of Change Manager is evolved when using the Lean IT practice of Infrastructure as Code. Infrastructure as Code (IAC) applies the concepts of Lean Programming and DevOps to the management of Infrastructure.
The ability to define infrastructure as software has revolutionized how services are delivered. (Here I speak of service in general as discussed by the ITIL framework with the focus on outcomes and customer value). It is possible with virtualization technology and the cloud to quickly spin up environments to test and run services. The direct configuration update by an engineer logging into servers, routers and other infrastructure components (which ITIL defines as Configuration Items) is replaced using IAC with indirect modifications using Configuration Definition Files and applying some tooling to effect the change. This seemingly small change of defining the next state of the Configuration Item (referenced in this post as CI; not to be confused with Continuous Improvement or Continuous Integration) has transformed Infrastructure from largely being a nest of unique CIs (aka Snowflakes) to a repeatable and consistent collection of nodes. Moreover, with IAC we can transform the role of Change Manager from being a traffic cop to a strategic role that improves the lives of the infrastructure engineers.
Change Management is seen by IT as a necessary evil to ensure we have good governance. Traditionally, Change Management has largely been a manual inspection and review process to prevent the organization to avoid failures and risky behaviors. Lean IT is not about removing the important governance function but to make it more streamlined and ideally automated. With our example of IAC we propose that the Change Manager (CM) is not reduced to inspecting some proposed change to the infrastructure (or worse in an emergency just crossing their fingers while the most senior engineer makes their best educated guess to what is needed), but they are providing valuable oversight and QA to the Automated Change Management Process.
To be specific, the CM could work side by side with an infrastructure engineer to put together a Vagrant workflow to manage local sandboxes so that through an infrastructure definition file tool an IaaS is delivered on the desktop to validate that the configuration changes proposed can be first tested in the engineer’s local sandbox. This first critical test of the proposed configuration change is significantly more valuable and reliable than the CM reviewing some document on the change. The Change Manager becomes a strategic resource by validating the infrastructure definition workflow and not just the person rubber stamping the change documents. The CM ongoing responsibility then is to ensure that a defined process using the infrastructure definition file is consistently used, and we don’t have rogue engineers SSH’ing into servers patching them. The continuous improvement work for a Change Manager is to identify additional improvements to building dynamic infrastucture such that governance is built into the process.