A misdiagnosed problem
Every large enterprise has a strategy. Most have several: corporate, digital, technology, data strategy. Each is carefully crafted, approved at board level, and translated into programs of work. Yet, somewhere between the executive floor and the engineering team, something goes wrong.
It rarely goes wrong dramatically. There is no moment of failure, no single fatal decision. What happens instead is a slow, structural dissolution. The strategic objective becomes an initiative. The initiative becomes a project. The project becomes a backlog. The backlog becomes user stories. And the strategy begins to whither. Not in the boardroom but in translation, where outcomes such as ‘grow SME lending by 25%’ or ‘reduce onboarding time to under five minutes’ are reduced to tickets, estimates and disconnected delivery.
This is the strategy-execution gap. It’s the most costly recurring problem in large enterprise technology management, and it’s frequently misdiagnosed.
Research has consistently highlighted the issue. Harvard Business Review reported that 67% of well-formed strategies fail in execution. A 2025 PMI global study of nearly 6,000 project professionals found that only half of projects today deliver value that justifies the investment — and the top barrier, named by 35% of executives, is the disconnect between planning and execution. Not capability. Not capital. Not technology. The gap between intent and delivery is the leading cause of strategic failure — and it has been for years.
This isn’t a strategy problem. Large enterprises typically have sophisticated strategy functions, mature planning processes and experienced leadership teams. The strategies themselves are often well-conceived.
It’s not an execution problem. Most large enterprises have invested heavily in agile delivery, DevOps, platform engineering and developer experience. Their engineering organizations are often highly capable.
This is an information architecture problem: a failure of how information is represented and flows in the enterprise. Strategy sits in slides. Architecture in diagrams. Delivery in tickets. None of it connects or updates. None of it can be interrogated as a system.
The result? An enterprise that’s simultaneously over-invests and under-invests in rebuilding capabilities it already has. And it misses the ones it actually needs, because the gaps aren’t visible until delivery fails.
Complexity isn't the villain, it's distributed autonomy without shared infrastructure
It’s tempting to attribute the strategy-execution gap to complexity. Large enterprises are, by definition, complex — multiple business units, multiple geographies, decades of accumulated technology, thousands of engineers working on hundreds of systems simultaneously. Complexity is real. But complexity isn’t the cause of the problem. Complexity’s the environment in which a more specific structural failure plays out.
The financial consequences are significant. McKinsey estimates that mismanaged strategy implementation costs enterprises up to 10% of annual revenue. More damaging still: as much as 60% of enterprise spend is lost to misalignment. Not bad decisions. Ill-informed decisions. And more than three out of five executives know they can’t bridge this gap The depressing truth? This is how most large enterprises operate.
The real failure is structural. Enterprises reward local optimization before realizing that’s a recipe for fragmentation. Give each business unit its own budget and roadmap, and they’ll do the rational thing: build what they need, when they need it. This is the predictable outcome of a system that rewards local speed over enterprise coherence.
The result is a capability estate that makes no sense at scale. The same capability is built over and over again, in slightly different forms, by different teams. Critical capabilities are missing, not because the organization lacks the resources to build them, but because no one has line of sight to the gap. Without a complete picture of what the enterprise can do, you cannot know what it cannot do.
A full-service bank is the clearest example of this failure mode in practice. Know Your Customer (KYC) — is a mandated capability for every business unit in a bank. In most large banks, KYC is implemented repeatedly: once for retail, once for SME, once for institutional banking, once for wealth management, and once for a digital channel team that didn’t know the others existed. The duplication could also be a result that each of the platforms that the BU chose also mandated the usage of their own modules to handle KYC. Each implementation was rationally justified at the time it was built. Collectively, they represent a governance failure of the first order — a failure that compounds every time a new product team needs KYC and chooses to build another implementation rather than navigate the uncertainty of what already exists. In our work with enterprises we’ve been contracted far too many times to consolidate such redundant systems, often involving expensive, complex data migrations that are extremely high risk.
In banking specifically, industry analysis has found that simplifying over-engineered IT environments — where the same capability has been built multiple times across business lines — can reduce application and infrastructure costs by up to 50% and total IT costs by up to 30%. The capability is already there. The cost is in building, maintaining and then merging its duplicates.
The standard industry response to this failure — create a center of excellence, mandate shared platforms, institute an enterprise architecture function with sign-off authority — addresses the symptom without addressing the cause. These interventions attempt to solve a distributed information problem with a centralized authority. They create friction without creating clarity. And they consistently fail to make the capability estate queryable — to give the CTO, the CIO, or the Chief Architect the ability to answer, in real time: what can we do, is it fit for use, who owns it, and does it connect to what we are trying to achieve?
What’s worse, over time, we’ve seen the same steady descent again into fragmentation, despite a (typically outdated and ignored) “capability map” that was made with much hard work and precious employee time in large room planning workshops.
The answer to distributed autonomy without shared infrastructure is not centralization. It’s federation with a shared vocabulary that actively drives value to the frontlines.
Three gaps that compound each other
The strategy-execution gap manifests itself as three specific, interconnected issues; each damaging in isolation, collectively debilitating when they compound.
Strategy execution fails across three gaps:
1. Capability Inventory. We don't know what we already have.
2. Scenario composition. We can’t easily "plug and play" existing parts into new products.
3. Traceability. We can’t see which board goals are at risk when a system fails.
The capability inventory gap
There is no authoritative, fitness-assessed, up-to-date inventory of enterprise capabilities. While individual teams know their own systems, no one can quickly and reliably answer enterprise-wide questions: Is this service healthy? Who owns it? What journeys depend on it? Every new product initiative defaults to rebuilding from scratch, because reusing existing capabilities feels riskier than starting fresh. This is how enterprises end up with six implementations of KYC and a near-zero reuse rate. The financial cost is significant: a McKinsey and University of Oxford study of more than 5,400 large IT projects — each exceeding $15 million — found they deliver 56% less value than predicted and run 45% over budget, with combined cost overruns exceeding $66 billion, more than the GDP of Luxembourg. Much of this traces directly to organizations investing in capabilities they already have, or missing the ones they don't.
The composition gap
Even when capabilities are discoverable, composing them into end-to-end customer journeys is fragmented. The typical process — product owner describes a journey, architect draws a diagram, committee approves something different, engineers build something different again — means the final product barely resembles the original strategic intent. The tools and processes simply aren't designed for composition: there's no library of existing journeys, no structured blueprint to force the right questions at each step, and no mechanism to surface capability gaps and route them into the investment pipeline. The result is endemic duplication. According to Gartner, eliminating redundant applications saves an average of 20% of application maintenance costs in year one — significant given that maintenance already consumes roughly 70% of the average enterprise IT budget. Duplication is the default state when reuse requires more effort than building new.
The traceability gap
This is the most damaging and least discussed of the three gaps. The problem runs in both directions. When a service degrades, the enterprise cannot immediately identify which customer journeys are affected, which strategic objectives are at risk, or who needs to be in a room. When the board sets an objective — grow digital revenues 30% in 18 months — the enterprise cannot reliably map which capabilities need to exist and what investment is required to get there. Without this bidirectional traceability, from strategy down to service, and from service up to strategy, governance becomes reactive, investment becomes political, and risk stays invisible until it isn't.
What a business architecture platform actually does
A business architecture platform isn’t an architecture tool. It isn’t an ITSM replacement, a service catalog, or another layer of governance overhead imposed on engineering teams who are already carrying too much process. It’s the connective tissue between strategy and delivery: the institutional mechanism that makes the three gaps above closeable, simultaneously and continuously, not as a one-time mapping exercise that goes stale within six months of completion.
The platform works through three mechanisms operating together.
The first is a live capability registry — the authoritative answer to "what can we do?" Every capability the enterprise possesses is registered against a common taxonomy, assessed for fitness through automated scorecards, monitored for health through event-driven signals from the engineering platform, and linked to the services that implement it. This registry is a queryable data layer, updated in near-real time by the system it models, not by human effort applied to keeping a diagram current.
The choice of taxonomy matters enormously. In financial services, the Banking Industry Architecture Network (BIAN) framework provides a mature, widely understood capability taxonomy that gives business and technology teams a shared vocabulary for the first time. A head of retail banking and a principal engineer can both point to "customer onboarding" in the taxonomy and mean the same thing. That shared meaning is the foundation on which everything else is built. Without it, federated governance is just another word for fragmentation.
The second mechanism is a journey composition layer; the answer to "how do we compose what we have into products our customers can use?" This layer includes a library of existing journeys that teams check before composing anything new, a structured blueprint process that forces the question of all five delivery lanes simultaneously (what the customer experiences, what channel delivers it, what orchestration manages the workflow, what business capabilities execute the logic, and what engineering platform capabilities underpin all of it), and an AI-assisted composition tool that makes reuse economically rational.
Journeys composed at the right level of abstraction can themselves become catalog entries — reusable capability sets leveraged across multiple products, with identity verification being a good example: a composite of data collection, DPI validation, internal database checks and a liveness test that no team should need to rebuild from scratch. The capability landscape in scope spans business, data, agentic and technology capabilities, and the composition team reflects this by bringing together the product owner, enterprise architect, data architect and AI architect to identify what the organization needs to do, know, decide, and act upon at each stage of a journey. Once agreed, the blueprint is handed to engineering as a structured unit of work, who then orchestrate the identified capabilities across all four buckets, build what is missing, and publish everything back to the registry — ensuring what was designed is what gets built, and what gets built is what the next team finds.
The economics of reuse are well established. McKinsey's analysis of one international consumer company building shared data products found that enabling five use cases from a single shared product cost 30% less than building five individual solutions. When that same data product was scaled to a second market, projected costs were 40% lower still. The cost reduction came from reuse of the standardized product, and the accumulated experience of the team that built it. This is the compounding return of a capability estate built for composition rather than duplication.
The economic point deserves emphasis. Reuse loses to rebuild because it’s harder. It means finding what exists, judging if it’s fit, negotiating with the team that owns it, and taking a dependency on a system you don’t control. Building is easier, at least at the start. Change that moment and you change the outcome. An AI composition assistant that surfaces existing capabilities, tests their fitness and drafts a blueprint in minutes shifts the decision. When reuse is easier than rebuild, teams reuse. That’s the tipping point.
The third mechanism is a governance layer — the traceability chain that connects strategy to service, and the investment pipeline that turns gaps into funded decisions. Strategic objectives are registered in the platform and linked to the capabilities and journeys that deliver them. Every deployed service traces upward through the capability it implements, through the journey it serves, to the strategic objective it advances. When a service degrades, the platform can answer within seconds which journeys are affected, which objectives are at risk, and which Business Unit executives need to act.
This traceability chain isn’t a reporting exercise, nor something produced quarterly for a governance committee. It is a live graph that updates as the world changes — when capabilities are registered, when services are deployed, when health states shift, when gaps are identified, when objectives are created or retired. The graph is the governance mechanism. The traceability is the accountability.
Why the timing is right — and what makes this different from previous attempts
Enterprise architecture has attempted to solve the strategy-execution gap before. TOGAF, COBIT, IT4IT, capability maturity models, service catalogs, configuration management databases — each addressed a real part of the problem, and each ultimately failed to sustain the information quality needed to be genuinely useful. Architecture artefacts went stale. Service catalogues became shelfware. CMDBs drifted from reality within months of their last update. The gap persisted.
Why? Because maintaining an accurate picture of a large, complex, continuously changing technology estate requires more human effort than organizations are willing to sustain. The moment a diagram requires manual updating to stay current, it stops being current. The moment a capability registry requires a dedicated team to keep it accurate, it becomes a compliance burden rather than a decision-support tool.
The urgency is increasing. Quantive's 2024 global strategy survey of nearly 400 executives across more than 20 industry sectors found that only one in 10 organizations can pivot quickly to adapt to changing market conditions. Nine in 10 cannot. In an environment where strategic conditions change faster than annual planning cycles can track, an organization's ability to maintain the connection between strategy and delivery in real time isn’t a nice-to-have. It’s a competitive necessity.
Three things have changed that make a platform approach viable now in ways it wasn’t a decade ago.
Event-driven architecture has changed the currency problem. When services emit lifecycle events — registered, deployed, updated, degraded, retired — that automatically update the capability registry, the gap between the map and the territory closes. The registry stays current not because a team maintains it, but because the system maintains itself. This is the architectural pattern that previous service catalog and CMDB initiatives lacked: a self-updating information layer driven by the system it models, not by human effort applied against it.
AI-assisted composition has changed the economics of reuse. The hardest part of operating a capability registry isn’t building it — it’s getting teams to use it consistently enough that it generates real value. When an AI assistant can take a natural language description of a customer journey, check the library for existing compositions, surface relevant registered capabilities, flag fitness and governance issues, and draft a structured blueprint in minutes, the cost of using the platform drops below the cost of not using it. Adoption follows when the tool is the path of least resistance, not an additional obligation.
The maturity of domain-driven design and API-first delivery has changed what is available to be cataloged. Modern engineering organizations structure their services around bounded contexts and domain ownership. They expose capabilities through versioned API contracts. The technical estate is already organized in ways that map naturally to a business capability taxonomy — not perfectly, but substantially. Registering what already exists is a matter of tagging and linking, not a ground-up architectural rewrite.
These three shifts together mean that the platform described in this article is buildable incrementally, demonstrably and without requiring a large enterprise to pause delivery while it completes a multi-year transformation program. Start with one business unit and one domain. Register its capabilities. Map one customer journey through a five-lane blueprint. Trace it to a strategic objective. Surface one gap and route it through the investment pipeline. The proof of value is visible within weeks, not years.
The governance insight that changes the model
The word governance does damage in large enterprises. It has accumulated decades of association with slowness, bureaucracy, committees and the systematic friction of getting things approved. When technology leaders hear "governance platform," they hear "another gate between the idea and the delivery."
The insight at the heart of this new approach is that governance, designed correctly, doesn’t slow delivery. It accelerates it. The friction that teams experience as governance overhead is almost never the governance itself — it’s the absence of clear decision rights, the lack of shared information, and the ambiguity about who owns what outcome. These are information architecture problems. Solve them with better information architecture, not with lighter governance.
The platform makes governance continuous and embedded rather than episodic and external. When a product owner uses the composition tool to design a new customer journey, the library check, the blueprint approval, and the fitness assessment aren’t bureaucratic steps imposed from outside — they’re the natural workflow of the tool. Governance happens at the moment of design, not in a committee review three months later. The architectural decisions are better because they‘re made with full visibility of what exists, what’s fit, and what strategic objectives are being served. And they are faster because the information needed to make them is available in real time, not assembled over weeks of investigation.
The investment pipeline is the governance mechanism that changes the relationship between architecture and funding. In most large enterprises, the decision about which capabilities to build or improve is made through a combination of project business cases, executive lobbying and annual planning cycles. The loudest voice at the investment committee, or the most compelling slide deck, has a disproportionate influence on where money goes. The capability gap pipeline replaces this with an evidence-based, risk-ranked, strategically-linked investment backlog. Every gap identified through composition — whether by an AI assistant or a human architect — is automatically routed into the pipeline with its strategic context, its risk assessment, and its priority score. The architecture authority makes investment decisions from data, not from persuasion.
Federated ownership with centralized standards is the governance design that resolves the central-versus-local tension that has frustrated enterprise architecture for decades. Business Units own their journey compositions, their investment decisions within their domains, and their delivery roadmaps. The architecture authority owns the capability taxonomy, the fitness thresholds, the integration standards, and the investment governance rules. Neither overrides the other's domain. The taxonomy makes federation possible without fragmentation — because when everyone uses the same vocabulary for capabilities, a business unit can build and own its implementations while the enterprise can still see, aggregate and govern the whole.
What good looks like: the measures that matter
The value of this approach is measurable. But the right measures aren’t the ones that large enterprises typically track for technology programs — cost savings, headcount reduction, percentage of services migrated to the cloud. These are efficiency metrics for a problem that’s fundamentally about effectiveness. The measures that reveal whether the strategy-execution gap is actually closing are different. These include:
Composition velocity. The time from "we want to build this customer journey" to "we have an approved blueprint ready for engineering" measures whether the platform is genuinely accelerating the front end of delivery. In most enterprises today, this takes weeks. With an active capability registry, a journey library, and AI-assisted composition, it should take days. The difference compounds across every product initiative the organization runs.
Reuse rate. The percentage of journey steps that use an existing registered capability rather than a net-new build reveals whether the economic tipping point has been reached. Below 40% reuse, the platform is present but not yet dominant. Above 60%, the capability estate is genuinely being treated as shared infrastructure rather than as a collection of team-specific implementations. Reuse rate is the leading indicator of long-term capability investment efficiency.
Strategic coverage. The percentage of active Tier 1 strategic objectives with at least one approved journey registered in the platform is the most honest measure of whether strategy is being executed, not just declared. An objective without a registered journey is strategy that exists only on a slide. One hundred percent coverage doesn’t mean all objectives will be achieved; it means the organization has a traceable line of sight from intent to delivery for every commitment that matters.
Gap-to-investment cycle time. The days from a capability gap being identified to it reaching architecture decision record status measures whether the investment process is actually connected to the platform. This is the feedback loop that validates whether the composition process is changing how the organization allocates capital, not just how it documents what it’s building.
Feedback loop latency. The time from a service health degradation to the relevant business executive knowing which strategic objective is at risk is the metric that changes the conversation from technical incident management to strategic risk management. When a Tier 1 objective is at risk because a critical service is degraded, that’s a board-level conversation. The platform should make that conversation happen in hours, not after a quarterly review and multiple negative customer reviews.
What you should take from this
The strategy-execution gap is not inevitable. It’s a design problem, one with a solution, and the organizations that close it earliest will compound that advantage in ways that are difficult for competitors to replicate quickly.
There are four key recommendations to keep in mind.
Stop treating strategy, architecture, and delivery as sequential phases with a handoff between them
The handoff model — strategy sets direction, architecture translates it, delivery implements it — is where fidelity is lost. The translation’s not a one-time event; it’s a continuous process that needs its own infrastructure. A living capability registry, a journey composition layer, and a traceability chain from objective to service aren’t overhead, they’re the infrastructure of strategic execution.
The path to connecting strategy with technology execution is more concrete than most organisations realize
It doesn’t require a multi-year transformation program or a ground-up architectural rewrite. It requires a shared vocabulary (a capability taxonomy your business and technology teams both recognize), a composition mechanism (so that product teams build journeys from registered capabilities rather than from first principles every time), and a traceability layer (so that every service deployed can be traced back to the strategic objective it serves). These three things can be built incrementally, starting with one business unit and one domain, and scaled as confidence grows.
As an executive, your most important job in this context is not to mandate the platform — it is to make the question visible
When your leadership team cannot answer "which capabilities are delivering our growth strategy, and are they fit for the task?" in a single conversation, that is a governance gap worth closing. When a service degrades and nobody can immediately tell you which customer journeys and strategic objectives are at risk, that’s an information architecture gap worth closing. The platform described in this article is the mechanism for closing both, but the executive who creates the demand for that visibility is the one who makes it happen.
The teams doing the daily work of building, operating, and governing technology need to feel the connection between what they do on a given Tuesday and what the organization is trying to achieve over the next three years
That connection isn’t made by publishing a strategy deck, it’s made when a product owner can see, in the tool they use every day, that the journey they are composing serves a Tier 1 strategic objective; when an engineer can see that the service they’re deploying is a registered capability that two business units are depending on; when a risk officer can see, in real time, that a degraded service is creating exposure against a regulatory commitment. The platform makes the connection visible at the moment it matters — not at the next quarterly review.
The connection that composes everything
The strategy-execution gap is not a mystery, and it is not inevitable. It’s a predictable consequence of a specific structural absence: the enterprise has no institutional mechanism that translates between the language of strategy and the language of delivery — continuously, traceably, and at the fidelity required to govern a complex technology estate.
The organizations that close this gap first do not just deliver their current strategic objectives more reliably. They develop an organizational capability — the ability to answer, in real time, whether what they are building is connected to what they are trying to achieve — that compounds over time. Every capability registered makes the next composition faster. Every journey approved makes the next reuse more likely. Every gap surfaced and funded makes the estate more collectively exhaustive. The platform builds on itself.
For the teams on the ground, this matters because it closes the distance between the work they do on a given day and the reason it matters. When an engineer deploys a service and it automatically registers as a capability serving a strategic objective, the connection between Tuesday's deployment and the company's three-year ambition is not theoretical — it’s traceable, visible, and acknowledged. When a product owner composes a journey and the platform tells them that their work’s advancing a Tier 1 strategic bet, strategy isn’t something that happens to them from above. It’s something they’re directly and demonstrably contributing to.
For executives, the platform changes the quality of the questions they can ask. Not "are we on track?" — a question that produces status reports — but "which capabilities are at risk of preventing us from delivering our growth strategy?" and "where do we have genuine gaps that need investment this quarter?" These are the questions that reveal whether an organization is in control of its strategic execution or merely managing the appearance of it.
The enterprises that will lead their sectors over the next decade are not necessarily those with the best strategies or the most engineering talent. They are the ones that build the connective tissue between the two — making strategy traceable to delivery, making delivery visible to strategy, and making the gap between intent and execution something that can be seen, governed and systematically closed.
That connective tissue is the platform. And the time to build it is now.