4.1 Phase B Objectives, Steps, and Business Modeling Approaches

4.1 Phase B Objectives, Steps, and Business Modeling Approaches

Phase B (Business Architecture) represents the foundational domain phase of the TOGAF Architecture Development Method (ADM). While Phase A establishes the overarching Architecture Vision, stakeholder landscape, and contractual boundaries in the Statement of Architecture Work, Phase B articulates the operational reality of how the enterprise creates value. Enterprise architecture is fundamentally business-led: technology solutions developed in Phase C (Data and Application) and Phase D (Technology) exist solely to realize, automate, and protect the business capabilities, organizational models, and value streams established in Phase B.

---

The Centrality of Business Architecture in the TOGAF ADM

In the TOGAF Standard, Business Architecture provides the context for all subsequent technical architecture domains. Attempting to design data architectures, microservice topologies, or cloud infrastructure without a validated Business Architecture creates solutions disconnected from corporate strategy, resulting in redundant investments, operational friction, and failed governance reviews.

Business Architecture describes the product and service strategy, organizational governance, business functions, capabilities, processes, roles, and information needs of the enterprise. By establishing explicit alignment between business strategy and architectural execution, Phase B ensures that every software license purchased, database schema defined, and server provisioned traces back directly to an authorized business goal.

---

Objectives of Phase B

The TOGAF Standard, 10th Edition states two objectives for Phase B:

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

Describing the baseline, performing gap analysis, and selecting reference models and viewpoints are the steps by which those objectives are reached. The Phase C and Phase D objectives follow the same pattern for their domains.

---

Inputs to Phase B: Laying the Groundwork

Enterprise architects do not invent the Business Architecture in isolation. Phase B relies on essential contextual and governance inputs:

• Request for Architecture Work: Articulates the business context, executive sponsorship, budget limits, and high-level business problems.
• Statement of Architecture Work: Sets the contractual scope, schedule, deliverables, and acceptance criteria agreed upon at the conclusion of Phase A.
• Architecture Vision: Delivers the high-level aspirational target state, key performance indicators (KPIs), business scenarios, and value proposition.
• Enterprise Architecture Principles: Governs design choices (e.g., "Buy over Build Commercial Solutions," "Straight-Through Processing by Default").
• Capability Assessment: Baseline capability maturity scores and organizational readiness metrics captured during the Preliminary Phase and Phase A.
• Architecture Continuum and Repository Assets: Relevant industry reference models (such as BIAN in banking or TM Forum eTOM in telecommunications), existing organization catalogs, and standard operating procedures.

---

The Nine Standard ADM Steps of Phase B

The TOGAF Standard defines nine structured steps for Phase B. While presented sequentially, practitioners execute these steps iteratively:

Step 1: Select Reference Models, Viewpoints, and Tools

The architect identifies relevant industry frameworks (e.g., APQC Process Classification Framework), internal corporate standards, and modeling notations (e.g., ArchiMate, BPMN). The architect uses the Stakeholder Map from Phase A to select viewpoints (e.g., Business Footprint View, Organization Structure View, Process Flow View) that communicate clearly with target stakeholder groups.

Step 2: Develop Baseline Business Architecture Description

The current state of the enterprise is modeled to the depth required to support the architecture scope. The architect documents existing organizational structures, business functions, operational capabilities, core processes, and external business actor relationships.

Step 3: Develop Target Business Architecture Description

The architect models the desired future state required to realize the Architecture Vision. This includes revised organizational boundaries, net-new business capabilities, modernized value streams, and optimized business services.

Step 4: Perform Gap Analysis

The architect compares the Baseline Business Architecture with the Target Business Architecture using the formal TOGAF Gap Analysis Matrix technique. Building blocks are classified to reveal what must be developed, modified, retired, or carried over.

Step 5: Define Candidate Roadmap Components

Based on the gap analysis results, the architect identifies candidate initiatives, business restructuring activities, and operational changes that must be sequenced in the Architecture Roadmap in Phase E.

