Business Architecture Fundamentals

Business Architecture is the domain of EA that defines the enterprise in business terms: what it does (capabilities), how it delivers value (value streams), who is accountable (organisation), and why it behaves as it does (motivation). It is the domain that anchors every other — data, application, and technology architecture all serve capabilities and value streams.

Too often dismissed as 'process maps', business architecture is far more. Its core artifact, the capability map, is arguably the most reusable asset in the entire EA because capabilities are remarkably stable even as strategy, organisation, and technology change continuously. A retailer's 'Order Fulfilment' capability has persisted for a century even as its execution moved from paper to web to mobile to AI.

This page covers the core artifacts of business architecture, the capability-based planning approach that connects it to strategy, and how business architecture anchors the rest of the EA.

The Business Architecture Guild's BIZBOK (Business Architecture Body of Knowledge) identifies a core set of artifacts. The three foundational ones are the capability map, the value stream map, and the organisation map. Around these orbit supporting artifacts: the information map, the strategy map, the business motivation model, and the value stream-to-capability cross-mapping.

Each artifact answers a different question. The capability map answers 'what does the enterprise do?'. The value stream map answers 'how does it deliver value to a stakeholder?'. The organisation map answers 'who is accountable for what?'. Together they form a coherent, mutually reinforcing description of the business — the basis on which data, application, and technology architecture are built.

A business capability is what a business does — an ability the enterprise possesses to achieve a specific purpose or outcome. Crucially, a capability is abstracted from how it is performed: the same capability ('Customer Onboarding') may be executed differently across business units, geographies, or eras, yet remain the same capability. This abstraction is what makes the capability map the most durable and reusable artifact in EA.

Capabilities are typically organised in a hierarchy: level 1 (strategic capabilities), level 2 (core capabilities), level 3 (detailed capabilities), and optionally level 4 (sub-capabilities). The discipline is to keep the top two levels stable and strategy-agnostic, so the map does not need rebuilding with every strategy refresh.

Each capability is enriched with metadata: its maturity, its strategic importance, the value streams it supports, the applications that enable it, and the data it consumes. This enrichment is what turns a static map into a decision tool — 'which capabilities are underinvested?' becomes a query, not a debate.

A value stream is an end-to-end set of activities that an organisation performs to deliver a valuable result to an external or internal stakeholder. Where capabilities describe 'what we can do', value streams describe 'how we combine capabilities to deliver an outcome' — for example, 'Acquire Customer' or 'Resolve Customer Complaint'.

Each value stream is decomposed into stages, and each stage maps to the capabilities that enable it. This value stream-to-capability mapping is one of the most powerful artifacts in EA: it shows, for any outcome the business cares about, exactly which capabilities are involved and where the weak links are.

Value streams are also the bridge to customer experience and process management. When a CX team maps a customer journey and an EA team maps the enabling value stream, the two fit together like puzzle pieces — and the enterprise can finally see, end to end, how a customer experience is delivered by a chain of capabilities.

Capability-based planning is the practice of planning investment, projects, and roadmaps against the capability map rather than against projects or org charts. Its power is that it makes the 'what' explicit before the 'how', forcing every investment to answer 'which capability does this build, and is that capability strategic?'.

This approach resists the most common failure mode of transformation portfolios: funding many projects that each seem sensible but collectively leave strategic capabilities underfunded and non-strategic capabilities over-served. With a capability view, the portfolio can be rebalanced toward the capabilities that matter most.

Capability-based planning also enables heat-mapping: plotting capability maturity against strategic importance to reveal where the enterprise is weakest where it most needs to be strong. These heat maps are among the most decision-shaping artifacts an EA can produce.

Business architecture earns its keep by anchoring the other domains. The capability map is the join key: every application should map to at least one capability it enables, every data domain to capabilities it serves, every technology platform to capabilities it underpins. When these mappings exist, the EA can answer questions that would otherwise require months of investigation.

This anchoring is also what makes business architecture the natural home of impact analysis. When a regulation changes ('PCI DSS v4 affects card data handling'), the business architect traces from the affected capabilities to the value streams, applications, and data — producing an actionable scope in days rather than a vague 'this affects many systems'.

In the AI era, business architecture is also where AI use-cases are anchored: each candidate AI capability is mapped to the business capability it enhances and the value stream stage where it intervenes. This is what keeps AI investment tied to business outcomes rather than technology curiosity.

Building a capability map is a collaborative exercise, not a desk job. The most credible maps are built in workshops with business owners, validated against strategy, and kept deliberately shallow at first (levels 1–2) before deepening. A common failure is to over-detail early, producing a map no one recognises or owns.

Maintenance is where most capability maps die. Without a named owner, a review cadence, and a clear change process, the map drifts from reality and loses credibility. The fix is to treat the map as a governed product: owned by the EA function, reviewed quarterly with business owners, and version-controlled so changes are deliberate.

Tools help — from dedicated EA suites to structured spreadsheets — but the discipline is human. The most important question to ask of any capability map is not 'is it complete?' but 'does the business recognise itself in it?'.