The Enterprise Architecture Deliverables Worth Producing

Key Takeaways

• The six recurring EA deliverables are strategy, current-state assessment, target-state architecture, the architecture blueprint, the transformation roadmap, and standards/guidelines.
• A deliverable earns its keep when it changes a decision — a budget line, a build-vs-buy call, a sequencing choice — not when it documents everything in exhaustive detail.
• Current-state assessments fail most often by describing systems in isolation instead of scoring them against cost, risk, and business value.
• Roadmaps that mix a few near-term, visibly finishable initiatives with the multi-year structural ones keep sponsors engaged; roadmaps that are all multi-year initiatives lose sponsors by month six.
• Standards documents that carry no exception process get either ignored or become a source of shadow IT; the exception process is what makes a standard enforceable.
• Every deliverable needs a named owner and a review cadence, or it decays into a document that was accurate the day it was published and increasingly wrong after.

Architecture Strategy: The Document That Should Get Argued About

Before any diagram gets drawn, the architecture strategy sets out how the practice will operate and what it's optimizing for.

The architecture strategy states the principles the practice will apply — how much standardization to enforce, where flexibility is allowed, how security and data governance factor into every other decision. It names the framework the practice will lean on, whether that's TOGAF's Architecture Development Method, a lighter homegrown process, or a hybrid. And it sets the governance model: who approves an architecture decision, who can grant an exception, and what happens when a project team disagrees with the architecture team. Most strategy documents fail for the same reason: they read as aspirational statements nobody would object to ("we will pursue business-IT alignment") rather than choices with tradeoffs. A strategy that says "we will standardize on a single case management platform even where it costs more upfront, because integration savings outweigh license cost" gives a project team something concrete to push back on or follow. A strategy that says "we value alignment and agility" gives them nothing to act on. If your strategy document hasn't generated a disagreement in its first six months, it's likely too vague to matter.

