Can Service Patterns Replace Business Capabilities? A Necessary Challenge

There is a capability model I think about often. A large public sector organisation. Eighteen months of work. A team of experienced architects. Workshops across every directorate. A heat map that covered two walls of the boardroom. The chief executive called it one of the most insightful pieces of work the organisation had ever commissioned.

That was four years ago. I recently spoke to someone still working in that organisation. The model exists, technically. It lives in a SharePoint folder that three people know about. It has not been updated since the year it was built. It has not informed a single investment decision in the past two years. The architect who built it left. The business stakeholders who attended the workshops moved on. The institutional knowledge that animated it dissipated. What remains is a document that is technically correct and practically invisible.

This is not an isolated case. It is, in my experience, the modal outcome of a business capability modelling exercise in an organisation that has not yet developed the architectural maturity to sustain one.

The Business Architecture Guild places business capabilities at the centre of the BA universe. The capability model is the foundation on which everything else is built: strategy alignment, technology investment, operating model design, organisational change. This is a coherent and well-developed intellectual framework, built on decades of practice and refined by some of the most rigorous thinkers in the profession. It deserves to be taken seriously.

It also has a deployment problem. And that problem is more widespread than the Guild's published frameworks acknowledge.

The abstraction gap

Business capabilities are defined as what an organisation does, independent of how, who, or with what technology. This independence is the point. A capability model is stable across re-organisations, system replacements, and delivery model changes. It gives architects a fixed point of reference in an environment of constant change. These are genuine architectural virtues.

They are also the qualities that make capabilities invisible to the business stakeholders who most need to engage with them.

'Customer Communication Management' is a well-formed capability. It is stable, it is independent of implementation, and it maps cleanly to the systems, processes, and people that enable it. It means almost nothing to the head of a service directorate who is trying to decide whether to invest in a new case management system. 'The way we tell people what has happened to their application, and when' means everything to that person. It describes something they recognise. It connects to decisions they make every day.

The abstraction that makes capabilities architecturally precise is the same quality that makes them organisationally inaccessible. The model is built in the language of architecture. The organisation speaks a different language. And in most organisations, architecture loses that translation battle not because the model is wrong, but because it arrives before the trust that would make it useful.

What the Guild's framework assumes

The capability-centric model assumes a level of architectural maturity that most organisations do not yet have. It assumes that business stakeholders can engage with abstracted representations of what an organisation does. It assumes that there is sufficient architectural credibility and organisational trust for a capability model to be used as the basis for investment decisions rather than filed as an interesting artefact. It assumes that the architects who build the model will be around long enough, and embedded deeply enough, to maintain it as the organisation evolves.

These are not unreasonable assumptions for a mature architecture practice operating in a supportive organisational environment. They are heroic assumptions for an architecture function that is two years old, has not yet established its credibility with the business, and is operating in an organisation that has never used the word 'capability' in a strategic context.

The Guild's framework was built by practitioners for practitioners. It describes what a sophisticated BA practice can achieve. It does not adequately address the question of how an organisation gets there from nothing, or from very little. That is the gap this article is concerned with.

The patterns proposition

Service patterns describe what organisations recognise. Not what an organisation abstractly is capable of, but what it actually does in its interactions with the people and entities it serves. A pattern called Capture and Triage does not require a business stakeholder to engage with a new conceptual framework. It describes something they deal with every day: what happens when someone contacts the organisation, and how that contact gets to the right place.

This accessibility is not a cosmetic advantage. It is a structural one. An architectural concept that business stakeholders can engage with is one that can be used to make real decisions: about service design, about technology investment, about where duplication exists and where it does not. An architectural concept that business stakeholders cannot engage with, however intellectually rigorous, makes decisions in isolation from the business and is routinely ignored as a result.

For organisations that are new to business architecture, or that sit at the lower end of the maturity scale in their understanding of what BA can do, service patterns offer something that capability models rarely deliver in the early stages: a quick, credible, visible demonstration of value. A pattern analysis of an existing service portfolio can be completed in weeks rather than months. It produces outputs that business stakeholders can read without training. It reveals structural duplication, inconsistency, and design debt in language that resonates with the people who have the authority to act on it. It earns the trust that a capability model then requires in order to be useful.

Naming what patterns cannot do

Intellectual honesty about the limits of this argument matters as much as the argument itself.

The most important objection is not that patterns are imprecise. It is that they are anchored to the present. Patterns describe the structural logic of services as they currently exist. A capability model describes what the organisation must be able to do, independent of how its services are currently structured. This forward-facing quality is what makes capability models useful for long-horizon decisions: a capability that does not yet exist can still be modelled, invested in, and built toward. A pattern that does not yet exist has nothing to describe.

An organisation that uses patterns as its only architectural lens risks embedding current-state thinking at precisely the moment it most needs to challenge it. When a transformation programme is asking not just 'how do we improve our services' but 'what kind of organisation do we need to become', capability models provide a frame that patterns cannot.

Patterns are also interaction-oriented in ways that limit their use for organisation design and technology alignment. A capability model tells you what the organisation must be able to do and maps that to the systems, roles, and processes that enable it. This mapping is the foundation of application rationalisation, of role design, and of the kind of M&A analysis that requires a stable, implementation-independent view of what an organisation actually is. Patterns serve none of these purposes.

The argument here is not that patterns are better than capabilities. It is that patterns are a more effective starting point for organisations that are not yet ready to use capabilities well.

The maturity path

In practice, the two concepts are more complementary than they are competitive, and the sequencing matters considerably.

An organisation beginning its BA journey with service pattern work is building something that a capability model later depends on: business stakeholder engagement, a shared vocabulary for service structure, and architectural credibility earned through visible, practical output. When the conversation eventually turns to capability modelling, the organisation has a foundation. Business stakeholders who have used pattern analysis to make real decisions about service consolidation are better placed to engage with the more abstract question of what capabilities underpin those services than stakeholders who have had no architectural exposure at all.

The patterns become the bridge. Not from services to capabilities in a single conceptual leap, but through a sequence of conversations in which business stakeholders gradually develop the architectural vocabulary and trust that capability modelling requires. Patterns first. Capabilities when the organisation is ready for them. Not as a permanent substitute, but as a deliberate stepping stone that makes the destination reachable.

A challenge to the Guild

The Business Architecture Guild's maturity model describes how BA practices evolve. It does not, in my reading of its published frameworks, adequately address the entry point problem: how an organisation with no architectural culture, no established credibility for the function, and no shared vocabulary begins to build one.

The Guild's implicit answer is to start with capabilities. My experience, across a range of organisations at different maturity levels, suggests that for many of them, starting with capabilities is the reason the practice never takes hold. The abstraction arrives before the trust. The model is built before the organisation understands why it needs one. The result is the SharePoint folder.

A patterns-first entry path is not a dilution of BA practice. It is a more honest account of how architectural value gets established in environments that have not yet learned to expect it. The Guild has the intellectual resources, the practitioner community, and the credibility to develop this thinking. The question worth putting to it directly is this: what is the right entry point for an organisation starting from nothing, and is the capability model it has always recommended genuinely the answer for every maturity level? That conversation, if the Guild is willing to have it, would benefit the profession considerably.