ITIL has a reputation problem: it's remembered as ticket queues, approval chains and the change advisory board that meets on Thursdays whether your outage can wait or not. DevOps was, in part, a rebellion against exactly that. But having worked both sides — ITIL Foundation certified, and years spent helping teams ship faster — I've concluded the war is mostly a misunderstanding about altitude. DevOps optimises the flow of change; ITIL maintains the memory of the service. Healthy organisations need both.

1. The fake war

ITIL 4 itself conceded most of the rebellion's points: it talks value streams, flow, and explicitly embraces agile and DevOps ways of working. Meanwhile, every mature DevOps organisation quietly reinvented ITIL's furniture under new names — service catalogs (Backstage), incident command (SRE), problem management (blameless postmortems), SLAs (SLOs and error budgets). The concepts survived because the problems are real; only the bureaucracy deserved to die.

2. Five ITIL ideas worth keeping, whatever you call them

  1. The service, not the server. Users consume services; infrastructure is implementation detail. An inventory of services with named owners is the single highest-value artifact in operations — it's the routing table for every incident, audit and cost conversation.
  2. Incident ≠ problem. Restoring service and removing root cause are different activities with different clocks. Teams that conflate them either firefight forever or philosophise during outages.
  3. Change as a risk decision, not a ritual. The question "what could this break, and how would we know and roll back?" is permanent. Only the answering mechanism should change with your deployment maturity.
  4. Knowledge as an asset. Runbooks, known-error databases, post-incident writeups — institutional memory that survives the engineer who wrote it. DevOps culture calls this documentation-as-code; ITIL called it knowledge management; both beat tribal memory.
  5. Continual improvement as scheduled work, not leftover time. Error budgets made this idea fashionable; ITIL said it first, less catchily.

3. Change management without the Thursday CAB

The modern translation of ITIL change management is risk-tiered, automation-first: standard changes (the vast majority) pre-approved and shipped through the pipeline with tests and rollback as the real control; normal changes peer-reviewed close to the work; a genuine emergency path that's fast and leaves an audit trail. The CAB survives only for the rare change that crosses many services and stakeholders — as a coordination meeting, not a permission ceremony. Framed this way, your auditors get their control evidence (my CISA lens approves) and your engineers keep their deploy frequency. Everyone's shocked how compatible the two worlds are once the queue is gone.

4. What an ITIL-shaped DevOps organisation looks like

  • A service catalog with owners, tiers and dependencies — machine-readable, wired into alert routing.
  • SLOs per service standing in for SLAs, with error budgets governing the pace of change.
  • Incident command with severity definitions, comms cadence and a named commander — rehearsed, not improvised.
  • Blameless postmortems feeding a visible improvement backlog that actually gets scheduled.
  • Change control implemented in the pipeline: approvals, evidence and rollback as code.

Nothing on that list slows delivery; every item makes speed sustainable. That's the ITIL idea, stripped of its 2007 outfit.

5. Is ITIL Foundation still worth sitting?

As a junior-to-mid credential: yes, cheerfully — it's a fast, cheap vocabulary download for the language large organisations still run on, and ITIL 4's framing is genuinely modern. As a senior credential: it's table stakes, not differentiation; pair it with delivery (PMP/PRINCE2) or governance (the ISACA trio) certifications where the seniority signal actually lives. In my own stack, ITIL is the quiet one — rarely the reason I'm in the room, constantly the reason the room's conversation makes sense.