Fractured: Bridging the Chasm Between Enterprise and Solution Architecture

Everybody has a plan

Mike Tyson once observed that "everybody has a plan until they get punched in the face." It is an unexpectedly apt metaphor for what happens to enterprise architecture strategies when they encounter the realities of delivery.

In professional boxing, a fighter's corner comprises strategists — coaches, analysts, physiologists — who prepare a comprehensive plan. But when the bell rings, it is the fighter alone in the ring, adapting in real time to an opponent who has no obligation to cooperate with the plan. The best corners are those that remain actively engaged throughout the fight: reading the conditions, adjusting tactics between rounds, and ensuring the strategy evolves with the reality unfolding in front of them.¹

Enterprise architecture and solution architecture should work exactly this way. Enterprise architects are the strategists — formulating the vision, defining the target state, mapping capabilities, and establishing the principles that guide technology investment. Solution architects are the tacticians — translating that strategy into deliverable designs, navigating the constraints of real platforms, real budgets, and real stakeholders, and making the hundreds of implementation decisions that determine whether the strategy actually materialises.

In too many organisations, these disciplines operate in isolation. The strategists prepare a plan and hand it over. The tacticians enter the ring alone. The plan, unsurprisingly, does not survive contact with reality.

Why the chasm persists

The separation between enterprise and solution architecture is not new, and it is not accidental. It persists because several reinforcing factors make it structurally difficult to close.

Enterprise architecture struggles to demonstrate value

Enterprise architecture practices often find it difficult to quantify their contribution in terms that resonate with business leadership. When the value proposition is expressed in terms of framework compliance, reference model completeness, or roadmap coverage, it becomes abstract — and abstract functions are the first to be marginalised when budgets tighten. Solution architects, by contrast, are directly attached to funded delivery programs with measurable outcomes. The asymmetry in perceived value reinforces the separation.

Frameworks address strategy but not the handoff

Major architecture frameworks — TOGAF, FEAF, DoDAF — provide comprehensive guidance for architecture development and governance at the enterprise level. But they tend to treat the interface between strategic architecture and solution delivery as a boundary condition rather than a discipline in its own right. TOGAF's Architecture Development Method (ADM), for example, provides a robust cycle for developing and governing enterprise architecture, but the mechanisms for ensuring that solution-level decisions remain aligned with enterprise intent during the turbulence of delivery are less prescriptive.²

Enterprise architects lack delivery experience

A persistent pattern in the profession is that enterprise architecture roles attract practitioners who are drawn to strategic thinking but may have limited recent experience in delivery. When an enterprise architect has not faced the commercial pressures, stakeholder dynamics, and technical constraints that shape solution-level decisions, their plans — however sound in principle — can be disconnected from the realities that solution architects navigate daily. The credibility gap this creates is corrosive: solution architects learn to treat enterprise architecture artefacts as aspirational documents rather than actionable guidance.

Solution architects lack strategic context

The inverse is equally damaging. Solution architects who are embedded exclusively within delivery programs often lack visibility of the broader enterprise context — the capability roadmaps, integration dependencies, and strategic trade-offs that should inform their design decisions. Without this context, they optimise locally: making decisions that serve the immediate program but may conflict with, or constrain, enterprise-level objectives. Neither party is at fault individually. The dysfunction is structural.

The counter-argument: is the chasm even a problem?

There is a credible counter-position that deserves consideration. The agile architecture movement, and frameworks like SAFe, argue that the traditional separation between upfront planning and iterative delivery is itself the problem — and that the solution is not to bridge the gap between strategists and tacticians, but to dissolve the distinction altogether.

SAFe's concept of "Agile Architecture" explicitly advocates for "a set of values, practices, and collaborations that support a system's active, evolutionary design and architecture."³ In this model, architecture is not a phase that precedes delivery, nor a separate function that governs it — it is an embedded, continuous activity within delivery teams. Enterprise architects build "just enough Architectural Runway" to support near-term delivery, rather than comprehensive target-state blueprints.

