← ADM cycle0/9 steps · 0%

Phase B: Business Architecture

Describe how the enterprise operates to reach its goals: capabilities, value streams, processes, organization, and information.

About this phase

Phase B develops the Business Architecture: a description of how the enterprise needs to operate to achieve its business goals and respond to the strategic drivers set out in the Architecture Vision. It shows how stakeholder concerns are addressed in the business domain.

The Business Architecture is developed first, because it is a prerequisite for work in the other domains (Data, Application, Technology) and demonstrates the business value of the work to key stakeholders. Typical content includes business capabilities, value streams, organization maps, business processes, and business information.

Like Phases C and D, Phase B follows the standard pattern of steps: select models/viewpoints/tools, develop Baseline and Target descriptions, perform gap analysis, define candidate roadmap components, resolve cross-landscape impacts, conduct stakeholder review, finalize, and feed the Architecture Definition Document.

Objectives

Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, respond to the strategic drivers set out in the Architecture Vision, and address the Statement of Architecture Work and stakeholder concerns.
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures.

Steps in this phase

0/9 · 0%

1.Select reference models, viewpoints, and toolsChoose relevant business reference models, the viewpoints that address stakeholder concerns, and the tools and techniques (e.g., capability maps, value stream maps, process models) to be used.
2.Develop the Baseline Business Architecture descriptionDescribe the existing business environment to the extent needed to support the Target Architecture and gap analysis.
3.Develop the Target Business Architecture descriptionDescribe the target business capabilities, value streams, organization, and processes needed to realize the Architecture Vision.
4.Perform gap analysisIdentify gaps between Baseline and Target using the gap analysis technique; verify the models for consistency and accuracy.
5.Define candidate roadmap componentsCreate an initial Business Architecture roadmap from the gap analysis — input to Phases E and F for work-package prioritization.
6.Resolve impacts across the Architecture LandscapeCheck whether other architectures in the landscape are impacted by (or impact) this architecture, and address the wider implications.
7.Conduct formal stakeholder reviewReview the work against the intent of the Statement of Architecture Work; confirm the architecture addresses stakeholder concerns.
8.Finalize the Business ArchitectureSelect standards for building blocks, fully document each building block, cross-check against business goals, and complete the deliverable.
9.Create/update the Architecture Definition DocumentDocument the Business Architecture (baseline, target, gap results, views) in the Architecture Definition Document.

Key inputs

Request for Architecture Work and approved Statement of Architecture Work
Architecture Vision (including refined key high-level stakeholder requirements)
Business principles, business goals, and business drivers
Organizational Model for Enterprise Architecture and Tailored Architecture Framework
Architecture Repository — reusable building blocks, reference models, organization-specific standards
Draft Architecture Definition Document (from Phase A)
Capability Assessment and Communications Plan

Key outputs

Refined and updated Architecture Vision phase deliverables (Statement of Architecture Work, validated principles/goals/drivers)
Draft Architecture Definition Document containing Baseline and Target Business Architecture (v1.0)
Draft Architecture Requirements Specification, including gap analysis results and relevant technical requirements
Business Architecture components of an Architecture Roadmap

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

PFrom Preliminary Phase

AFrom Phase A: Architecture Vision

Prepared for this phase

example inputCatalogfrom PreliminaryA sample set of Architecture Principles in the standard four-part TOGAF template: Name, Statement, Rationale, Implications.

Meridian Retail Group — Architecture Principles v1.0

Approved by: Architecture Board, 14 March 2026 Owner: Lead Architect · Review cycle: annually, or when Phase H raises a change

Principles catalog (summary)

#	Name	Domain	Derived from (business principle / driver)
1	Business Continuity	Business	Customer first
2	Data is an Asset, Shared, and Accessible	Data	One Meridian, not many
3	Buy Before Build	Application	Spend once
4	Interoperability	Technology	Spend once, integration cost driver
5	Compliance with Law and Regulation	Business	Regulatory pressure (GDPR, PCI-DSS)

