Draw the usual diagram and it looks complete. A box for strategy. A box for product. Boxes for the delivery teams. Arrows between them, pointing in the right direction. The diagram is honest about almost everything except the one thing that matters: there is nothing inside the arrows. The space between strategy and delivery is treated as a connector, not a discipline — as though intent flows downhill on its own once the boxes are drawn. It does not. That space is where most transformation value is lost, and almost no organisation has named it, staffed it or held anyone accountable for it.
The evidence that the space exists is not subtle. PMI's December 2025 study of roughly 5,800 project professionals found that only about half of projects meet a modern definition of success; 13% fail outright and 37% deliver only part of what was expected. In the companion executive survey, the single most-cited barrier to reinvention — named by 35% of executives, more than any other factor — was a disconnect between planning and execution, with 93% saying they must rethink their operating approach at least every five years. The strategy is rarely the problem. The translation of strategy into concrete, sequenced, deliverable change is.
The layer everyone assumes is happening
The reason this gap persists is not effort and it is not communication. It is ownership. Strategy is owned by the executive. Delivery is owned by the teams. The translation between the two — the work of turning a direction into a structure people can build against — is owned by no one in particular, so everyone assumes it is happening because the boxes on the diagram exist. It is the same failure whether you meet it from the organisational side or the technical one. A discipline with no owner is not done badly; it is done inconsistently, by whoever happens to be in the room, if at all.
PMI reaches a structural verdict too, pointing at rigid operating models and fragmented accountability rather than weak teams. The wider strategy-execution literature has said the same for years: somewhere between half and two-thirds of strategies stall in execution, and leaders consistently blame poor translation into action and misalignment rather than a bad plan. The market has a dozen names for the symptom — alignment, operating model, OKR hygiene — and no convincing name for the missing function itself.
It already has a name — and it was filed under the wrong department
Here is the awkward part. Enterprise architecture named this layer decades ago. TOGAF's Architecture Development Method defines three explicit states — Baseline (where you are), Target (where you intend to be) and one or more Transition Architectures (the phased states in between) — as the formal mechanism for moving from strategy to delivery. Its Capability-Based Planning builds a business capability map and gap analysis, then decomposes capabilities into increments that each deliver a discrete, measurable outcome. Capability mapping, domain modelling, target and transition states, roadmaps: these are not an invention waiting to be made. They are a recognised discipline that most delivery organisations quietly stopped doing, because classic EA earned a reputation as a slow, ivory-tower function producing diagrams divorced from anything that ships.
So the artefacts exist and the function is discredited. That is the white space. We call the rehabilitated middle Delivery Architecture: the translation layer that connects business strategy to product to architecture to engineering to operations to outcomes, owned by someone accountable for the whole path, not handed off in fragments at each boundary.
Decisions, not deliverables
What rescues these artefacts is treating them as decisions rather than documents. Martin Fowler defines architecture as the decisions that are both important and hard to change, and judges a good architect by whether they make future change easier. Michael Nygard's Architecture Decision Records, from 2011, push the same point into practice: the durable thing worth keeping is the decision and its rationale, captured lightweightly enough to stay alive. A capability map drawn once and laminated is the ivory tower. A capability map maintained as a living record of which boundaries we have committed to, why, and at what cost to reverse, is decision-quality work. Architecture, in our spine, is not about diagrams or technology. It is the discipline of making decisions that let an organisation change safely and deliver consistently — and the translation layer is where those decisions are densest and most consequential.
A capability map is not a picture of the organisation. It is a record of the decisions you have made about where the organisation is allowed to change cheaply — and where it is not.
Framing the layer as decisions also imports a test the documentation framing lacks: reversibility. Borrowing Jeff Bezos's distinction between one-way and two-way doors, transition states and domain boundaries are overwhelmingly one-way doors — slow and expensive to walk back once teams, contracts and data have formed around them. Knowing which decisions are irreversible tells you where to spend deliberation and where to move fast, and that is precisely the judgement that disappears when the work is treated as a deliverable to be signed off rather than a decision to be governed. Govern it by something closer to Harmel-Law's advice process than by an approval committee, and the layer stays fast as well as owned.
Skipping it is not neutral — you ship a default organisation
There is a sharper reason not to skip this layer than lost value. Conway's Law, sharpened by the Team Topologies work, holds that system architecture mirrors organisational communication. Domain and boundary decisions are therefore organisation-design decisions wearing technical clothes. Draw the domains and you have drawn the teams, the ownership lines and the communication paths. Decline to draw them deliberately and the boundaries form anyway, around whatever the org chart and the existing codebase happen to suggest. Skipping the translation layer is not abstention. It ships a default organisation, and a default organisation is almost never the one your strategy needed.
AI moves the scarce work up, not away
The reflex is to assume faster tools will paper over the gap. The opposite holds. DORA's 2024 research found that internal developer platforms and AI both lift individual productivity yet can erode delivery stability and throughput without deliberate design, and that cloud migration without genuine architectural flexibility can underperform staying on-premise. McKinsey frames enterprise architecture as the discipline that decides whether transformation value is captured at all, warning that modernisation for its own sake fails and that domains where architecture confers competitive advantage should be tackled first. Both say the same thing in different registers: AI and platforms only pay off behind architectural guardrails and standardised workflows.
That makes the missing layer the binding constraint on AI delivery rather than a casualty of it. When agents can produce plausible artefacts overnight, coding throughput stops being scarce. The scarce human work moves up — to capability boundaries, target states, domain models and the decision quality that determines whether the cheap output was worth generating. This is the logic of The Acceptance Gap pushed upstream: once generation is abundant, value migrates to the adjacent step that is still hard, and the adjacent step is the translation. Delivery Architecture, not throughput, becomes the differentiator, because an agent can write the system far faster than it can tell you which system was the right one.
What to do on Monday
Name an owner for the translation, with a budget and a remit that spans strategy through operations rather than stopping at a handoff. Maintain a capability map and a baseline-target-transition view as living decision records, not a one-off deck. Tag the boundary and transition decisions by reversibility, and spend your deliberation where the doors are one-way. Treat every domain boundary as an organisation-design decision and decide it on purpose. Do this and the arrows between the boxes finally contain something. Skip it and you will keep funding the production of well-built systems that solve the wrong problem with admirable velocity.
If this resonates, read Architecture Is Not About Technology — It Is About Decision-Making for why decision quality — not documentation — is the unit of architecture, and The Acceptance Gap for why, once generation is cheap, this translation layer becomes the constraint that decides whether AI delivers value at all.