The discussion on ITIL vs. DevOps is a common one. There are many different views on the subject: some argue that ITIL and DevOps have different mindsets; some that they they are compatible; some that they are different but both have their place in the IT department. In a recent article, Charles Betz, leader of the Agile Workstream at the Open Group IT4IT Forum, which aims to provide a "vendor-neutral Reference Architecture for managing the business of IT", argues that their basic principles are at odds. ITIL is still trapped in a phased workflow. DevOps embraces lean product management tenets such as managing work in progress, managing queues, or handling small batches.
Betz and Jeff Sussna, both ITIL skeptics, agree that ITIL has done a great service to the IT community by "promoting service-centric, outside-in, customer-focused thinking". But they contend that, despite ITIL V3's discussion on "Continual Service Improvement", which aims to continuously align IT processes with business needs, it still has a phased-step mindset. As Betz puts it:
For every mention of “iterative” or “feedback,” there are ten mentions of “plan” or “planning. Notably, the word “experiment” appears only a few times in Service Strategy and not at all across the remaining volumes.”
According to Sussna, ITIL V3:
V3 locates Continual Service Improvement at the end of a set of phases consisting of Service Strategy, Design, Transition, and Operation. I was frankly a bit shocked to see such a waterfall-looking approach.
Betz sees ITIL as describing the IT pipeline as "large batches of accurately planned work transitioned between strategy, development, and operations". Betz also reckons that ITIL fundamentally believes in processes as the main problem solving mechanism and that risk is mitigated through planning and documentation. Betz traces some of these foundational beliefs to the fact that most of ITIL dates back 10 years and thus, is outdated:
ITIL requires an improved foundational model of IT delivery as a socio-technical system that is centrally concerned with execution, feedback, and flow.
Gene Kim, on the other hand, says that ITIL/ITSM are very much compatible with DevOps:
ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.
and:
More importantly though, ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business.
Kim presents several examples where ITIL/ITSM practitioners add value. On an infrastructure automation project, ITSM practitioners can integrate existing "release management readiness checklists, security hardening checklists and so forth" into the automated build process. Standard Changes, is an ITIL term for frequent, documented, low-risk, pre-approved changes. ITSM practitioners can help to embed Standard Changes into automated deployments into production.
Rob England diverges both from Betz, Sussna and Kim. England argues that ITIL and DevOps are at odds, but both may have their place in the same IT organization. He draws inspiration from Gartner's bi-modal and pace layer models to advocate for a multi-speed IT:
- Conservative: traditional, probably waterfall, change management and operations
- Nimble: some variant of DevOps
According to England, the business should decide which approach to take. Some business needs, and their supporting applications, need an emphasis on innovation and speed of change: they need a Nimble approach. Other business needs require stability and very low risk: they need a Conservative approach.