Principle 1: Business Continuity

Statement: Enterprise operations are maintained in spite of system interruptions.

Rationale: Store trading and online checkout are revenue-critical. As systems become more integrated under One Meridian, dependence on shared services increases and interruptions have wider impact.

Implications:

Shared services must be designed for resilience and graceful degradation
Recoverability and redundancy requirements must be defined at design time
Applications must be assessed for criticality and assigned availability tiers

Principle 2: Data is an Asset, Shared, and Accessible

Statement: Data is a corporate asset with defined ownership; it is shared across functions and accessible to authorized users through common services.

Rationale: The single largest obstacle to the One Meridian strategy is fragmented customer, product, and inventory data held in silos.

Implications:

Each key data entity is assigned a business data owner (trustee)
Applications consume master data from designated authoritative sources
Data sharing must comply with Data Governance Council privacy policies

Principle 3: Buy Before Build

Statement: Packaged and SaaS solutions are preferred over custom development unless a capability is a source of competitive differentiation.

Rationale: Meridian's differentiation is retail experience, not software engineering. Custom systems have driven maintenance cost and key-person risk.

Implications:

Requirements should be adapted to standard product capability where possible
A build decision requires an approved exception with business justification
Vendor and integration standards must be defined and maintained

Principle 4: Interoperability

Statement: Software and hardware conform to defined standards that promote interoperability of data, applications, and technology.

Rationale: Integration cost across the current fragmented landscape is the largest single component of IT change spend.

Implications:

An integration standard (APIs, events) is defined and governed
Deviations are managed through a documented exceptions process
Standards are reviewed periodically by the Architecture Board

Principle 5: Compliance with Law and Regulation

Statement: Architecture decisions comply with applicable law, regulation, and contractual obligations in every country where Meridian trades.

Rationale: Unifying customer data across channels increases GDPR exposure, and payment flows fall under PCI-DSS. A breach would undo the trust that One Meridian depends on.

Implications:

Consent and lawful basis are designed into customer data flows, not added later
PCI-DSS scope is kept as small as possible and documented for each solution
The CISO and Data Protection Officer review designs that process personal data

Using these principles

Every deliverable submitted to the Architecture Board states which principles it supports and any it departs from.
A departure is handled as a time-bound dispensation (see the Architecture Governance Framework). A departure that should be permanent is raised as a Change Request against the principle itself.
When principles conflict (for example Buy Before Build against Interoperability for a closed SaaS product), the Board records how it weighed them in the Governance Repository.

Example outputs

example outputDeliverableExcerpt of the Architecture Definition Document: target business capability map fragment and a value stream mapped to capabilities.

Architecture Definition Document — Business Architecture (draft v0.2, excerpt)

Document: ADD for SAW-2026-001 · Section: 5, Business Architecture Author: T. Lindqvist · Status: Section approved, Architecture Board 25 Jun 2026

5.1 Viewpoints and techniques used (step 1)

Capability map with maturity heat map; value stream mapped to capabilities; Organization/Actor catalog; Driver/Goal/Objective catalog; Process Flow diagrams for BOPIS and cross-channel returns. No external retail reference model was adopted. Capability names follow the Meridian capability catalog in the Architecture Repository.

5.2 Target business capability map (fragment, Customer & Commerce)

Level 1 capability	Level 2 capability	Baseline maturity	Target maturity
Customer Management	Customer Identity & Profile	1 – fragmented	4 – single governed profile
Customer Management	Consent & Preference Mgmt	1 – per-system	4 – centralized
Order Management	Cross-channel Order Capture	2 – per-channel	4 – unified
Order Management	Returns & Exchanges	1 – manual cross-channel	3 – one-step any channel
Inventory Management	Real-time Availability	1 – nightly batch	4 – event-driven
Loyalty	Earn & Redeem	2 – online only redemption	4 – all channels
Fulfilment	Store Fulfilment	0 – does not exist	3 – BOPIS in all stores
Fulfilment	DC Fulfilment	3 – stable	3 – unchanged
Customer Service	Case Management	2 – three queues	3 – one cross-channel queue

