Strategy decks and delivery backlogs are written in different languages. Business architecture is the translation layer. Here is why the two drift apart, and what closes the distance.

Every year, leadership teams gather offsite, argue productively for two days, and leave with a strategy. Three priorities. A handful of bold bets. A deck that, in the room, feels inevitable. Six months later the same leaders look at what shipped and barely recognize their own plan. The bets are half-funded. Two of the priorities never reached a roadmap. The third got delivered — to a team that didn’t know it was strategic.

This is the strategy-to-execution gap, and it is not a motivation problem. The people in the offsite want the strategy to happen. The teams shipping work want their work to matter. The gap opens because the two groups live in different artifacts that never touch. Strategy lives in narrative: themes, ambitions, market moves. Execution lives in tickets: epics, sprints, releases. Nothing in between translates one into the other, so the translation happens informally — in hallway conversations, in a senior engineer’s memory, in a slide someone made once and never updated. Informal translation degrades. Every reorg, every reprioritization, every departure erases a little more of it.

What actually drifts

Watch a strategy decay in slow motion and the pattern repeats. A priority is set as an outcome (“become the easiest bank to switch to”). It is handed down as projects (“rebuild the onboarding portal”). The projects are funded one at a time, scoped by whichever team owns the nearest system, and tracked against delivery dates rather than the outcome. By the time work is underway, the link to the original ambition survives only in the name of a budget line. When the market shifts and leadership asks “are we still set up to be the easiest to switch to?”, no one can answer — because no one mapped the ambition to the things the company actually does.

That phrase is the crux: the things the company actually does. Strategy changes constantly. Org charts change almost as often. But the underlying capabilities a business needs — to onboard a customer, to price a product, to settle a payment — are remarkably stable. A bank needed to onboard customers in 1990 and needs to in 2026. What changes is how well it does it, who owns it, and how much it invests. Capabilities are the layer that holds still long enough to connect a moving strategy to moving execution.

What business architecture does

Business architecture is the discipline of making that connective layer explicit. At its center is a capability map: a structured inventory of what the business does, independent of how it is organized or which software runs it. Around the map sit value streams — how value actually flows to a customer, end to end — and a set of relationships that cross-map strategy to capabilities to the initiatives funding them.

Done well, this turns an unanswerable question into a traceable one. “Are we still set up to be the easiest to switch to?” becomes: which capabilities does that ambition depend on, how mature are they today, and what is currently funded to improve them? That fits on one screen. You can color it by maturity, by investment, by risk. You can see the capability everyone agrees is strategic and no one is funding — the most common and most expensive blind spot in a portfolio.

None of this replaces strategy or execution. It connects them. The offsite still happens. The teams still ship. But now both sides point at the same map, and either side can check — at any moment, not just at the next offsite — whether the work in flight still serves the plan on the wall.

Three signs the gap is widening

1. You can name your strategic priorities but not the capabilities each one depends on.

2. Funding is decided project by project; nothing reviews those decisions against one map of the business.

3. When priorities change, you re-plan from the org chart — because there is no more stable layer to plan from.

Not modeling for its own sake

One caution before the worked example, because it is the reputational trap the discipline keeps falling into. None of this is an argument for modeling everything. A capability map that tries to capture the whole enterprise in exhaustive detail is not more rigorous; it is more likely to be ignored, because no one can hold it in their head and no one will keep it current. The point of the connective layer is to answer questions a leadership team is actually asking — where is our strategy unfunded, where are we paying twice, what breaks if this priority changes. Build exactly enough to answer those, and not one box more. The value is in the questions it settles, never in the completeness of the picture.

A worked example

Return to the bank that wanted to be the easiest to switch to, and run the three questions properly. Which capabilities does that ambition depend on? Account opening, identity verification, data portability, and the ability to move direct debits and standing instructions across from another provider. How good is each one today, honestly? Account opening is strong — it was last year's flagship project. Identity verification is adequate. Data portability is weak and owned by no one in particular. Migrating payment instructions is the worst of the four and lives inside a legacy system every team quietly avoids. And what is funded to improve them? Account opening, again — because it already had momentum, a team, and people who knew how to pitch for budget.

The picture writes itself. The bank is pouring investment into the one capability it is already good at, while the two capabilities that actually decide whether switching is easy go unowned and unfunded. No one chose this. It is the accumulated result of a dozen reasonable, local funding decisions, none of which was ever checked against a single map of what the ambition required. That is the strategy-to-execution gap rendered in one portfolio — and the only thing needed to expose it was the discipline to ask three questions against a stable list of capabilities.

“Isn’t this just planning?”

A fair challenge. Organizations already plan, already budget, already track delivery — so what does business architecture add that those don’t? The answer is the stable middle layer. Planning speaks the language of projects, budgeting the language of cost centres, delivery the language of tickets — three vocabularies that never quite reconcile. Capabilities are the shared noun all three can point at. Without that common reference, alignment depends on individuals who happen to hold the whole picture in their heads, which works right up until the reorganization that scatters them. Architecture is what lets the alignment outlive the people currently maintaining it by memory.

Where to start

You do not need a year-long modeling effort to close the gap. Take one strategic priority and ask three questions. Which capabilities does it depend on? How good are we at each today, honestly? What is actually funded to improve them? The first time a leadership team does this, the answers are uncomfortable — and that discomfort is the point. It is the gap, finally made visible.

That visibility is what Span is about. Twice a month we will take one idea from this space — a technique, a term, a hard-won lesson — and make it usable. The free self-assessment further down is where to begin.

Strategy is debated at the top. Execution happens at the bottom. The middle — where architecture lives — is where decisions go to die.

This is the frozen middle: layers of well-meaning managers who can’t say yes (no authority) but can say no (plenty of incentive). Every architecture initiative that fails in a large enterprise dies here.

The instinct is to fight it with more governance, more committees, more frameworks. This is wrong. You don’t thaw the middle with process. You thaw it with cover from above and pull from below.

Cover: an executive sponsor who absorbs the political heat. Pull: a team in the trenches that wants what you’re selling. With both, the middle melts. With neither, your beautiful target architecture becomes another PDF in the shared drive.

Business architecture is a structured description of what an organization does and how its parts fit together — separate from how it is staffed, structured, or automated. Its core artifact is the capability map: a stable inventory of the abilities a business needs to operate, such as “manage customer onboarding” or “settle payments.”

It is not the org chart (that shows who reports to whom), and it is not a process map (that shows the steps in a task). A capability answers a different question: what must we be able to do, regardless of who does it or how. That difference is the whole point. Teams reorganize and tools get replaced, but the capability to onboard a customer persists — which makes it a reliable anchor for planning, funding, and measuring.

Architects use the map to connect strategy to delivery: tag the capabilities a strategic goal depends on, rate each one’s maturity, and trace the initiatives investing in them. The result is a single picture that answers the question most portfolios cannot — are we actually building toward our strategy, or just staying busy?

Said the EA, “Let’s start with the Why.”
Said the CFO, “Just tell me when. Try.”
So they argued for weeks,
Drew capability peaks,
And the project just waved them goodbye.