Step 6: Resolve Impacts Across the Architecture Landscape

The architect evaluates whether the proposed Business Architecture impacts other business units, ongoing enterprise initiatives, partner ecosystems, or architecture domains. If the target business model requires real-time data streaming, the architect flags an immediate cross-domain requirement for Phase C.

Step 7: Conduct Formal Stakeholder Review

The architect presents the baseline, target, and gap analysis models to key stakeholders identified in the Power/Interest Grid, actively soliciting feedback, reconciling objections, and securing formal sign-off.

Step 8: Finalize the Business Architecture

Feedback from the formal stakeholder review is integrated. The models are finalized, validated against architecture principles, and checked for internal consistency.

Step 9: Create/Update the Architecture Definition Document

The architect updates the Business Architecture section of the Architecture Definition Document (ADD) and captures detailed functional and non-functional requirements in the Architecture Requirements Specification.

---

Business Modeling Approaches: Structure, Function, and Process

A mature Business Architecture models the enterprise across three complementary dimensions:

1. Organization Structure Modeling

Organization modeling captures the static, hierarchical, and network relationships within the enterprise. It details organizational units (e.g., divisions, departments, branch offices), internal actors (roles and personas), external actors (customers, suppliers, regulators), and physical/geographical locations. While essential for assigning accountability and governance, architects must avoid confusing the corporate organizational chart with the business architecture itself. Organizational charts shift frequently with leadership changes, whereas underlying business capabilities remain stable.

2. Business Function Modeling

Business functions represent logical groupings of business capabilities and activities centered around specialized expertise, regardless of which department performs them. Examples include Financial Management, Risk Underwriting, and Human Capital Management. Modeling business functions allows architects to identify duplicate functions performed inefficiently across multiple siloed operating units.

3. Business Process Modeling

Process modeling captures dynamic, operational behavior over time. A business process is a sequenced flow of activities that takes defined inputs and transforms them into measurable outputs for an internal or external customer. Typically documented using Business Process Model and Notation (BPMN), process models detail task sequences, swimlanes (role responsibilities), operational handoffs, business rules, and decision gateways.

---

Baseline-First versus Target-First Architectural Sequencing

A pivotal methodological decision in Phase B is whether to adopt a Baseline-First or a Target-First approach. The TOGAF Standard does not mandate a single pattern; rather, the lead architect selects the approach based on business context, time constraints, and organizational maturity:

---

Outputs of Phase B: ADD and Requirements Specification

Phase B concludes with substantial updates to core architectural deliverables:

• Architecture Definition Document (ADD) - Business Architecture Components:
  • Baseline Business Architecture models (versioned and cataloged).
  • Target Business Architecture models (versioned and cataloged).
  • Business Architecture Gap Analysis Matrix and narrative rationale.
  • Candidate Architecture Roadmap components and cross-domain impact assessments.
• Architecture Requirements Specification - Business Domain:
  • Validated business requirements tracing directly to Phase A business goals.
  • Business domain constraints (e.g., statutory compliance mandates, union labor rules).
  • Service-level expectations and business operational metrics.

---

Practitioner Exam Traps and Mitigation Strategies

• The Technology Prematurity Trap: Introducing specific software products, database vendors, or infrastructure platforms during Phase B. When an answer option in Phase B mentions "deploying a cloud data warehouse" or "installing an enterprise service bus," it is an anti-pattern. Phase B addresses business capabilities, functions, and processes, not technical solution components.
• The Organizational Chart Fallacy: Assuming that reorganizing corporate departments constitutes a Business Architecture. Org charts show management reporting lines, which are notoriously volatile. True business architecture focuses on reusable capabilities and customer-aligned value streams.
• The Scope Creep Hazard: Attempting to document every micro-procedure and desktop work instruction in the baseline business process models. Architects must maintain an architectural level of abstraction, delegating operational procedure documentation to business process management (BPM) teams.