4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
Key Takeaways
Phase B artifacts are categorized into Catalogs (lists of building blocks like Organization/Actor, Capability, and Value Stream catalogs), Matrices (relationship grids like Business Interaction and Actor/Role matrices), and Diagrams (visual viewpoints like Business Footprint and Process Flow diagrams).
The TOGAF Gap Analysis technique utilizes a structured two-dimensional matrix comparing Baseline Architecture Building Blocks against Target Architecture Building Blocks to classify gaps as Included, New, Eliminated, or Missing.
Architects must rigorously distinguish between intentional gaps (deliberately eliminated legacy capabilities or added target capabilities) and unintentional gaps (overlooked baseline requirements or accidental omissions).
Phase B deliverables include formal updates to the Architecture Definition Document (ADD) capturing the baseline, target, and rationale, alongside the Architecture Requirements Specification recording functional and non-functional business criteria.
Identified business gaps and candidate architecture building blocks are channeled into candidate roadmap components, forming the primary inputs for transition planning in Phase E and Phase F.
4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
Phase B transforms strategic concepts into structured, governed architectural content. Under the TOGAF Architecture Content Framework, architects capture business architecture models using three foundational artifact classes: Catalogs, Matrices, and Diagrams. Once baseline and target states are documented, architects apply the formal TOGAF Gap Analysis technique to identify discrepancies, discover unintentional omissions, and generate candidate roadmap components that feed downstream ADM phases.
The Architecture Content Framework in Phase B
The TOGAF Architecture Content Framework provides a structural model for architectural work products, distinguishing between:
- Deliverables: Formally reviewed, agreed-upon, and signed-off contractual outputs (e.g., the Architecture Definition Document).
- Artifacts: Fine-grained architectural work products that describe an aspect of the architecture, classified as catalogs (lists), matrices (relationships), or diagrams (graphical views).
- Building Blocks: Reusable operational or technical components. In Phase B, architects define Architecture Building Blocks (ABBs) representing business capabilities, functions, services, and organization units.
Catalogs, Matrices, and Diagrams: The Phase B Artifact Toolkit
Practitioners must select and construct the appropriate artifacts to address the stakeholder concerns recorded in the Stakeholder Map:
1. Business Architecture Catalogs (Inventories)
Catalogs are tabular repositories of discrete architectural elements:
- Organization/Actor Catalog: Captures internal organizational units, departments, external partner entities, and distinct human/system actor roles.
- Business Capabilities Catalog: A hierarchical, definitive inventory of all strategic, core, and supporting capabilities across the enterprise, including ownership and maturity metadata.
- Value Stream Catalog: Catalogs all approved value streams, their sequential value stages, trigger events, participating stakeholders, and final value propositions.
- Business Service / Function Catalog: Documents the functional boundaries of the enterprise and the reusable business services exposed to internal or external consumers.
- Business Process Catalog: Details the end-to-end operational processes, process owners, cycle times, regulatory classifications, and trigger events.
2. Business Architecture Matrices (Cross-Entity Relationships)
Matrices map relationships between two or more entity types to evaluate dependencies, ownership, and functional gaps:
- Business Interaction Matrix: Depicts interactions, communications, and data exchanges between different organizational units or business functions.
- Actor / Role Matrix: Maps which individual actors (or job titles) perform which defined architectural roles within business operations.
- Capability / Organization Matrix: Explicitly maps business capabilities to the organizational units accountable for their funding, maintenance, and execution, uncovering duplicate capabilities across departments.
- Value Stream / Capability Matrix: Cross-maps value stages to supporting business capabilities (as examined in Section 4.3).
3. Business Architecture Diagrams (Graphical Views)
Diagrams provide visual representations of the architecture tailored to stakeholder viewpoints:
- Business Footprint Diagram: Visually links business functions, organizational units, and supporting technology platforms. It demonstrates business ownership of IT systems and illustrates the functional perimeter of proposed changes.
- Business Service / Information Diagram: Details the operational dependencies between business services and the specific information entities consumed and created.
- Functional Decomposition Diagram: Decomposes high-level business capabilities or functions into child functions, providing clarity on operational scope.
- Goal / Objective / Service Diagram: Establishes end-to-end visual traceability from executive strategic goals and KPIs down to operational business services.
The TOGAF Gap Analysis Technique
A critical requirement of Phase B is performing a rigorous Gap Analysis (Step 4 of the ADM progression). The Gap Analysis technique is a disciplined, matrix-driven method for discovering what building blocks have been added, modified, retired, or inadvertently missed between the Baseline and Target architectures.
Structure of the Gap Analysis Matrix
The architect constructs a two-dimensional matrix:
- Vertical Axis (Rows): Baseline Architecture Building Blocks (ABBs) plus an entry for "New ABBs."
- Horizontal Axis (Columns): Target Architecture Building Blocks (ABBs) plus an entry for "Eliminated ABBs."
| Baseline \ Target ABBs | Target ABB 1: Digital Onboarding | Target ABB 2: Auto Underwriting | Target ABB 3: Real-Time Fraud Engine | Eliminated ABBs |
|---|---|---|---|---|
| Baseline ABB 1: Manual Paper Intake | - | - | - | Eliminated (Intended) |
| Baseline ABB 2: Rule-Based Credit Scorer | - | Modified (Included) | - | - |
| Baseline ABB 3: Batch Fraud Screening | - | - | - | Eliminated (Intended) |
| Baseline ABB 4: Regulatory Tax Reporting | - | - | - | MISSING GAP (Unintentional) |
| New ABBs | NEW (Intended) | - | NEW (Intended) | - |
Deconstructing the Gap Categories: Included, New, Eliminated, and Missing
TOGAF's own wording distinguishes items that are included, new, or eliminated, where an eliminated item may have been eliminated by design or by accident. This guide splits out the accidental case as "missing" so it stands out. In Requirements Management, something eliminated by accident becomes a gap requirement, which must be recorded and fixed in the Target Architecture. The intersection cells of the matrix therefore reveal four classifications:
- Included (Retained / Modified): The baseline building block continues to exist in the target state. It may be retained without change or modified to meet new performance, scalability, or regulatory standards.
- New (Intentionally Added): A building block that exists in the Target Architecture but has no counterpart in the Baseline. It represents net-new business capabilities, functions, or organizational structures required to achieve strategic goals.
- Eliminated (Intentionally Decommissioned): A building block present in the Baseline that is deliberately excluded from the Target Architecture. This represents rationalized, automated, or divested capabilities (e.g., eliminating manual paper document scanning upon adopting automated e-signatures).
- Missing (Unintentional Omission): A critical baseline capability, regulatory check, or stakeholder requirement that was inadvertently omitted during target modeling. This is the most dangerous defect in enterprise architecture. If an architect designs a target operating model but forgets statutory reporting requirements (such as Baseline ABB 4: Regulatory Tax Reporting above), the target system will be illegal to deploy.
Reconciling Intentional versus Unintentional Gaps
When a gap is identified, the architect must immediately determine its nature:
- Intentional Gaps: Driven by business strategy. If an enterprise strategy states "Phase out physical retail branches in favor of digital-only mobile banking," eliminating the Branch Cash Handling capability is an intentional gap. The architect must formulate decommissioning and talent transition plans in Phase E to handle this elimination smoothly.
- Unintentional Gaps: Architectural design errors. When the Gap Analysis Matrix reveals an unmapped baseline building block that is still legally or operationally required, the architect must immediately update the Target Business Architecture to incorporate that building block before advancing to Phase C.
Documenting Results: Updating the ADD and Architecture Requirements Specification
Phase B concludes by updating two primary architectural deliverables:
1. Architecture Definition Document (ADD) Updates
The ADD is the companion document that describes the architecture itself. In Phase B, the architect formalizes:
- Baseline Business Architecture (Version 1.0): Complete descriptions of current organizational models, capabilities, and processes.
- Target Business Architecture (Version 1.0): Validated models of the future business operational state.
- Gap Analysis Results: The completed Gap Analysis Matrix, detailed gap narratives, and business impact assessments.
- Business Architecture Rationale: The architectural decisions, trade-offs, and governance validations that justify the target state.
2. Architecture Requirements Specification Updates
The Architecture Requirements Specification documents the quantitative and qualitative conditions that the architecture must satisfy. In Phase B, the architect adds:
- Functional Business Requirements: Detailed processing rules, service automation rates, and cross-functional workflow handoffs.
- Non-Functional Business Requirements: Operational business hours, disaster recovery recovery time objectives (RTOs) from a business continuity perspective, customer service level agreements (SLAs), and regulatory compliance criteria.
- Business Constraints: Budgetary caps, statutory regulations, labor union contracts, and executive policy limits.
Deriving Candidate Roadmap Components for Downstream Phases
Every gap identified in Phase B represents work that must be executed to transition the enterprise from baseline to target. Rather than discarding these gaps, the architect packages them into Candidate Architecture Roadmap Components:
- A New Capability Gap (e.g., Automated Biometric Identity Verification) becomes a candidate work package in Phase E.
- An Eliminated Capability Gap (e.g., Decommissioning Legacy Check Sorting Center) becomes a candidate divestment work package in Phase E.
- A Modified Capability Gap (e.g., Upgrade Core Underwriting Rules) becomes a candidate enhancement work package in Phase E.
These candidate components flow directly into Phase E (Opportunities and Solutions), where they are synthesized with data, application, and technology gaps to build cohesive transition architectures.
Practitioner Exam Traps: The Hazard of Unintentional Gaps
- The Orphaned Target Building Block: Introducing a flashy new capability into the Target Business Architecture that does not trace back to any approved business goal in Phase A or resolve any identified business driver. Every new ABB must have justifiable business lineage.
- Confusing the ADD with the Architecture Requirements Specification: Believing that the Architecture Definition Document and Requirements Specification are interchangeable. The ADD describes what the architecture looks like (models, views, building blocks); the Requirements Specification describes the measurable criteria the implementation must meet (compliance, performance, constraints).
- Ignoring Eliminated Capabilities: Failing to document eliminated building blocks in the gap analysis. If legacy business capabilities are quietly dropped from models without formal decommissioning plans, orphaned employees, zombie IT systems, and unmanaged contracts will persist indefinitely.
During Step 4 (Gap Analysis) of Phase B, an enterprise architect maps baseline business building blocks against target building blocks in a gap matrix. The architect discovers that a statutory anti-money laundering (AML) reporting capability present in the baseline is completely unmapped in the target architecture. How should the architect classify and handle this gap?
Treat it as an intentionally Eliminated item, since anything absent from the target was removed by design, and proceed with Phase C immediately.
Treat it as Included, because baseline compliance capabilities carry over to the target automatically and need no further documentation.
Treat it as an unintentional omission (a missing gap), and add the mandatory AML capability to the Target Business Architecture before moving on.
Record it as an optional candidate roadmap component for the development team to evaluate during Phase G implementation governance.
Which of the following business architecture artifacts is specifically designed to visually communicate the boundary and ownership between business functions, organizational units, and technical systems to business executives?
Business Footprint Diagram
Organization / Actor Catalog
Business Interaction Matrix
Actor / Role Matrix
What is the primary conceptual distinction between the Architecture Definition Document (ADD) and the Architecture Requirements Specification as deliverables updated at the conclusion of Phase B?
The ADD is created only in the Preliminary Phase, whereas the Architecture Requirements Specification is first created in Phase H when change requests arrive.
The ADD documents the software code repositories, whereas the Architecture Requirements Specification documents the hardware server specifications for each site.
The ADD is an informal internal draft, whereas the Architecture Requirements Specification is the formal contract that delivery partners sign in Phase G.
The ADD holds the baseline and target models, views, and building blocks; the Requirements Specification holds the measurable criteria the architecture must meet.
Sections you finish are checked off in the contents.