More than 40 years have passed since the creation of ITIL (Information Technology Infrastructure Library). In this article, we explore why the practice is still relevant now and how it blends with frameworks such as DevOps.
Days are numbered for the classical trope of the service provider solely delivering value for the customer, or service consumer – and for a good reason, too. With the adoption of a data-driven mindset and best practices, players in the service market at both ends, those who deliver and those who receive, have come to the realization that it’s a two-way road.
Value is the result of co-creation, by the customer who receives the services as much as by the actual service provider. In practice, this brings into play key aspects of surfacing tangible value out of a service investment that typically lies in the service consumer’s court such as creating specifications and implementing training.
Defining value in service delivery
Creating and delivering value has always been top of mind in any endeavour, be it IT related or not. Being such a much-used notion, it’s understandable that everyone can have a different, personal perspective on it. That’s why it’s important to get things straight right from the start and ensure that everyone involved in a project is on the same page.
So how do we define value in a generally acceptable and practical way? The ITIL 4 service value system (SVS) comes to define value as the perceived benefits, usefulness and importance of an endeavour. The goal of the SVS is to encompass how all the elements and activities that an organization performs work together as a system to enable the creation of value. Turning Demand and/or Opportunity into value is a journey that spans five elements, in the ITIL (Information Technology Infrastructure Library) system.
How value is delivered in a controlled but agile manner
In support of the idea of value as described above, ITIL 4 formulates seven guiding principles. These may seem like common sense but are not randomly put together, and, more importantly, can be complemented – or even underlined – by the DevOps principles of open communication, collaboration and shared goals. Indeed, these form a solid base that is universally applicable to any initiative, at any scale and in any operational framework, beyond ITIL itself.
Focus on value: every action should be targeted at creating value for stakeholders, which is a clear overlap between ITIL 4 and DevOps regarding customer value. Beyond customers and users, stakeholders include society at large, regulatory bodies, employees and shareholders. A practical example of this view is that a product that creates value for customers but causes frustration for employees is limited and will not be a success story.
Start where you are: evaluate your position and leverage any advance you’ve got instead of starting from scratch. This also shows the team that their previous contributions are valued and taken into consideration so they are more likely to support change.
Progress iteratively with feedback: instead of doing everything at once, plan to break down large projects into smaller, manageable actions that deliver incremental value often. This aligns with DevOps: continual analysis of feedback provided for IT services at every stage of its lifecycle.
Collaborate and promote visibility: obviously working in silos is not the best idea when it comes to adapting to change. Incorporate operational supportability early on by removing the organizational barriers between Dev and Ops to enhance communication, collaboration, and accountability.
Consequently, there can be a greater focus during development on how support services, resources, and capabilities will need to change. Collaboration and transparency go hand in hand, and these are not limited to the service project teams, but also include customers, users and everyone else involved in the service. Beyond improving collaboration, this is about showing people what they can achieve and contribute. It is about the value that they can co-create.
This involves overcoming established processes to see the business outcomes and the associated value streams, with new or changed services considered in the context of the entire service and support ecosystem, rather than in isolation. Even more than ITIL, DevOps is great at bringing together separate teams and bridging gaps across business objectives.
Think and work holistically: how does the current project fit into the bigger picture of the organization and into the effort of the overall creation of value? No service or product stands alone, rather it is all part of a complex system whose goal is, of course, to create value. This ITIL guiding principle aligns with DevOps by providing an end-to-end approach to the service lifecycle, plus the integration of product and service management practices.
Keep it simple and practical: oftentimes, complex processes haven’t reached that level of complexity for value creation reasons, but rather because they’ve been in place for a long time and have gone through many iterations. This is an opportunity to improve. If there isn’t a solid reason to account for complexity, then it’s time to rethink and simplify. People need to make it a habit to practice constructive criticism, and should they identify an unnecessary complexity, they are expected to search for a simpler, more practical solution and implement that.
Optimize and automate: this is about being both effective and efficient at the same time i.e. when you can, you automate, where you can’t, you train people for the task. Moreover, don’t try to automate a process that hasn’t yet been optimized; after all, automation is not a patch, but an enabler.
The challenge still lies in creating change and release capabilities at the speed of the business. ITIL’s change and release processes have long caused Dev teams issues. This is mostly due to perceived bureaucracy and delays. On the other hand, the IT Ops function might perceive DevOps practices as neglecting change control in favour of increased velocity. However, with DevOps, technology is used for constant error checking to release automation, to increase both assurance and velocity by implementing continuous integration, continuous delivery, and continuous deployment.
The guiding principles in ITIL are most certainly not a thing of the past. Rather, they constitute excellent guidance for any service delivery engagement and even beyond.
ITIL system, Lean, Agile, DevOps and the many flavours of getting things done right and fast
ITIL (Information Technology Infrastructure Library), Lean, Agile, DevOps and more – these are practices and frameworks that aren’t specific to the Insurance or Banking industries, but rather they cross the boundaries of specificity and can be applied to any organization and/or project that aims to deliver value in a right and fast manner.
In our work, we align with the DevOps Handbook while also ensuring practices are made compatible with the ITIL process. To support the shorter lead times and higher deployment frequencies associated with DevOps, many areas of the ITIL processes become fully automated, solving many problems associated with the Configuration and Release Management processes of ITIL – for example, by keeping the configuration management database (CMDB) and definitive software libraries (DSL) up to date. Moreover, because DevOps requires fast detection and recovery when service incidents occur, the ITIL disciplines of Service Design, Incident, and Problem Management remain as relevant as ever
At Encora we have developed our own solution development and delivery lifecycle that enables us to be both structured and at the same time flexible when it comes to delivering value for our varied customers, be they insurance carriers, banking organizations or manufacturing companies. In addition, we adhere to the four dimensions of service management as described by ITIL 4 system, and especially in the understanding that IT service management goes beyond managing new technologies.
Blending the classical foundation of ITIL with modern frameworks targeted at agility and speed like DevOps and Agile is a good idea, provided that there is an openness to adapt and to blend the two without the risk of becoming inflexible or slowing down. Ultimately, the detailed guidelines of ITIL (Information Technology Infrastructure Library) can help fill in the gaps that can sometimes be left by DevOps’ much more general guiding principles.
