Consistency without connection is cost; connection without consistency is chaos — why “ITIL vs. the rest” is a false choice
An honest dive into the recent debate about ITIL 4, “Humanising IT,” “Value-Engineering,” and the so-called “framework crisis” — and how to cut through the noise with a simple, integrated, verifiable operating model.
Before we begin, a quick context (and 7 frank questions):
You probably arrived here because you’ve heard that “ITIL got expensive,” that “it doesn’t fit DevOps,” or that “there are modern alternatives.” Before you buy a new label, run an honest check on your reality:
- When someone says “service” at your company, does that mean perceived value or a ticket queue?
- Do your changes go through an approval meeting or through evidence in the pipeline (tests, security, segregation of duties, progressive delivery)?
- What are your SLOs? Who signed them? How do you use the error budget in decision-making?
- Has your MTTR dropped in the last 90 days? And your change failure rate?
- Do experience indicators (CSAT/NPS and team EX) show up at the executive committee as much as SLAs?
- Do ITIL 4’s guiding principles (keep it simple & practical, start where you are, focus on value) show up in everyday tools — or only on the wall?
- Have you invested more in certification than in adoption? Why?
I spent hours reading qualified contributions — agreements, critiques, and provocations — and distilled here what’s signal (what changes outcomes) and what’s noise (what only changes the label). If any question above made you uncomfortable, good: this text is for you.
1) The end of the world (that didn’t happen)
In recent days I went back to basics: I stopped to calmly read dozens of comments from professionals I respect — people who live operations, who teach, who design policies, who defend audits and suffer when they bog things down. Among praise, criticism, and provocation, the loudest narrative was that there’s a “dilemma” around ITIL and that “new approaches” are finally pointing to a way out.
Here’s my starting point: there is no dilemma where there’s a false dichotomy. “ITIL vs. an alternative” is a bad question. The problem was never ITIL, just as it was never DevOps, SRE, SIAM, or any other label. The problem is when we confuse consistency with bureaucracy and human connection with improvisation.
If your organization chooses “consistency without connection,” you buy cost. If it chooses “connection without consistency,” you buy chaos. Value is born between the two — right where a common language (ITIL 4) meets behavior, design, and automation (DevOps/SRE/HCD) and, increasingly, AI with guardrails.
2) What’s actually being disputed
There are three underlying disputes in this conversation:
- Language vs. behavior. ITIL 4 gives vocabulary, artifacts, and a Service Value System. That’s essential for alignment and governance. But vocabulary without behaviors (working agreements, honest feedback, focus on outcomes) doesn’t change the user’s reality.
- Process vs. tool. When the process lives outside the tool, a parallel ritual no one respects is born. When the process is embedded (rules, automations, templates), the experience flows — and governance appears as evidence, not as memos.
- Human control vs. automation. Approving change “in a meeting” is costly and slow. Controlling in the pipeline (tests, security, segregation of duties, progressive delivery) is safer, faster, and more auditable. It’s not less governance — it’s different governance.
“Humanising IT” speaks to experience; “Value-Engineering” demands evidence. A mature synthesis doesn’t pick one or the other — it unites experience + engineering.
3) From classroom to gemba: two implementations I’ve seen lately
Company A did everything “by the book”: a wave of certifications, a dozen mapped processes, lots of new forms. The change backlog grew, the success rate improved a bit, but MTTR and user perception stayed almost the same. Moral: compliance without experience.
Company B started smaller: defined 2 critical value streams, treated service like a product (with an owner, SLOs, and budget), implemented risk-based change inside the pipeline, and trained blameless post-mortems. The next quarter, MTTR fell, the change failure rate plummeted, and people felt the difference. Moral: experience with consistency.
It wasn’t a miracle of labels. It was adoption discipline.
4) How to reconcile ITIL 4, DevOps/SRE, and Design without reinventing the wheel
Start with service as a value principle. If “service” is treated like a low-status department, you lose sponsorship. If “service” is seen as a capability that enables desired outcomes while managing risks and costs, the game changes. Name an owner, define SLOs that make sense to the customer, and create a roadmap that speaks to experience, not only SLA.
Move control into the pipeline. Manual approval becomes a queue; automated evidence becomes trust. Policy-as-code, feature flags, and progressive delivery turn “change” from ceremony into engineering. Audit? Easier — you prove with logs and gates instead of meeting minutes.
SRE beyond the buzzword. SLOs designed with the customer, error budgets to balance stability and pace, and blameless post-mortems that produce real improvement actions.
A lean SMO. A small unit (or chapter) that orchestrates practices, data, and continuous improvement — not to police people, but to enable teams and prevent regressions. The SMO ensures the process lives in the tool and that metrics talk across areas.
AI with guardrails. AI removes repetitive steps and expands support, but requires clear roles, risk management, MLOps/ModelOps, and EX/CX telemetry so you don’t “optimize” what doesn’t matter.
5) When the criticism sticks — and how to address it
“It got bureaucratic.” I agree: sometimes it does. The fix is lean policies, short runbooks, automated change models, and cycle-time SLAs for internal work.
“It turned into a product and lost the plot.” That happens too. When the standard is sold as an end in itself, focus drifts from the user. Prescription: value/flow/experience metrics visible to the executive committee and everyday, accessible trainability.
“Lots of alternatives, little result.” Call it framework fatigue. The answer is architecture: a design that makes clear what’s core (common language, incident/change/request, improvement) and what’s contextual (SRE/DORA for Product, FinOps/AI for Platform, reinforced audit trails for Regulated areas).
6) Judge by evidence, not by labels
Before you “switch doctrines,” ask:
- What improved, numerically, in reliability, speed, and experience?
- How does the approach hold up in high-risk, audit-heavy environments?
- Is there an ecosystem (people, content, practices) to scale it?
- How does it fit with what already works (ITIL/ISO/COBIT/DevOps) without creating rework?
- If the answer is weak, the problem isn’t your “doctrine” — it’s your adoption process.
7) Conclusion
The recent debate surfaced something precious: the urgency to reconnect consistency and connection. What paid the bills in the organizations I observed was far less glamorous than marketing would like: ITIL 4 as a lingua franca, SRE/DevOps as flow engineering, human-centered design as daily practice, automation as control, and data as arbiter.
Consistency without connection is cost. Connection without consistency is chaos. Value happens where the two meet.
Categorias
Artigos Relacionados
The “ITIL Dilemma” Is False: Consistency + Connection for Real ITSM Value
Consistency without connection is cost; connection without consistency is chaos — why “ITIL vs. the