The evolutionary architecture thesis advanced by Ford, Parsons, and Kua reinforces this view: architecture should support "guided, incremental change as a first principle," with fitness functions replacing governance boards as the mechanism for ensuring architectural qualities are maintained over time.⁴

These are not marginal perspectives. They reflect the operational reality of many successful technology organisations, particularly those operating at scale with high rates of change. And they raise a legitimate question: if the chasm exists because the roles are defined as separate, perhaps the answer is to stop defining them as separate.

The limitation of this argument is one of context. Evolutionary architecture and embedded agile practices work well in organisations with high engineering maturity, strong platform foundations, and relatively homogeneous technology stacks. In the complex, heterogeneous enterprise environments that most large organisations operate — spanning legacy systems, multiple vendors, regulatory constraints, and business units with competing priorities — the strategic coordination function that enterprise architecture provides is not easily dissolved into delivery teams. The question is not whether strategic architecture should exist, but how it should engage with delivery so that strategy and execution reinforce each other rather than operating in parallel.

Closing the gap

Bridging the chasm requires deliberate action across three dimensions: how architecture teams work together, the resources they share, and the processes that connect them.

Teaming: embed, don't hand off

Enterprise architects should spend meaningful time embedded within delivery programs — not as governance observers, but as active participants who understand the constraints, trade-offs, and stakeholder dynamics that shape solution decisions. This is not a token "review and approve" engagement; it requires sustained presence and genuine collaboration.

Equally, solution architects should be regularly engaged in strategic planning activities — capability modelling, roadmap development, technology evaluation — so that they carry enterprise context into their delivery work. The boxing metaphor holds: the best corners are those where the strategists remain committed to the fighter as much as the fighter is committed to the plan.

Team composition matters too. The instinct is to select architects for technical depth alone, but the skills that bridge the chasm are relational: emotional intelligence, stakeholder engagement, the ability to communicate technical trade-offs in business terms, and the willingness to treat practitioners in the other discipline as peers with distinct and equally valuable expertise.

Resources: make strategy usable

Enterprise architecture artefacts — reference models, capability maps, technology roadmaps, architecture principles — have value only if they are accessible, current, and usable by solution architects in the context of delivery decisions. Too often, these artefacts exist in presentation decks or modelling tools that are disconnected from the environments where solution-level decisions are made.

Structured, searchable repositories with clear provenance and version control are table stakes. Beyond tooling, the content itself must be designed for consumption by practitioners who need actionable guidance, not comprehensive documentation. A reference architecture that helps a solution architect evaluate a vendor proposal is more valuable than one that comprehensively describes the target state but cannot be applied to a specific decision.

Processes: create feedback loops

The most damaging aspect of the chasm is that it is self-reinforcing: enterprise architects plan without delivery feedback, producing artefacts that are disconnected from reality; solution architects deliver without strategic context, making decisions that erode the enterprise vision; and neither discipline has a structured mechanism to learn from the other.

Closing the gap requires formal, recurring feedback loops — not governance checkpoints, but genuine two-way exchanges where solution architects inform strategy with delivery realities, and enterprise architects inform delivery with strategic context. This includes active risk management: when a delivery decision threatens an enterprise outcome, the escalation path should be clear, timely, and lead to a genuine assessment rather than a rubber-stamp approval.

As James Coplien noted in his work on lean architecture, "while we must acknowledge emergence in design and system development, a little planning can avoid much waste."³ The goal is not to choose between strategy and emergence, but to ensure they are in continuous dialogue.

Strategy that survives the ring

The measure of an architecture practice is not the quality of its plans — it is the degree to which those plans survive contact with delivery and produce the outcomes the organisation invested in achieving. Enterprise architects who hand over a strategy and step back are not strategists; they are document authors. Solution architects who deliver without strategic context are not tacticians; they are technicians solving the problem in front of them without reference to the war being fought.

Bridging the chasm does not mean eliminating the distinction between strategic and tactical architecture. It means ensuring that both disciplines operate as parts of a single, coordinated capability — with the teaming, resources, and processes that keep strategy grounded in reality and delivery aligned with intent. The organisations that achieve this will find that their architecture plans do not merely survive the ring — they improve through the fight.