An architecture team produces a detailed, framework-conformant target-state document, but when they present it to the executive steering committee, the executives can't tell from it what business risk is being reduced or what budget decision they're being asked to make. What likely went wrong, and how would you fix it?

## The communication problem every framework hits Every EA framework that's been used at scale eventually has to solve the same communication problem: the people who need to authorize a decision (executives, a steering committee) are not the people who need to implement it (engineers, technical architects), and they need fundamentally different information to do their job. A framework's notion of 'viewpoints' or 'perspectives' exists precisely to force this separation explicitly rather than leaving it to whoever happens to be writing the document that week. In practice, this means the architecture repository should contain, for a given decision or system, more than one deliverable: - a **detailed, structurally accurate artifact** (data models, system diagrams, integration specs) for the people building or maintaining the thing; - a **distinct, much shorter artifact** for the people deciding whether to fund or approve it, stated in terms of business risk, cost, and choice, not technical structure. When a team produces only the former and expects it to also serve the latter audience, the executive committee is being asked to extract a decision from a document that was never designed to communicate one. ## Why teams fall into it Why this happens, and the problem it solves: architects, left to their own preferences, tend to default to the artifact type they find most natural to produce - usually the detailed technical one, because that's the artifact that actually captures the engineering reality they're managing day to day. Producing a genuinely separate executive artifact takes additional effort with no direct engineering payoff, so it's the deliverable most likely to be skipped or done as an afterthought - a slide deck thrown together the night before the steering committee meeting, mechanically copying diagrams from the technical document rather than reframing the content around the actual business question. The framework's discipline - explicitly requiring different deliverable types for different audiences as a first-class practice, not an optional nicety - exists specifically to counteract that default. ## What the second artifact costs Trade-offs: producing a genuinely audience-appropriate executive deliverable costs real time. It's not just a shorter version of the technical document; it requires translating technical risk into business terms, which often means the architect needs input from a business stakeholder to correctly characterize the cost of inaction in terms the executive audience cares about (revenue risk, compliance exposure, customer impact) rather than in terms the architect finds most natural (technical debt, coupling, latency). Skipping this translation is cheaper in the short term but produces exactly the failure in the scenario: decisions don't get made, or get made on ad hoc verbal explanation rather than the actual documented artifact, which erodes the value of maintaining the architecture repository at all, since the repository isn't actually driving the decisions it exists to support. Overcorrecting the other way - producing only glossy executive summaries with no underlying detailed artifact - creates a different failure: decisions get approved based on an oversimplified picture, and the technical team later discovers the approved plan didn't account for a real constraint that only would have surfaced in the detailed artifact. ## Failure modes in production Failure modes in production: 1. The most common variant of this failure is the **'single artifact, multiple audiences' anti-pattern** - one document gets reused unchanged for both technical review and executive approval, and it satisfies neither audience well: too detailed and jargon-heavy for executives to extract a decision, too summarized and hand-wavy for engineers to actually build from. 2. A related failure is **producing the executive artifact but disconnecting it from the technical one**, so the numbers or timeline in the executive summary silently diverge from what the detailed technical plan can actually support - the executive approves a budget based on a summary that was optimistically simplified, and the technical team later has to explain a shortfall against a commitment they never actually validated. 3. A third failure is producing the right artifact types but **the wrong cadence** - refreshing the detailed technical artifacts continuously as engineering reality changes, while letting the executive-facing artifact go stale, so leadership is making decisions off information that's a year out of date even though the underlying technical documentation is current. ## A worked example and its fix Concrete example: a retail company's architecture team produced a thorough, framework-conformant target-state document for consolidating three separate order-management systems into one, full of data-flow diagrams and integration specs, and presented that same document to the executive steering committee asking for migration budget. The committee couldn't determine from it: - which of the three current systems posed the greatest operational risk if left unconsolidated; - what the migration would cost in dollars versus what the status quo was costing in duplicated support effort; - what decision they were actually being asked to make versus simply being informed. The fix the team applied was to produce a **one-page decision brief** - three systems, estimated annual cost of maintaining each, quantified support-ticket volume as a risk proxy, and a specific dollar ask tied to a specific timeline - as a distinct deliverable explicitly derived from, but not identical to, the detailed technical document, and steering-committee approval followed within one meeting cycle once that artifact existed.