Probably not!
With the emergence of Agile and DevOps, some people are saying that ITIL is dead! Is this true? The short answer is ‘NO!’
However we need to understand the rationale for the claim of ITIL irrelevance and IT Service Management (ITSM) obsolescence. It’s certainly true that many organizations that have “implemented ITIL” or are “ITIL-compliant” or “ITIL-aligned” currently face many challenges. These issues include unnecessary bureaucracy, inflexible and complex processes, outdated tools and technology, siloed and adversarial IT departments, as well as other significant issues and dysfunctions.
It’s common for people to view ITIL and IT Service Management (ITSM) as being dogmatic and fixated on rigid processes. Another popular perception is that ITIL has a strong bias for operations over software development and thus isn’t relevant for the “app guys”.
An issue of misinterpretation
Many organizations misinterpret ITIL best practices and/or implement ITSM principles badly. Similarly, many organizations make a mess of Agile, especially if their interpretation of Agile is synonymous with “shoot from the hip.” In the years to come, it’s highly likely we’ll see many organization attempt and then fail at DevOps. However, just because some may implement Agile and DevOps poorly, it should not be an indictment of these incredibly powerful concepts. There is more “user error” than deficiency in any of these frameworks—ITIL included.
ITIL was not supposed to be a one size fits all solution to be implemented the same way by every organization. One of the ITIL mottos is “adopt and adapt.” The purpose of this admonition is to encourage a flexible implementation of the ITIL framework.
ITIL is not supposed to be bureaucratic or to impede agility and innovation. The opposite is true. ITIL encourages the adoption of new technologies and innovation in order to meet the needs of the business and create value for customers. ITIL concepts should be implemented in such a way as to optimize results from a People, Process and Technology point of view.
Assumed conflict does not exist
Contrary to popular belief, ITIL does not conflict with Agile or DevOps thinking. ITIL is also not limited to infrastructure or operations. The most current versions of ITIL are focused on end-to-end services. These normally include the management of applications, development, infrastructure, operations, and alignment with business strategy and customer value.
Furthermore, ITIL has a development lifecycle based on principles that are almost identical to the software development lifecycle used by both Agile and DevOps. A big part of the ITIL lifecycle is “Service Design” and ITIL is fairly agnostic on the topic of how to conduct application development. ITIL does not have an inherent bias for the Waterfall approach to project management and accommodates Agile as well as any other possible approach to designing services or running projects. ITIL is mostly non-prescriptive when it comes to tools, organizational structure, and designing policies and procedures.
No incompatibility
Many of the best practices and concepts described in ITIL are similar, if not identical, to those advocated in Agile and DevOps – or at the very least are not incompatible with ITIL. For example, ITIL does not say that you need to do “big bang” quarterly releases or have a slow and complicated Change Management process. ITIL allows for frequent releases and a nimble change process.
The recently published book, Site Reliability Engineering: How Google Runs Productions Systems, describes Google’s DevOps implementation in detail. DevOps at Google is a blend of Agile methodologies, ITIL best practices, systematic problem solving and decision making, and a mature culture of blame-free continuous improvement. Of course, all of this runs on Google’s highly advanced proprietary technology for applications, virtualized infrastructure, monitoring and alerting tools, etc. Google utilizes best practices from an integrated and holistic People, Process and Technology perspective, similar to what’s been advocated by ITIL since the 1980s.
Google and many other organizations use two important DevOps concepts—continuous integration and continuous delivery—to encourage frequent releases, in some cases hundreds per day. These concepts are not antithetical to ITIL, which would suggest that this is done in a controlled fashion with a set of processes, tools, and skills that are aligned to the needs of the business. DevOps, Agile, and Google all concur.
DevOps and Agile are not the ‘wild west’ of IT
Systematic analysis, solid planning, and careful management are all required in order to setup an effective and efficient Release Management system. This is important if the desired end-result is a traditional approach to conducting releases on a quarterly schedule, and is even more important using a DevOps model with a continuous delivery objective. DevOps and Agile do not equate to sloppy or “wild-wild west.” Discipline and structure are essential to ITIL, Agile, and DevOps. Google is no exception in this regard.
Integrating ITIL best practices with DevOps and Agile
So how does continuous integration and continuous delivery fit in with ITIL and other ITSM best practices?
Continuous integration and delivery can be achieved partially by pushing as many changes into the Standard Change (i.e. pre-approved) category as possible. For example, your ITIL-aligned change policy could be something like, “If the proposed change request passes all required tests, then it’s pre-approved to implement the change request without the need for any additional permissions or management oversight” (thus bypassing your typical weekly Change Advisory Board, etc.). Another complementary approach would be to automate as many approval points in the Change Management process as possible.
Automation is key
Automated testing and monitoring have been around for a long time and are fully supported by ITIL best practices. DevOps just takes this one step further. With DevOps, the goal is to implement automated testing and monitoring capabilities as early into the development lifecycle as possible. Built-in code-based automated testing encourages the programmer to develop applications that are able to detect almost anything that could potentially go wrong with the system. If the programmer is really slick, then they’ll even try to build in a solution to fix all detected problems automatically, without the need for any human intervention (and no need to raise a new incident ticket – although the system could create an informational alert in the Event Management system).
DevOps isn’t typically a good fit for legacy systems
With that said, let’s not forget that, in many organizations, it’s not always realistic or preferable to use Agile or DevOps in every situation. What about legacy systems? What about systems that are neither virtualized nor cloud-based? What if your organization is not ready to use Agile or DevOps because there’s a lack of the necessary skills, tools, cultural maturity, organizational structure, etc.? Traditional ITIL and/or other related Service Management frameworks are still some of the best ways to handle the management of legacy IT systems and services.
In conclusion: In many organizations it would make sense to use a combination of approaches: ITIL for some things, Agile for some development, Waterfall for other projects, and DevOps in certain circumstances where the conditions will allow for it (perhaps by running a pilot or only using DevOps for new products and digital services).
So is ITIL dead? No! It’s still relevant and in some cases needed now, more than ever.
