One of my mentees once asked me a question I was not prepared for. "Why do we spend so much time creating a capability model, if the stakeholders are never going to use it once we are gone?" I did not have a good answer. And the fact
I have watched some of the most technically accomplished consultants in the industry walk out of client engagements with their analysis intact and their recommendations unimplemented. The decks were excellent. The logic was sound. The findings, in most cases, were exactly right. They were also completely unusable. There is a
Six weeks of discovery. A structural logic already designed twice in the same organisation by teams who never spoke. Pattern chaining is the discipline that changes this. Article 6 of the Service Pattern Playbook.
This article introduces the fifteen patterns that underpin every large public service estate, grouped into five families, with worked examples showing how they combine to build complete services.
Most business capability models end up in a SharePoint folder. Technically correct. Practically invisible. This article challenges that orthodoxy, not to dismiss it, but to ask whether it is the right starting point for every organisation. And to propose something more accessible in its place.
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.