Maturity scale 0–5, ratings validated with the business after the May workshops.

5.3 Value stream: "Acquire & Serve Customer" (stages → enabling capabilities)

Attract → Campaign Mgmt, Segmentation
Engage → Customer Identity & Profile, Consent Mgmt
Transact → Cross-channel Order Capture, Real-time Availability, Earn & Redeem
Fulfil → Store Fulfilment (new), DC Fulfilment
Support → Returns & Exchanges, Case Management

Stage	Entry condition	Value item delivered	Stage KPI
Attract	Prospect or lapsed customer	Relevant offer	Campaign response rate
Engage	Customer interacts in any channel	Customer is recognized	Identified-transaction share
Transact	Intent to buy	Order placed with a trusted promise	Order conversion
Fulfil	Order confirmed	Goods in customer's hands	BOPIS ready within 2h
Support	Post-purchase need	Issue resolved in one step	Returns cycle time

Value-stream heat map finding: stages Transact and Fulfil depend on the two lowest-maturity capabilities (Real-time Availability, Store Fulfilment) — these become priority roadmap candidates. Customer Identity & Profile is also rated 1, but it underpins every stage and is treated as the foundation (WP-01).

5.4 Business process changes (summary)

Process	Baseline	Target
Loyalty enrolment	Paper form, keyed in 3–5 days	Enrolled at the till, points usable same day
Order fulfilment	Central DC only	DC or store pick (BOPIS)
Cross-channel return	Head-office credit, ~9 days	Refunded in one store transaction
Care enquiry	Order number required, transfers common	Search by customer across all channels

5.5 Target organization change (summary)

New role: Customer Data Steward (reports to Data Governance Council)
Store associates gain "endless aisle" and BOPIS pick/handover duties
Customer Care consolidated from 3 channel teams into 1 cross-channel team

5.6 Traceability

Capabilities trace to objectives in the Driver/Goal/Objective catalog (CAT-B-01) and to business requirements REQ-B-001 to REQ-B-015 (Architecture Requirements Specification, §2).

Study notes

Produced in: Step 1: Select reference models, viewpoints, and tools · Step 3: Develop the Target Business Architecture description · Step 8: Finalize the Business Architecture · Step 9: Create/update the Architecture Definition Document

This is a section of the Architecture Definition Document, which is a deliverable. The capability map, value stream table, and process summary inside it are artifacts that make up its content.
Baseline and target maturity sit side by side so the gap is visible on one page. The heat map links weak capabilities to the value stream stages they hold back, which is how roadmap priority is argued.
Value streams describe how value is delivered end to end. Capabilities describe what the business does. Mapping one to the other is a core Phase B technique and a common exam distinction.
Section 5.1 records the step 1 choices. Stating that no reference model was adopted is itself a decision worth documenting.
The traceability section links the target to objectives and requirements, which is what step 8 means by cross-checking the architecture against business goals.

Study tips & key concepts

Knowledge of the Business Architecture is a prerequisite for architecture work in the other domains — that's why Phase B comes first after the Vision.
Key Business Architecture concepts: business capabilities (what the business does), value streams (how value is delivered end-to-end), organization maps (who), and business processes (how).
Gap analysis: matrix with Baseline building blocks on one axis and Target on the other; 'Eliminated' items (in baseline, not in target) must be deliberately removed, and 'New' items (in target, not baseline) are gaps to fill.
Phases B, C, and D all share the same nine-step pattern — learn it once: select models/viewpoints/tools → baseline → target → gap → candidate roadmap → resolve impacts → stakeholder review → finalize → document.
The Architecture Requirements Specification starts to be populated here with measurable requirements the implementation must meet.