Twelve service design teams. Over 200 services. A design authority that kept asking whether different services were not, in fact, the same service in a different context. Service designers who disagreed. Business architects who found that both sides were right. The article that explains how.
Service patterns get confused with user stories, process maps, design components, and service blueprints. They are none of these things. They occupy a specific layer of service architecture that most organisations have never named.
Large organisations design the same service interactions from scratch, with no shared vocabulary and no institutional memory resulting in inconsistency. Service patterns can changes this.
Business architecture keeps failing in the same place. Not because the model is wrong, but because it was built to ignore the code the organisation actually runs on. This is the fifth and final article in The Missing Domain series — and the one that says what to do about it.
There is a version of this story I have told at conference tables in which the lesson is about stakeholder management. The engagement succeeded. The client was satisfied. That version is true. It is also incomplete in a way that matters.
The profession's standard defence is that culture is too soft to map. That defence is wrong. Not subtly wrong. Empirical frameworks for characterising organisational culture have existed for decades. Business architecture has simply chosen not to look at them.
Every organisation has three cultures. The one in the mission statement. The one in the policy documents. And the one that shows up when the stakes are real. Most transformation programmes design for the first two. The third one is the one that decides whether your programme lives or dies.
In 2016, a textbook-correct transformation at a Channel Islands wealth firm collapsed two weeks after go-live. The reason was not in any of the frameworks we had used. It was in the one component business architecture refuses to map.
The target operating model is one of the most widely used artefacts in business architecture. It is also an artefact that the world no longer respects. What if the problem is not the TOM itself, but the five-year cadence and mega-programme delivery we keep wrapping around it?
There is a moment I have encountered in almost every transformation programme I have worked on. It happens in a workshop, or a design review, or sometimes in a corridor conversation that nobody planned. Someone asks a question that stops the room. Not a hostile question. Not a political one.
Before I turn to the professional analysis in this article, I want to be honest about the context. The conflict that began on 28 February 2026 has cost thousands of lives. But its consequences have reached into the daily lives of people far beyond the conflict zone. Fuel rationing has
In this series I have argued that organisation debt — the accumulated cost of poor structures, deferred decisions, broken processes, and ungoverned data — is a real liability that belongs on the management agenda alongside financial and technical debt. In Part II, I introduced a practical taxonomy: Decision Debt, Control Debt, Data