Some people believe that ITIL has died with the advent of Agile and DevOps. This is true? Is this true?
We need to understand why ITIL manchester is considered irrelevant and IT Service Management (ITSM), obsolete. Many organizations that have “implemented ITIL” are either “ITIL compliant” or “ITIL aligned”. This is true. These problems include excessive bureaucracy and inflexible and complicated processes, obsolete tools and technology and siloed or adversarial IT departments.
ITIL and IT Service Management (ITSM), are often viewed as rigid and dogmatic by many people. Another common perception is that ITIL is biased towards software development over operations and therefore is not relevant for “app guys”.
A problem of misinterpretation
Many organizations make poor ITIL implementations and misinterpret ITIL best practice. Many organizations also make a mess out of Agile, especially if they interpret it as “shoot at the hip” or “shoot from a hip.” It’s likely that many organizations will attempt to implement DevOps and fail. Although some organizations may not implement Agile or DevOps well, this should not be a reason to dismiss these powerful concepts. It is possible to make more mistakes than there are deficiencies in these frameworks, including ITIL.
ITIL was not meant to be a universal solution that could be used by all organizations in the same way. ITIL’s motto is “adopt, adapt.” This is meant to encourage flexibility in the implementation of the ITIL framework.
ITIL is not meant to be bureaucratic. It should not hinder agility and innovation. It is the opposite. ITIL encourages innovation and the adoption of new technologies to meet business needs and provide value for customers. ITIL concepts must be implemented so that they maximize results from a People, Process, and Technology perspective.
Assumed Conflict does not exist
Contrary to popular belief ITIL is not in conflict with Agile and DevOps thinking. ITIL does not only cover infrastructure and operations. Modern ITIL is focused on providing end-to-end services. These services include management of applications, development and infrastructure, as well alignment with customer value and business strategy.
ITIL’s development lifecycle is based almost exactly on the Agile and DevOps software development lifecycles. ITIL’s lifecycle includes “Service Design”, which is a large part of it. ITIL is not specific about how to do application development. ITIL doesn’t have an inherent bias towards Waterfall project management. It can accommodate Agile and any other approach to designing services and running projects. ITIL is largely non-prescriptive in terms of tools, organizational structure, designing policies, and procedures.
No incompatibility
Many of the ITIL best practices and concepts are very similar to those in Agile and DevOps. ITIL doesn’t require you to release quarterly “big bangs” or have a complicated Change Management process. ITIL allows frequent releases and a quick change process.
Site reliability Engineering: How Google Runs Productions Systems is a recently published book that describes in detail Google’s DevOps implementation. Google’s DevOps is a mix of Agile methodologies, ITIL best practice, systematic problem solving, decision making, and an mature culture of continuous improvement that doesn’t take any blame. All of this is powered by Google’s proprietary technology, which includes applications, virtualized infrastructure, monitoring, alerting, and other tools. Google uses best practices that are integrated and holistic from a People, Process and Technology perspective, which is similar to the ITIL approach since the 1980s.
Google and other companies use DevOps concepts of continuous integration and continuous delivery to encourage frequent releases. In some cases, hundreds per day. These concepts are not incompatible with ITIL. They suggest that ITIL is controlled and executed using a set process, tools, skills, and tools that are tailored to the business’s needs. DevOps and Agile are all in agreement.
Agile and DevOps are not the “wild west” of IT.
To create an efficient and effective Release Management system, you need to do thorough analysis, plan well, and manage carefully. This is especially important if you are looking for a traditional way to release software on a quarterly basis. It is even more important when using DevOps models with continuous delivery objectives. Agile and DevOps are not synonymous with being lazy or wild-wild west. ITIL, Agile and DevOps require structure and discipline. Google is not an exception to this rule.
Integration of ITIL best practices into DevOps/Agile
How does continuous integration and delivery fit into ITIL and other ITSM best practice?
Continuous integration and delivery can partly be achieved by pushing as many changes to the Standard Change (i.e. As many changes as possible can be pushed into the Standard Change (i.e. pre-approved) category. Your ITIL-aligned Change Policy could say, “If the proposed Change Request passes all necessary tests, then it is pre-approved to execute the Change Request without the need of additional permissions or management oversight.” (This would bypass your usual weekly Change Advisory Board etc.). A complementary approach is to automate as many approval points as possible in the Change Management process.
Automation is the key
Monitoring and automated testing have been around since the beginning and are fully supported and encouraged by ITIL best practices. DevOps takes this one step further. DevOps aims to integrate automated testing and monitoring capabilities early in the development cycle. The programmer can use code-based automated testing to help detect any potential problems with the application. If the programmer is truly skilled, they might even attempt to create a solution that fixes all problems automatically without human intervention.
DevOps is not a good fit for legacy system systems.
Let’s not forget, however, that Agile and DevOps are not always feasible or desirable in all situations. What about legacy systems? What about legacy systems? What happens if your company isn’t ready to use Agile and DevOps? Traditional ITIL and/or related Service Management frameworks remain the best methods to manage legacy IT systems and services.
It would be a good idea to combine different approaches in many organizations: ITIL for certain things, Agile for some projects, Waterfall for others, and DevOps when the circumstances will permit it (perhaps running a pilot, or using DevOps only for new products or digital services).
evitile 