Are you thinking about putting your ITIL® based processes to rest and because you have heard that ‘doing DevOps’ is better? Do you think that your current service management practices are slow, bloated and you have no chance of transitioning to DevOps? Getting rid of ITIL® is not necessarily a good move; it might just be a recipe for disaster. Let’s examine how DevOps and ITIL® can bring balance and some serious improvements to your capabilities.
If you work in IT in any sort of capacity, it is hard to escape the allure of DevOps. Just like the pop star du jour, it has become quite prevalent in mainstream IT publications and social media channels. In turn, it has upended the industry completely. DevOps has also had an unintentional effect: It has given many of the ITIL® naysayers another bullet to go shoot the old framework behind the barn, call it dead and bury it. However, those that think this way may be shooting themselves in the foot as ITIL® brings more to the table than they realize. Before going into how ITIL® can serve your DevOps initiatives, let’s explore ITIL®’s “bad reputation”, and how it got it through the years. For some, ITIL® has always been a lot of work and overhead. There are so many plans, databases, processes, documents, and artifacts. This notion of hard work has a hint of truth though; if you were to ‘do’ ITIL® exactly as it is laid out in the books, your job will only revolve around managing your service management system (SMS), and not the services you’re providing. This has resulted in many organizations staying within the confines of what they already know how to do (incident, change) before ITIL® got there, and sometimes with the things that they think they understand (problem, knowledge, configuration, availability). IT Service Management (ITSM) vendors deserve a little bit (some would say a lot) of blame as well. Ever since the grand old days of ITIL® v2, vendors have promised ‘ITIL®-in-a-box’ solutions that promise ‘rapid results’ and ‘ITIL® compliance’. What happens next is that: a.) Organizations tend to stay within the safe comfort of what the tool provides, ignoring the other elements that need to go into managing and governing the SMS OR b.) They are not satisfied with what the tool provides, so they pile more on top of what is included out of the box because they think there’s a need for something that no one planned for or built a requirement for
Additionally, many people (and consultants) became ‘ITIL® purists’. These were folks that declared publicly and frequently that ITIL® had to be followed ‘by the book’. They tried turning ITIL® into a standard, but as it is written, it is clearly not. This bloated into unnecessary work and non-value add activities which resulted in many people getting fatigued with ITIL®. This unnecessary work translated to new everyday tasks, and it became too much for most organizations to handle. For example, if it takes more than five minutes to fill out an incident ticket, or a request for change, you probably over-designed and over-thought your process execution activities. Many organizations started ‘doing’ ITIL® because they thought it was a great idea or because they thought they needed to be ‘compliant with’ ITIL® to do their work. Unfortunately, many (conveniently?) ignored the fact that ITIL® requires you to actually go out and understand your customers and their requirements. We all get it; historically, those in IT don’t really like to go deal with those pesky customers. They know too little about what we do. We hate explaining them what a SQL query is, what a firewall does and which scripts run at what times and what for. We are masters of our kingdom, and they are on the outside looking in. Newsflash! They don’t care about all that. They just want to process an invoice and move it from here to there. They never gave a you-know-what about your precious servers and technology in the first place!
Enter DevOps, which has come with the promise of changing the stale, static world of old IT by shattering old customs and swiftly kicking bureaucracy and old styles of working to the curb. And yes, that meant kicking ITIL® and many other supporting frameworks and standards to the wayside as well. This came with great intentions, but if ITIL® was not working previously, there is no way that DevOps would benefit an organization any better. As a matter of fact, it may actually make things worse. DevOps is not only about doing things faster. Yes. it is a cultural change, but changing culture alone won’t cut it. DevOps falls short in addressing how to understand and approach your customers, how to deal with risk, how to do quality design, transitions and so on. Amplifying feedback loops is well and good, but if what you have in terms of culture and design is bad, you are amplifying the bad! So DevOps is not a silver bullet, and neither is ITIL®. They are both approaches to transform the culture and ways an organization works. Allow them to work together in order to provide the engine for deep cultural change in your organization. In today’s fast and dynamic technological environment, ITIL® is far from a moribund horse. ITIL® can still bring a structured, organized way of designing and working with IT services and their lifecycle. It brings perspectives and ideas on how to develop them, what to consider when approaching customers to gather requirements and understand their business objectives, how to measure demand, and how to improve services. DevOps brings collaborative work, fast deployment rates, faster delivery and focus on important work. How exactly do ITIL and DevOps will work together?
The Service Strategy lifecycle phase provides information related to existing and proposed services through service portfolio management. Through demand management, you can understand your user profiles and patterns of business activity. It is in Service Strategy where you identify how your services enable business outcomes, and also where you define your service models. Before starting DevOps, you will want understand exactly who your customers are, what they want, and how you can provide value. You want to be sure that you understand your customer’s requirements, what success looks like from a business perspective, and define the vital business functions (VBFs). This will ensure that there is purpose behind the things you do with DevOps.
In Service Design, perform activities that solidify what was envisioned during strategy and makes sure that the service is ‘fit for use’. Processes like availability, capacity, information security and IT service continuity management ensure that your services will be there as agreed to with the customer. This is one of the most important and most valuable lifecycle phases in ITIL®. Having a well designed service will make transitions from Dev to Ops easier because you will be working against a solid design package that will be followed and adhered to by all resources in the organization without ambiguity or deviation. It is important, though, to be sure that you are designing to scope; if your customer did not ask for it, why should it be in the design package? It won’t be fair to operations if they are made to support something that customers do not want.
Service Transition is the great orchestrator. It has all of the processes that enable a clean handoff between design and operations. Of all the processes in this lifecycle, transition planning and support is one of the most overlooked, and that is a mistake. It defines the transition strategy, coordinates all of the resources and capabilities needed for the transition, and provides oversight over all transition activities. Do you want to ensure that your Ops are ready to handle whatever Dev does? Spend time understanding this phase and how to integrate all elements to provide a good transition.
The configuration management process and its associated configuration management database (CMDB) are under the purview of Service Transition. You may be thinking, “My organization tried to build/implement a CMDB. It failed spectacularly and we spent so much time and money in it that we don’t want to do it again”. It could have failed because you went too big and too broad. Think back to the scope you set in Service Design. If the customer did not ask for it, and you did not design for it, why are you tracking it? Track the configuration items (CIs) that are absolutely necessary for the service scope, abstract some of the supporting services and CIs as applicable. Use automation wisely wherever applicable, and use operational level agreements (OLAs) or risk registers to document and track those CIs that are excluded from the scope. Also ensure that the knowledge management process is strong. Knowledge management is not just for the service desk; it provides information back to every other lifecycle process in ITIL. Empower your resources to register all knowledge that they encounter, as it will benefit in the improvement of strategy, design, transition and operations.
Service Operations is where the rubber meets the road. This is where end users interact with what was designed, and if a good job was done, this is where they see the value in what they are paying. If you did not do your homework in design, this is where your users will notice that, and where they will complain about it. Loudly. Here is where to elevate the operations folks, especially the service desk agents, early into the design and transition phases (Dev) and give them an opportunity to contribute. You might think that service desk agents have nothing to contribute in the development of a service. Think again, because they are the ones directly in tune with what users are seeing and feeling. They can bring data, perspectives, ideas, insight and knowledge. Continual Service Improvement (CSI) provides the tools needed to measure and improve your processes, activities, and to feed all of that information back to other lifecycle phases through the CSI register and service improvement plans.
DevOps and ITIL® need to work on a two-way street, but in order for them to work better together, take a look at how your current processes and activities generate waste. This is especially true about ITIL® since it, if taken literally ‘by the book’, can generate quite a bit that will not bring any value to your organization, your customers or users. One of the main tenets of DevOps is bringing about rapid delivery and transition to operations, and is one of the reasons ITIL® has been shunned as of late because it is perceived as a lot of work. As stated earlier, ITIL® brings an assortment ideas related to service stability, design and transition rigor.
Turbo boost: Lean ITOne of the ways in which DevOps and ITIL® can work together is by looking at your processes and activities through the lens of Lean, as it enables you to examine how your activities support customer outcomes, how those activities flow through your organization, and how to identify wasteful activities and eliminate them. Lean IT is the extension of lean manufacturing and lean service principles to the development and management of information technology products and services. Lean IT’s primary concern is with the identification and elimination of waste from products of services, where waste is something that adds no value to a product or service. Waste, in all of its three types, can happen in any of ITIL®’s five lifecycle phases and can really drag down your DevOps activities and it is this, not ITIL® itself, that will hold DevOps back. In addition to the identification and management of waste, Lean IT also deals with other elements related to the execution of processes in an organization, and it works well within the ITIL® framework. For example:
So, you want to start using DevOps and ITIL® together as partners? Great. Do not rush blindly into it. Here are things that you should consider:
If you choose, you could do DevOps without ITIL®. But as explained, DevOps on its own will not be as successful as was hoped for. Use ITIL® wisely, especially through the application of Lean IT principles, and you can start down the path of great DevOps activities in your organization.