Trends such as virtualization, cloud computing, and agile development have all prompted the need for leaner, more efficient, and more highly automated ITSM processes. Probably one of the things that is most misunderstood about ITIL is that it is a highly scalable framework. Organizations need to understand that if their processes are bureaucratic, it’s most likely because they have made them that way. So in the spirit of continual improvement, what’s an organization to do… throw out ITIL and start over?
That’s what the DevOps folks would have you think. If you haven’t heard of DevOps, according to Wikipedia the term refers to the emerging understanding of the interdependence of development and operations in meeting a business' goal to produce timely software products and services. DevOps has been referred to as (1) a movement, (2) an approach, and one blogger went so far so refer to it as (3) a “framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups.” Launched by a group of European system administrators, the spirit of DevOps is relatively sound… let’s all understand that in this day and age, technology (and more specifically, software) is and must change – and change FAST – or the business isn’t going to make any money. To move quickly, and yet not so quickly that we wreak havoc of the production environment, the “dev” and “ops” folks have to work together.
Proponents of the DevOps movement talk about things like culture change, unified processes, and unified tools… all concepts that are central to ITIL. So where is the disconnect?
We all know that ITIL understands the interdependence between development and operations and the need to foster cooperation, learning, and coordination. We also know that, at times, it can seem that ITIL does so in a heavy-handed way. Controls imposed by governance and security and sometimes just by management’s need to be in control can all add up to less than efficient processes.
So what’s an organization to do? It’s called continual process improvement. It’s remembering that processes are never “done” and there is always room for improvement. It’s remembering that process maturity and culture change takes time and doesn’t end when the processes have been documented and are being supported with a tool.
Continual process improvement involves continually looking for ways to streamline and integrate processes and automate the associated activities. Here are a few good places to start…
Models - Earlier this month, more than 240 people attended Jayne Groll’s webinar Using Models for Incident, Change, Problem and Request Fulfillment Management. The Q&A session associated with this webinar went on for an hour. Models are a basic concept that may be missed during the initial design of a process. Even organizations with advanced ITIL knowledge may fail to fully utilize this valuable concept. Models = efficiency, models can easily lead to automation, and models are a much needed helping hand at a time when we’re all being asked to do more with less.
Standard changes - Folks often understand the concept of standard changes but apply that concept only to basic things such as installing desktops and commercial software. Virtualization and agile development are prime candidates for the use of standard changes, as are many of the other activities that IT organizations perform on a daily basis. A good place to start is by initiating a project aimed at increasing the number of standard changes. This could involve first further defining what a standard change is and then a set of specific procedures (models) for putting those changes in production. One client shared that they set up a temporary CAB whose role is was to evaluate and implement standard changes. Once the criteria had been fine-tuned and the most frequently performed standard changes had been formalized, the temporary CAB was disbanded. This enabled them to quickly increase the number of standard changes without impacting the work of the main CAB.
Release and deployment management – This process handles much of the coordination between development and operations and is increasingly becoming a hot topic for organizations. A recent ITPI study concluded, “Change management is often identified as a logical starting point for ITIL implementations. However, release management should be the destination for those organizations wanting to achieve performance gain from standardizing on ITIL change and release practices.” An important aspect of the release management process is the release policy. It is often the release policy that dictates how quickly changes can be made and when. In Service Transition, the release policy is an important component of overall transition planning and support. Today, company’s release policy and release management process and procedures must be scalable and flexible. Are there some changes that require tremendous rigor? Sure. Are there many other changes that can be planned, tested, and deployed more quickly (by using models, templates, and automation)? Absolutely.
ITIL can seem overwhelming, particularly at the Foundation level. It can at times seem impractical to those “dev” and “ops” folks who are struggling to get by. There are tremendous opportunities, however, to demonstrate how scalable and flexible ITIL can be and to show how it can be used to do what we all need to do in this day and age… speed up!