Historically, ITIL and DevOps have made poor bedfellows. DevOps is about speed and enablement, while ITIL, at least traditionally, is a far more proscriptive framework that places considerable delays into a DevOps workflow.
This isn't to say that DevOps is perfect; many organizations have found -- to their cost -- that an open DevOps approach has led to major issues, such as relatively uncontrolled code making its way from development to production.
However, DevOps has matured -- as has the ITIL IT service management framework. And while the two technologies are not yet a perfect match, it's time to stop thinking in terms of DevOps vs. ITIL, and instead consider DevOps and ITIL.
Where DevOps and ITIL intersect
DevOps shops must have the right checks and balances in place. They must codify processes that enable audits; feed errors back to developers for a fix; and create a feedback loop from end users to development and operations teams.
The latest version of the ITIL framework -- ITIL 4 -- is value-focused, which provides a solid foundation for these processes. And as DevOps continues to evolve, ITIL practices could help IT teams create idempotent environments.
Idempotency is the means by which an entity -- such as an end user, developer, IT operations professional, or even an AI or machine learning engine -- defines the desired outcome of any given change. Underlying tools then use scripts to create and provision packages into an operational environment that will achieve that desired outcome. This approach requires continuous monitoring and feedback loops to ensure that the outcome is not only achieved, but is maintained as the platform changes as well.
ITIL 4 embraces these concepts. The framework's service value chain promotes an interconnected set of activities that deal with service creation, delivery and continuous improvement. It's complementary to the continuous development and continuous delivery practices in DevOps. Yet, there is a key difference between DevOps vs. ITIL here: The former emphasizes the under-the-hood, technical ways to perform these tasks, through the use of development tools and hard processes, while the latter focuses more on ensuring tasks occur in a controlled and auditable manner.
ITIL's service value system overlies its service value chain. This broad system embodies how an organization works from opportunity or end-user demand to value delivery.
DevOps vs. ITIL for the business
At the time of publication, ITIL's service value system far outstrips the current state of DevOps -- specifically, the state of BizDevOps. In this DevOps model, business drivers shape how developers work, with the goal of meeting the needs of users who directly affect the organization's bottom line. There has been some progress around BizDevOps, but not enough to make it a reality across enterprise IT shops. ITIL's service value system could provide a layer on top of existing DevOps environments to enable this much-needed capability.
The majority of open source DevOps tools address the down-and-dirty technology needs of developers and operations staff, although some commercial systems also try to target the business. But these systems, to date, have been met with limited success, in part because IT departments, not the business, largely procure DevOps tools. In addition, IT teams still suffer from the perception of being somewhat removed from the rest of the organization, and so are loath to roll out and support the business front end of such tools.
ITIL, on the other hand, is nominally a business process tool -- particularly under ITIL 4. It is incumbent on Axelos, the organization behind the ITIL framework, to make an effort to push ITIL to the business, as a means to provide the necessary controls over the end-to-end value chain across an organization.
What's new with ITIL?
After nearly a decade of radio silence, Axelos finally unveiled ITIL version 4 in mid-2019. The ITSM framework update builds off existing guidelines and best practices, as well as adjusted for the paradigm shift of cloud operations, distributed applications and DevOps. But it also offers clarification and corrections on details in prior versions. Additionally, ITIL was made less prescriptive and more flexible -- which makes it possible for more organizations to adopt and adhere to these best practices.
It will be interesting to see if tool vendors and open source developers start to focus less on comparisons of DevOps vs. ITIL, and instead view the latter as a non-competitive framework that creates a standardized platform on which they can work. If DevOps teams and vendors can fold ITIL concepts and practices into their environments, everyone could win.