• Principles that state a tradeoff, not just a value (what you're willing to give up, not just what you want)
• A named framework or method, tailored rather than adopted wholesale
• A governance model: who decides, who can appeal, who can grant exceptions
• The tools and repositories the practice will maintain as the system of record

Current-State Assessment: More Than an Inventory

A current-state assessment that only lists what exists is a spreadsheet, not an architecture deliverable.

The baseline documents applications, data stores, integrations, and infrastructure as they exist today — but the version that gets used adds a judgment layer on top of the inventory: which systems are expensive to run relative to the business value they deliver, which carry concentrated technical risk, which are duplicated across business units, and which are quietly load-bearing despite looking unimportant on an org chart. That judgment layer requires talking to the people who run the systems, not just querying a CMDB. Interviews surface the workarounds, the manual patches, and the one person who understands the integration that nobody has touched since it was built. A current-state assessment that skips this and relies purely on automated discovery tools will be technically accurate and strategically useless — it won't tell anyone which of the ten aging systems to fix first.

• Application inventory scored on cost-to-run against business value delivered, not just listed
• Technical debt flagged by what it blocks (a planned initiative, a compliance deadline) rather than by age alone
• Concentration risk: single points of failure, single people who understand a system, single vendors with no alternative
• A baseline that's dated and versioned, because "current state" has a shelf life measured in months, not years

Target-State Architecture: Specific Enough to Be Wrong

The future-state vision has to be concrete enough that someone could point out where it's mistaken.

A target-state architecture describes where the organization's capabilities, applications, and technology are headed, and it has to do more than gesture at direction. "Move to the cloud" is not a target state. "Consolidate order management onto a single platform, retire the two legacy systems it replaces, and expose order status through a common API layer other channels can call" is a target state — someone can look at it and say it's wrong, too aggressive, or missing a dependency, which is exactly the reaction a useful deliverable should provoke. Building it requires the same people who'll have to live with it: the business owners whose processes will change, the engineering leads who know what's actually replaceable, and whoever owns the budget. Skip any of the three and the target state either won't get funded, won't get built as designed, or will get quietly redesigned mid-project by the people who weren't consulted. None of that makes the vision wrong to have — it makes the vision wrong to have without their input.

• A target operating model stating which business capabilities the organization will run differently
• A conceptual architecture naming systems and integration points, not just describing categories of technology
• Explicit tradeoffs called out — what gets retired, what gets consolidated, what stays as-is on purpose
• A revisit cadence, since the target state that was right eighteen months ago may not survive a market shift or an acquisition

The Blueprint: One Picture, Several Audiences

The architecture blueprint is the single diagram (or connected set of diagrams) that shows how business, data, application, and technology layers relate.

Where the current-state and target-state deliverables are detailed working documents, the blueprint is the summary view — the thing an executive glances at in a steering committee meeting to understand how a proposed change ripples through the rest of the environment. It typically layers a business capability map, an application portfolio view, a technology infrastructure diagram, and a data flow model into one connected picture, with enough detail to be useful and not so much that it becomes illegible. The practical failure mode here is over-density: architects who've spent months on a domain understandably want every relationship represented, and the result is a diagram that takes a specialist twenty minutes to parse. A blueprint that a business sponsor can't explain to their own team after one walkthrough isn't communicating anything — it's demonstrating effort. Separate blueprints for separate audiences (an executive summary view, a detailed working view for architects) usually serve better than one diagram trying to do both jobs.

• Business capability map showing core functions, not org units
• Application portfolio view highlighting what talks to what
• Technology infrastructure diagram at a level a non-specialist can follow
• Data flow model tracing information across system boundaries

The Transformation Roadmap: Sequencing Is the Deliverable

A roadmap's value is almost entirely in the sequencing decisions it makes explicit, not in the list of initiatives it contains.

Any current-state-to-target-state gap can be closed by dozens of possible initiatives. The roadmap earns its place as a deliverable by deciding — and defending — the order: what has to happen before something else can start, what delivers value on its own versus what only pays off once three other pieces are in place, and where the organization's actual capacity (budget, staffing, change tolerance) caps how much can run in parallel. Roadmaps that skew entirely toward multi-year structural initiatives lose sponsor attention within a couple of quarters, because there's nothing to point to as done. Roadmaps that are all quick wins never touch the harder structural debt driving the problem in the first place. The versions that hold up mix both deliberately: a handful of initiatives that can visibly finish inside the first year, sequenced alongside the longer initiatives they help fund or justify.

• Initiative sequencing driven by real dependencies, not by which team asked first
• A mix of near-term, visibly finishable work and longer structural initiatives
• Resourcing and budget shown against the same timeline, not in a separate document
• Named milestones with a clear definition of done, not just target dates

Standards and Guidelines: Rules With an Exception Path

Standards documents govern how architectural components get built and used across the enterprise — and they only work if there's a legitimate way around them.

Standards cover data management conventions, approved technology platforms, integration patterns, and security requirements. Done well, they reduce the number of one-off decisions a project team has to make from scratch and keep the environment from fragmenting into dozens of incompatible approaches to the same problem. The part teams skip is the exception process — a documented way for a project to deviate from a standard when the business case is strong enough, with a named approver and a clear bar for what counts as sufficient justification. Without it, standards get enforced unevenly: project teams that ask permission wait weeks for an answer, while teams that don't ask just build around the standard and nobody notices until the audit. A standard without an honest exception path isn't governance — it's a suggestion that inconveniences whoever follows it.

• Technology platform standards naming approved options, not just principles
• Integration patterns for how systems are allowed to talk to each other
• Data governance rules tied to actual compliance requirements
• A documented, timely exception process with a named approver

Frequently Asked Questions

Q: What's the single most important EA deliverable? A: There isn't one — a target-state architecture with no current-state baseline to measure against is a wish list, and a roadmap with no target state is just a list of projects. The strategy, current state, and target state have to exist together before the roadmap can be trusted. Q: How often should these deliverables be updated? A: Current-state assessments and roadmaps need the most frequent attention — every planning cycle, at minimum annually, because they describe things that change. Strategy and standards can hold for longer, but should still get a scheduled review rather than sitting untouched for years. Q: Who should own each deliverable? A: Each one needs a single named owner accountable for keeping it current, even if multiple people contribute. Shared ownership across a whole team is how deliverables quietly go stale — everyone assumes someone else is updating it. Q: Do smaller organizations need all six deliverable types? A: The substance matters more than the format. A ten-person IT shop doesn't need a formal governance board, but it still benefits from writing down its current state, its direction, and its near-term sequencing — even in a shared document rather than a dedicated tool. Q: What's the fastest way to tell if a deliverable is actually being used? A: Ask when it was last cited in a real decision — a budget approval, a build-vs-buy call, a project kickoff. If nobody can point to a specific instance in the last quarter, the deliverable is decoration.

Pro Tips

• Write deliverables to be argued with, not agreed with — a document that provokes no pushback usually isn't specific enough to guide a decision.
• Interview the people who actually run a system before you score it in a current-state assessment; automated discovery tools miss the workarounds that matter most.
• Put at least a few visibly finishable initiatives in year one of any roadmap, even small ones — sponsors disengage from plans where nothing completes for eighteen months.
• Give every standard a real exception process with a named approver; a standard nobody can legitimately deviate from just gets quietly ignored instead.