ITIL vs. DevOps: What path should an enterprise choose?

What is ITIL?

The ITIL IT service management framework emerged the 1980s as data centers decentralized and adopted more diverse architectures, which caused discrepancies in processes and deployments and inconsistent or suboptimal IT services. It is a set of guidelines and best practices designed to standardize how businesses select, plan, deliver and maintain IT services, and to improve IT service delivery efficiency and predictability. ITIL also helps align IT department actions and expenses to business needs, and change them as the business grows or shifts direction.

ITIL v4, released in 2019, encourages organizations to evaluate and implement the aspects that are most important for their needs, and integrate IT services management with other areas of the business. ITIL 4 principles also address priorities aligned with frameworks such as DevOps and Agile: focus on value, iterative progress, collaboration, visibility and transparency, simplicity and automation.

What is DevOps?

DevOps broadly refers to a collection of practices and tools which combine software development and operations to shorten lifecycles and support continuous development delivery. The DevOps process is basically an infinite loop of steps: plan, code, build, test, release, deploy, operate, monitor and, through feedback, plan again.

From one perspective, DevOps is a philosophy that fosters cooperation and collaboration between the two historically divided and siloed IT groups: application developers and IT operations teams. From another view, DevOps is a chain of processes that blends methodologies of continuous integration and continuous delivery or continuous deployment to efficiently create and deploy applications. A narrower interpretation of DevOps is the adoption of tools, automation and programmable infrastructure to deploy production-ready code on a rapid release schedule.

How ITIL fell behind DevOps

Historically, some have criticized ITIL as a rigid checklist of prescriptive practices that is too unwieldy, extensive and time-consuming, and easily disrupted by shorter-term needs and initiatives. The long wait from ITIL v3 to ITIL 4 further fueled questions about ITIL's agility and responsiveness as a standard for emerging technologies and operational challenges -- as well as the organization behind it.

ITIL fell into a bureaucratic crevasse during the eight-year lapse between the revised version of ITIL 3 (also known as ITIL 2011) and ITIL 4. One explanation for the delay was ITIL's change in ownership. Its initial owner, the United Kingdom's Central Computer and Telecommunications Agency (CCTA), a governmental agency that provided IT and telecom support, merged with the Office of Government Commerce. In 2013, Axelos -- a joint venture between Capita, a professional services company, and the U.K. Cabinet office -- took ownership of ITIL.

With no DevOps or cloud message from ITIL during those years, organizations sought other frameworks. Their option was to embrace DevOps or develop other processes internally, especially as enterprises faced pressure to meet customer expectations around the quick delivery of new applications and features. Certainly, ITIL's limbo triggered some cultural clashes along the way, as ITIL stalwarts tried to hang on to the methodology while IT operations and technology stacks changed rapidly around them.

During that long wait between ITIL 3 and 4, organizations also developed cloud migration strategies. Cloud management models would begin as ad hoc, but mature gradually into more formal service management approaches. Early cloud adopters could iterate and build on their lessons learned without the arbitrary restrictions of an industry methodology. While some cloud management practices have their roots in ITIL, they were largely shaped by early adopters, cloud service providers, system integrators and startup cloud management platform (CMP) vendors.

ITIL 4, even with some cloud and DevOps support, entered a market in which organizations were already doing both. For example, ITIL 4 practices still push top-down command and control, whereas DevOps fosters an empowered team. Furthermore, organizations began to pilot continuous integration/continuous development (CI/CD) strategies, while others were well into their cloud and DevOps initiatives based on containers, microservices and serverless computing.

Moreover, ITIL 4's 34 practices and four core functions still encourage operational and data silos, which keep development and operations teams apart. This is a major difference between ITIL and DevOps, as the latter aims to breaks down silos to improve collaboration, troubleshooting and reporting during the entire product delivery lifecycle.

All those factors add up to this: Many organizations are less likely to rewrite governance and management processes for ITIL 4, particularly when they already spent money and time crafting their own processes.

ITIL vs. DevOps: Can they coexist?

To many, a lack of synergy between certain ITIL and DevOps practices makes them fundamentally incompatible. Others still assert that the two frameworks can, and should, coexist -- ITIL lays out processes to govern service delivery, and DevOps infuses them with agility, automation and team collaboration.

Most enterprises have a mix of legacy and modern infrastructures. ITIL reinforces stability and reliability that especially suit legacy systems, while DevOps' velocity shines with cloud, containerized and distributed architectures. ITIL and DevOps are starting to share common ground -- ITIL 4 finally began to address modern IT practices, including automation, containers and microservices.

Unfortunately, the choice of ITIL or DevOps can devolve into a this-vs.-that conflict because of corporate politics and cultural differences. For example, back-office executives often prefer ITIL for its regimentation and reporting, but development and operations teams need the continuous integration/continuous development that DevOps provides to keep up with customer demands. ITIL's rigid oversight and overhead can impede projects and employee morale as badly as micromanagement, whereas DevOps quickly resolves those issues through iterations and (ideally) blame-free post-mortems.

For DevOps and ITIL to coexist, an enterprise needs champions who can bridge these organizational rifts, so organizations can cherry-pick the best practices that each methodology offers.

Cloud management as a middle ground

Many cloud-first organizations have turned to CMPs as the only major service management platform they need -- and some enterprises have adopted CMP as a class of service management as well. A CMP removes complexity from cloud operations tasks and supports a range of customizable reporting options. Implementing a CMP also enables teams to use operational data for actionable security and operational intelligence.

Some enterprises forsake ITIL for a CMP and a process created in-house. For example, organizations write their own cloud management processes and frameworks that might include ITSM. CMPs manage IT assets and resources across multi-cloud environments. CMP cost management features also help organizations optimize cloud spending and eliminate resource waste. In addition, these tools ensure compliance with unified configuration and activity monitoring, and automate key cloud management and operations tasks to improve the productivity and efficiency of cloud initiatives.

It's possible for a determined enterprise to work with both ITIL and DevOps despite their inherent differences, but such a feat requires bridging cultures. ITIL proponents must see that embracing DevOps agility doesn't mean giving up control. Likewise, DevOps proponents must learn that service management principles don't equate to "business prevention."

For many enterprises, however, the compromise is to adopt service management principles through creating their own internal best practices, or augmenting their cloud management platform with the new generation of DevOps practices.