The Core Business Architecture Deliverables, and How They Fit Together

Key Takeaways

• No single business architecture deliverable is self-sufficient; a capability map, value stream map, organization map, and information map each answer a different question and need each other to produce a decision.
• Cross-mapping, capability against value stream, capability against application, capability against organization, is where a business architecture practice earns its keep, not the individual diagrams themselves.
• A deliverable that isn't reviewed on a regular cadence and tied to a real decision, a budget cycle, a transformation initiative, goes stale within a year regardless of how well it was built.
• Deliverables need business ownership and business language, not just architectural rigor; a technically correct map that the business doesn't recognize as describing itself won't get used.
• Building every deliverable to the same level of detail wastes effort; a capability map usually needs less depth than a value stream map of the same business, because the two are answering different kinds of questions.

Capability Map: What the Business Can Do

The capability map is usually the first deliverable a business architecture practice builds, and the one most often mistaken for the whole discipline.

A capability map is a structured inventory of what the organization needs to be able to do, independent of who does it or what technology supports it today. Built well, it stays valid across reorganizations and system migrations because it describes ability, not structure. Its main use is as a stable reference point: for portfolio decisions, for heat mapping maturity and strategic importance, and as the anchor other deliverables get cross-mapped against. What it doesn't do on its own is show how value actually flows through the organization, or who's accountable for keeping any given capability healthy. Those are separate questions, answered by separate deliverables.

Value Stream Map: How Value Actually Moves End to End

Where a capability map describes what the business can do, a value stream map describes how those capabilities get sequenced to deliver an outcome a customer or stakeholder actually cares about.

A value stream map traces the end-to-end path from a triggering event, a customer places an order, a patient is admitted, a claim is filed, through to the value delivered at the end. It exposes handoffs between capabilities and, often, between departments, which is exactly where delay and rework tend to concentrate in most organizations. Unlike a detailed process map, a value stream map usually stops at one level of decomposition, the major stages, rather than every step, keeping it readable as a single artifact rather than a sprawling flowchart. Because it's built around an outcome rather than an organizational unit, a value stream map is often the artifact that first makes cross-departmental inefficiency visible to people who've only ever seen their own piece of the process.

Organization Map: Who's Accountable

An organization map connects the capabilities and value streams to the people and roles actually accountable for them today.

This is not simply an org chart. An org chart shows reporting lines; an organization map, in the business architecture sense, shows which roles or units are accountable for which capabilities and value stream stages, which is a different and more useful question when the goal is figuring out where a gap or an overlap in accountability actually sits. It's also where the single-owner principle from capability modeling gets tested against reality: if no role on the organization map is clearly accountable for a capability, that's a finding, not a formatting problem.

Information (or Concept) Map: What Data the Business Depends On

An information or concept map inventories the core business concepts and data entities the enterprise relies on, described in business terms rather than database schema.

This deliverable answers a narrower but persistent question: what does Customer mean here, and is it the same thing across every system and department that uses the word? Large organizations frequently discover, once this map gets built, that three different systems have three different definitions of something as basic as an active customer, and that inconsistency is quietly breaking reporting, analytics, or customer service without anyone having previously named it as an information architecture problem rather than a data quality problem.

Cross-Mapping: Where the Real Insight Comes From

Each deliverable read alone is a description. Laid against another deliverable, it starts producing findings.

Capability mapped against value stream shows which capabilities carry the most weight in delivering customer value, and which ones show up nowhere in any value stream, a sign they may be misdefined or no longer needed. Capability mapped against organization shows where accountability is missing or duplicated. Capability mapped against the application portfolio shows where multiple systems are propping up a single capability, a common and expensive redundancy, or where a strategically important capability is running on aging technology nobody has flagged as a risk.

• Capability x value stream: which capabilities matter most to customer outcomes, and which show up in no value stream at all
• Capability x organization: where accountability for a capability is missing, split, or duplicated across units
• Capability x application portfolio: where a single capability depends on redundant systems, or a critical capability sits on outdated technology
• Value stream x information map: where inconsistent data definitions are quietly breaking a value stream's handoffs

Keeping Deliverables Alive After the Workshop Ends

The deliverables above are only as useful as the discipline behind updating them.

A deliverable built once for a single steering committee presentation and never revisited becomes decorative within a year; the organization keeps changing and the artifact doesn't. Deliverables that survive tend to share a few habits: a named owner for each artifact, a review cadence tied to an existing calendar, budget planning, portfolio review, rather than an ad hoc architecture forum, and a standing expectation that the deliverable gets consulted before a relevant decision, not produced after the decision's already been made to justify it retroactively.

Frequently Asked Questions

Q: Which business architecture deliverable should a team build first? A: Most practices start with the capability map, because it's the most stable reference point and the one other deliverables get cross-mapped against. It's not the most important deliverable on its own; it's the one that makes the others more useful once they exist. Q: How detailed should a value stream map be? A: Detailed enough to show the major stages and the handoffs between them, typically one level of decomposition, without going down to a full step-by-step process map. A value stream map that tries to show every task loses the end-to-end view that makes it useful in the first place. Q: Is an organization map the same as an org chart? A: No. An org chart shows reporting relationships. An organization map, in the business architecture sense, shows which roles or units are accountable for specific capabilities and value stream stages, which is a distinct and generally more decision-relevant view. Q: Why does an information map matter if the business already has a data dictionary? A: A data dictionary usually describes fields inside a specific system. An information map describes core business concepts, like what counts as an active customer, at the business level, independent of any one system, which is what surfaces inconsistencies between systems that a single system's data dictionary can't reveal. Q: How often should business architecture deliverables be updated? A: On a cadence tied to an existing planning or portfolio review cycle, not an arbitrary schedule. A deliverable that's only updated when someone happens to remember tends to fall out of sync with the organization within a year.

Pro Tips

• Build the capability map and organization map together, or close together, rather than the capability map alone. Accountability gaps are much easier to spot when both artifacts are on the table at once.
• Don't aim for uniform depth across every deliverable. A capability map usually needs less detail than a value stream map of the same business; forcing both to the same level of decomposition wastes effort on the one that doesn't need it.
• Pick one cross-mapping exercise, capability against application portfolio is usually the fastest to produce a concrete finding, and run it before trying to complete every deliverable in full. A partial cross-map that produces a real decision beats a complete set of maps that sits unused.