ITIL has been pronounced dead approximately every three years for as long as I have been in IT service management. Agile was going to kill ITIL. DevOps was going to kill ITIL. Cloud was going to kill ITIL. Continuous delivery was going to kill ITIL. SRE was going to kill ITIL. Each obituary was confidently written, widely shared, and then gradually faded as ITIL continued to exist.
The framework keeps not actually dying. The pattern is worth examining because it tells us something about both ITIL and about the discourse that keeps trying to kill it.
The standard ITIL-is-dead argument
The standard argument for ITIL's obsolescence usually has the same structure regardless of which approach is being positioned to replace it. ITIL is too process-heavy. ITIL is too slow. ITIL doesn't fit modern operational realities. ITIL was designed for a different era. The new approach (whichever one is current) is more aligned with how things actually work now.
The argument has surface plausibility because ITIL does have specific characteristics that the alternatives don't have. ITIL is process-oriented. ITIL emphasizes documentation. ITIL has formal change management. These characteristics produce overhead that more lightweight approaches don't produce.
The argument also has specific weaknesses that account for why ITIL keeps not dying. The alternative approaches usually address part of what ITIL addresses while leaving other parts unaddressed. Organisations that have committed fully to the alternatives often discover after a period that they have created gaps in their service management capability that need to be filled with something — usually some adapted form of the practices that ITIL had been providing.
What each replacement actually addressed
The historical pattern of ITIL replacements shows that each one addressed specific real limitations in how ITIL was being applied while creating new gaps that hadn't been salient before.
Agile (in the operations context, not just development) addressed the speed problem with traditional ITIL implementation. Change management cycles that took weeks weren't appropriate for environments where deployment cadence had moved to multiple times per day. The lightweight approaches that emerged from agile thinking addressed this real problem.
DevOps addressed the silos between development and operations that ITIL implementations sometimes reinforced. Treating dev and ops as separate organisations with formal handoffs produced specific friction that DevOps culture and tooling addressed.
Cloud addressed the infrastructure-centric assumptions in some ITIL practices that didn't apply when infrastructure became more programmable and ephemeral. The practices that assumed slow infrastructure provisioning didn't fit when infrastructure could be provisioned in minutes through API calls.
SRE addressed the absence of explicit reliability engineering as a discipline within traditional ITIL. The mathematical approach to reliability through error budgets and SLI/SLO frameworks added rigor that ITIL hadn't provided.
Each of these addressed real limitations. None of them addressed everything ITIL addressed. The gaps emerged after sustained adoption, often after the original advocates had moved on to championing the next thing.
Why ITIL adapts rather than dies
The reason ITIL keeps not dying is that the framework has continued to evolve in response to the criticisms and the alternative approaches.
ITIL v3 was the version most people had in mind when they started declaring ITIL dead in the 2010s. ITIL 4 explicitly addressed many of the criticisms. The Service Value Chain model, the practices framework, the explicit acknowledgment of agile and DevOps influences, the move away from the "process-first" framing — all of these represent ITIL absorbing and integrating the criticisms rather than being killed by them.
The result is that ITIL 4 looks quite different from ITIL v3 while remaining recognisably ITIL. The framework has shown enough adaptive capability to remain relevant despite repeated predictions of obsolescence.
This pattern is not unique to ITIL. Most established frameworks that have been around long enough to face multiple waves of criticism have either adapted or actually died. The frameworks that didn't adapt — and there are several from the same era as ITIL — really did die. ITIL is in the category of established frameworks that adapted enough to continue.
The discourse pattern
The pattern of declaring ITIL dead also tells us something about how IT discourse works.
The pronouncements of ITIL's death typically come from advocates of new approaches who have a professional interest in those approaches succeeding. Consultants, trainers, vendors, and thought leaders advocating for new approaches benefit professionally from the new approaches displacing the established ones.
This isn't bad faith — the advocates often genuinely believe what they are saying. It is professional incentive structure that produces a steady stream of "X is dead" pronouncements that mostly turn out to be premature. The discourse produces these pronouncements because the discourse is shaped by professionals whose careers benefit from them.
The audience for these pronouncements is also receptive to them in specific ways. IT professionals who feel that their established approaches aren't producing the results they want are emotionally available to "the established approach is dead, here's what's actually working" framings. The receptivity rewards the producers who keep producing the framings.
The result is a steady production of obsolescence claims that mostly don't pan out. The claims serve professional and emotional functions even when they turn out not to be empirically accurate.
What organisations should actually do
For organisations trying to make sense of the periodic obsolescence claims, the productive response is to evaluate specific claims against their specific situations rather than treating the discourse as authoritative.
The questions worth asking include: Does the new approach address a specific limitation we are actually experiencing in our current practice? Have organisations similar to ours adopted the new approach successfully and what have their experiences been? What are the gaps the new approach creates that we will need to address through other means? What are the transition costs and risks of adoption?
These questions produce more useful evaluation than the binary framings the obsolescence discourse encourages. Most organisations end up with hybrid approaches that combine elements of established frameworks with elements of newer approaches, addressing their specific contexts rather than committing fully to any single framework.
The hybrid pattern is what actually works. The "we're going to do pure DevOps now" or "we're going pure SRE" or "we're abandoning ITIL completely" framings rarely produce the outcomes their advocates expect. The hybrid approaches that take what's useful from multiple frameworks tend to produce better outcomes.
The current cycle
The current obsolescence pronouncements are mostly framed around AI and what it means for service management. AI is going to automate so much of what ITIL practices currently address that the framework will be obsolete within a few years. This is the new version of the standard pattern.
The pattern will probably play out the way previous patterns have played out. AI will absorb specific work that was previously done through ITIL practices. AI will not absorb other parts of what ITIL practices do. Organisations that try to fully replace ITIL with AI-driven approaches will discover gaps. ITIL will adapt to incorporate the AI capabilities. The framework will continue to exist in modified form.
The obsolescence advocates will move on to the next thing once the AI cycle has played out. The framework will continue to be pronounced dead approximately every three years until the publication discourse shifts to other topics or until the framework actually does die because it stopped adapting.
What I think about all this
I have stopped paying much attention to the periodic obsolescence pronouncements after watching several cycles play out. The framework is more durable than the pronouncements suggest. The pronouncements are more about the producers' professional positioning than about the framework's actual viability.
What I do pay attention to is the specific criticisms that drive each new wave of obsolescence claims. The criticisms usually identify real limitations in current practice. The framework's adaptation in response to those criticisms is where the actual evolution happens. The criticisms have been useful even when the obsolescence claims they were attached to were premature.
For practitioners, I would recommend a similar posture. Take the specific criticisms seriously. Engage with the alternative approaches that emerge in response. Adopt what works for your specific context. Ignore the binary framings that demand you choose between approaches. The hybrid approaches that combine the useful parts of multiple frameworks are what most successful organisations end up with.
ITIL will probably be pronounced dead again within the next three years. It will probably continue not actually dying. The pattern is reliable enough that you can use it as a benchmark for evaluating other obsolescence claims you encounter in IT discourse. Most of them will follow similar arcs. Most of them will be premature.
The sustained relevance of established frameworks in IT, despite the constant pronouncement of their obsolescence, is one of the more reliable patterns in the industry. ITIL is among the most durable examples. Bet accordingly.
