Business Architecture Domain Module

Connecting strategy to delivery.

Business Architecture is where strategy meets structure. It translates organisational intent into something technology teams can actually work with — capability models that show what the organisation does, value streams that show how it creates outcomes, and the traceability that connects business priorities to technology investment.

Most organisations have a gap between what leadership says matters and what technology actually gets built. Business Architecture, done right, closes that gap. Done poorly, it produces pretty pictures that nobody uses.

This module provides the practical foundation for business architecture that connects to real delivery decisions.

What This Module Provides

How It Plugs Into the Governance Core

Business Architecture doesn't operate in isolation. It connects to every component of the Governance Core:

Guardrails Framework — Strategic guardrails come from business architecture. What capabilities are we investing in? What are we divesting from? These become the boundaries within which technology decisions happen.

Decision Records — When a decision touches strategic capabilities or value streams, the business architecture context gets captured. "We chose this approach because it supports the Customer Experience capability investment."

Architecture Passport — Each system's passport includes which capabilities it supports and which value streams it enables. This makes the business relevance of technology visible.

Tiered Oversight — Business criticality is a key factor in determining oversight tier. Systems supporting strategic capabilities or customer-facing value streams typically warrant higher scrutiny.

Technical Debt Register — Debt isn't just technical. When systems can't support capability evolution or value stream improvement, that's business-architecture debt that needs visibility.

Architecture Registry — This module populates the business layer of your registry: capabilities, value streams, organisational mapping, and the relationships between them.

Core Artefacts

Capability Model

Business capabilities describe what the organisation does, independent of how it's currently done. They're stable over time — "Manage Customer Relationships" remains a capability even as the CRM system changes.

Why it matters: Capabilities provide the vocabulary for business-technology conversation. "We're investing in Customer Experience" becomes tangible when you can point to specific capabilities and ask "which of these need improvement?"

Structure

A capability model is hierarchical, typically three levels:

• Level 1: Major business areas (5-10 for most organisations)
• Level 2: Functional groupings within each area (3-7 per L1)
• Level 3: Specific capabilities (3-7 per L2)

The right level of detail depends on your context. Start at L2 — enough to be useful, not so detailed you're drowning in maintenance.

Key fields per capability:

Capability heat mapping shows where investment is needed. Overlay strategic importance against current maturity — capabilities that are strategically important but poorly delivered are your investment priorities.

Project vs Product Operating Models

The capability model works in both contexts, but the conversation differs:

For government and traditional enterprises running project-based funding, capability models translate strategic intent into investable chunks. The business case becomes: "We're investing $X to improve these specific capabilities from current state to target state."

For organisations running product models, capabilities help define product scope and prevent overlap. Each product team knows which capabilities they're accountable for.

Value Streams

Value streams show the end-to-end flow of activities that deliver outcomes — from trigger to value realised. Unlike processes (which show how work is done), value streams show what value is created and where.

Why it matters: Value streams reveal where friction exists. They expose handoffs, delays, and pain points that capability models alone don't show. When someone asks "why does it take three weeks to onboard a customer?", the value stream provides the answer.

Structure

A value stream has stages, each contributing toward the final outcome:

Value Stream Canvas (simplified)

┌─────────────────────────────────────────────────────────────────┐
│ VALUE STREAM: [Name]                                            │
├─────────────────────────────────────────────────────────────────┤
│ Trigger: [What initiates]  →  Outcome: [What's delivered]       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Stage 1      Stage 2      Stage 3      Stage 4      Stage 5   │
│   ┌─────┐      ┌─────┐      ┌─────┐      ┌─────┐      ┌─────┐   │
│   │     │ ──▶  │     │ ──▶  │     │ ──▶  │     │ ──▶  │     │   │
│   └─────┘      └─────┘      └─────┘      └─────┘      └─────┘   │
│                                                                 │
│   Capabilities: [List per stage]                                │
│   Pain Points:  [Where friction exists]                         │
│   Systems:      [What supports each stage]                      │
│                                                                 │
├─────────────────────────────────────────────────────────────────┤
│ Current Lead Time: [X days]    Target: [Y days]                 │
└─────────────────────────────────────────────────────────────────┘

Project vs Product Operating Models

In project-based environments, value streams help justify investment by showing end-to-end impact. A project that improves one stage can claim contribution to overall value stream performance.

In product environments, value streams prevent product teams from optimising locally at the expense of end-to-end flow. The value stream owner ensures products work together.

Product Mapping

For organisations running product operating models, product mapping connects products to the capabilities they own and the value streams they contribute to. Even project-based organisations increasingly deliver through product teams — making this relevant beyond pure product models.

Why it matters: Without clear product-capability mapping, you get capability overlap (multiple products doing the same thing), capability gaps (no product owns a critical capability), and value stream fragmentation (no one accountable for end-to-end flow).

Structure

Product-Capability Relationship Types

Why this matters for governance: When a capability needs investment, you know which product team owns it. When a value stream is underperforming, you can identify which products contribute to the problem stages. When products propose overlapping scope, capability mapping surfaces the conflict early.

Project vs Product Operating Models

For hybrid environments — common in government where funding is project-based but delivery increasingly product-oriented — product mapping bridges the gap. Projects deliver change; products own the outcome.

Business-Technology Traceability

This is where business architecture earns its keep. Traceability connects strategy to execution in a way that's auditable and actionable.

The Traceability Chain

Strategic Priority
       │
       ▼
Business Outcome
       │
       ▼
Capability Investment
       │
       ▼
Value Stream Improvement
       │
       ▼
Application/System Change
       │
       ▼
Technology Decision

Each link in the chain should be explicit. When someone asks "why are we investing in this system?", you can trace it back to the strategic priority it supports.

Traceability Matrix (simplified)

Why this matters for governance: When a project proposes technology changes, the traceability matrix shows what's at stake. Changes to systems supporting strategic capabilities get appropriate scrutiny. Changes to systems with no strategic linkage might question whether the investment should happen at all.

Strategic Guardrails

Strategic guardrails are the business architecture contribution to the Guardrails Framework. They define what the organisation is investing in, divesting from, and prioritising — keeping technology decisions aligned with where the business is actually heading.

What Strategic Guardrails Cover

• Capabilities the organisation is actively investing in
• Capabilities being sunset or divested
• Business outcomes that matter this planning cycle
• Strategic initiatives that technology must support
• Business domains where differentiation matters versus commodity

Example Strategic Guardrails

Guardrail Lifecycle

Strategic guardrails aren't permanent. They reflect current strategic context and should be reviewed at least annually, or when strategy shifts.

Populating the Architecture Registry

This module provides the content that populates the business layer of your Architecture Registry. If you've established the registry structure from the Governance Core but have empty business architecture sections, this is where the content comes from.

What goes in the registry:

Relationship integrity: The power of the registry comes from relationships. Every application should link to the capabilities it supports. Every value stream should link to the capabilities involved at each stage. Without these relationships, you have lists instead of architecture.

Minimum Viable Implementation

You don't need everything on day one. Here's a tiered approach to getting started:

Must Have (Week 1-2)

1. Strategic guardrails documented — Even a simple list of 5-10 statements about what the organisation is investing in and divesting from
2. Draft L1/L2 capability model — High-level capabilities that give you vocabulary for business-technology conversation
3. One value stream mapped — Pick your most painful or strategically important value stream and map it end-to-end
4. Basic traceability — For current initiatives, document which capabilities they impact

Add Early (Month 1-2)

1. Capability heat map — Strategic importance vs current maturity for L2 capabilities
2. Application-capability mapping — Which applications support which capabilities
3. Product mapping (if product model) — Which products own which capabilities
4. Additional value streams — Map the next 2-3 most important value streams
5. Strategic guardrail governance — Who owns them, how they're reviewed

Scale (Quarter 1-2)

1. L3 capability detail — Where needed for active investment areas
2. Full value stream portfolio — All significant value streams mapped
3. Maturity assessment process — Regular capability maturity reviews
4. Integration with planning cycles — Business architecture inputs to annual planning

Roles and Responsibilities

Business Architecture doesn't require a dedicated Business Architect role to start — but someone needs to own the artefacts and maintain the traceability.

In smaller organisations, the Business Architecture Owner function might be part of a broader EA role. In larger organisations, it might be a dedicated team. The function matters more than the structure.

Common Pitfalls

Creating capability models nobody uses — A capability model that sits in a drawer adds no value. If technology teams aren't using capability vocabulary in their conversations, the model isn't working. Start simple, prove value, then expand.

Over-engineering value streams — Value streams should be high-level flows, not detailed process maps. If you're documenting exception handling and system interactions, you've gone too deep. Save that detail for process architecture.

Strategic guardrails that never change — If your strategic guardrails haven't changed in two years, they're probably not reflecting actual strategy. Review them regularly.

Traceability theatre — Traceability that exists only in documents but never influences decisions is waste. If the traceability matrix isn't used in investment decisions or design reviews, question why you're maintaining it.

Capability models divorced from applications — A capability model without application mapping is an academic exercise. The value comes from knowing which systems support which capabilities — and therefore what's at stake when those systems change.

Product boundaries without capability clarity — Product teams need to know what they own. Without clear capability ownership, you get duplication, gaps, and endless boundary disputes. If two products think they own the same capability, the model isn't clear enough.

Confusing product mapping with org structure — Products and teams aren't the same thing. A team might support multiple products. A product might span teams. Map products to capabilities, then figure out team structures separately.

Extending to Full BIZBOK

XAF Business Architecture provides the governance-connected fundamentals. For organisations wanting deeper business architecture practice, BIZBOK (Business Architecture Body of Knowledge) offers comprehensive methodology that builds naturally on this foundation.

How they fit together:

XAF provides what BIZBOK doesn't emphasise:

• Governance integration — how business architecture decisions flow through tiered oversight
• Guardrails-based autonomy — enabling teams to move fast within business architecture boundaries
• Delivery connection — business architecture embedded in delivery cadences, not parallel to them
• Technical debt visibility — business architecture gaps tracked alongside technical debt
• Cross-domain traceability — systematic connection to security, data, and technology architecture

The practical path:

1. Start with XAF Business Architecture — Get the governance foundation working. Capability vocabulary in use. Value streams informing investment. Traceability connecting strategy to delivery.

2. Layer BIZBOK depth where needed — As business architecture maturity grows, adopt BIZBOK techniques for deeper analysis. Organisation mapping when operating model questions arise. Information mapping when data governance matures. Strategy mapping when planning cycles formalise.

3. Maintain XAF governance integration — Whatever BIZBOK artefacts you adopt, connect them through XAF's governance mechanisms. BIZBOK artefacts should inform guardrails, feed decision records, and populate the registry.

Certification note: BIZBOK supports the Certified Business Architect (CBA) credential through the Business Architecture Guild. For organisations investing in dedicated business architecture capability, this provides professional development pathways that complement XAF implementation.

The goal isn't XAF or BIZBOK — it's XAF for governance integration, with BIZBOK methodology available for those wanting comprehensive business architecture practice. Start with what XAF provides. Extend when you need more depth.

Integration with Other Domain Modules

Business Architecture provides context that other domains consume:

Business Architecture is typically where you start — it provides the "why" that shapes decisions in other domains.

What Success Looks Like

You know Business Architecture is working when:

• Technology investment conversations reference capabilities and value streams, not just systems
• Strategic guardrails are known and followed without architecture having to police them
• Solution architects can trace their designs back to business priorities without effort
• Capability maturity informs budget discussions
• Value stream metrics improve as architecture-informed improvements land
• New architects can understand business context by reading the registry, not just asking people

The goal isn't comprehensive documentation. It's business-technology alignment that actually works in practice.

Next Steps

1. Review the Governance Core — Ensure you have the foundation in place
2. Draft your strategic guardrails — Start with 5-10 statements about current priorities
3. Create an initial capability model — L1 and L2 to start, focused on areas of active investment
4. Map one value stream — Pick something strategically important or painfully broken
5. Connect to your registry — Populate the business architecture sections

Start small. Prove value. Scale what works.

XAF Connected Architecture | Developed by InnovateX Solutions