TOGAF ADM in Practice — Part 2: Building the Architecture — Domains and Decisions

The Architecture Development Method’s domain phases are Business Architecture (Phase B), Information Systems Architecture (Phase C) and Technology Architecture (Phase D). These phases are where strategic intent becomes concrete architectural decisions. Most programs treat these phases as documentation exercises. They are not. They are the primary mechanism for converting business requirements into technology constraints and for surfacing integration complexity before it becomes implementation cost.

This paper, the second in a four-part series, works through Phases B, C, and D as I encounter them in practice: with the sequencing logic, the tradeoffs, the failure modes and the cross-domain disciplines that determine whether the architecture holds under delivery pressure. Part 1 established the foundation: Architecture Vision, scoping, and principles. Part 3 picks up where this paper ends, at the transition from architecture definition into delivery governance.

Enterprise architecture programs routinely fail not because the framework is wrong but because domain phases are executed in isolation. Business Architecture produces a capability map. Information Systems Architecture produces an application inventory. Technology Architecture produces a platform diagram, however, verifying that these three are mutually consistent is the key for successful delivery. Phase E (Opportunities and Solutions) is built on three independently coherent but collectively contradictory foundations.

The TOGAF ADM addresses this through a deliberate sequencing: Business drives Information Systems, Information Systems drives Technology and through explicit cross-domain gap analysis before the program moves into solution selection. The sequencing is not bureaucratic convention, it reflects a simple dependency: you cannot make sound technology choices without understanding the application landscape, and you cannot make sound application choices without understanding the business processes they support.

Part 1 of this series established the Architecture Vision and scoping framework that governs all three domain phases. This paper assumes that foundation is in place — Statement of Architecture Work signed, Architecture Vision approved, principles documented, scope bounded across the four dimensions of breadth, depth, time period, and domain.

All three domain phases follow the same internal logic. Understanding the pattern once means applying it consistently across all three.

flowchart TD
    classDef input fill:#fff3e0,stroke:#e65100
    classDef process fill:#e8f5e9,stroke:#2e7d32
    classDef output fill:#e3f2fd,stroke:#1565c0

    IN1["Architecture Vision<br>(Phase A Output)"]
    IN2["Existing Baseline<br>Documentation"]
    IN3["Architecture<br>Principles"]
    IN4["Requirements<br>Repository"]

    PB["Phase B<br>Business Architecture"]
    PC["Phase C<br>Information Systems Architecture<br>(Data + Application)"]
    PD["Phase D<br>Technology Architecture"]

    OUT1["Business Architecture<br>Deliverables"]
    OUT2["Information Systems<br>Architecture Deliverables"]
    OUT3["Technology Architecture<br>Deliverables"]
    OUT4["Input to Phase E<br>Opportunities & Solutions"]

    IN1 --> PB
    IN2 --> PB
    IN3 --> PB
    IN4 --> PB

    PB -->|"Business context<br>drives IS decisions"| PC
    PC -->|"IS requirements<br>drive tech decisions"| PD

    PB --> OUT1
    PC --> OUT2
    PD --> OUT3
    OUT3 --> OUT4

    class IN1,IN2,IN3,IN4 input
    class PB,PC,PD process
    class OUT1,OUT2,OUT3,OUT4 output

Each phase has four consistent steps:

1. Develop the Baseline Architecture — what exists today
2. Develop the Target Architecture — what the future state looks like
3. Perform gap analysis — what needs to be built, changed, or retired
4. Define candidate roadmap components — the work packages that close the gaps

The gap analysis is the most underinvested step in practice. Teams document the baseline and the target, then skip directly to solution selection. Gap analysis forces the question: what specifically has to change, and in what sequence? Without it, roadmaps are wish lists.

Phase B translates the Architecture Vision into a structured description of how the business works — its processes, organizational units, information flows, and the capabilities it needs to deliver its strategy. Business Architecture provides the foundation for all subsequent architecture domains. Every downstream decision in Phase C and D traces back to a business requirement I establish here.

Business Architecture produces many artifacts — capability maps, organization maps, process models, information maps. In practice, two views carry the most weight in real programs.

Business Capability Map

A capability map answers: what must the business be able to do? — independent of how it currently does it or which systems support it.

flowchart TD
    classDef l1 fill:#fff3e0,stroke:#e65100
    classDef l2 fill:#e8f5e9,stroke:#2e7d32
    classDef l3 fill:#e3f2fd,stroke:#1565c0

    ENT["Enterprise Capability Map"]

    C1["Customer Management"]
    C2["Supply Chain"]
    C3["Financial Management"]
    C4["Product Development"]

    C1A["Customer Acquisition"]
    C1B["Customer Retention"]
    C1C["Customer Service"]

    C2A["Procurement"]
    C2B["Inventory Management"]
    C2C["Logistics & Fulfillment"]

    C3A["Financial Planning"]
    C3B["Accounting & Reporting"]
    C3C["Treasury Management"]

    ENT --> C1
    ENT --> C2
    ENT --> C3
    ENT --> C4

    C1 --> C1A
    C1 --> C1B
    C1 --> C1C

    C2 --> C2A
    C2 --> C2B
    C2 --> C2C

    C3 --> C3A
    C3 --> C3B
    C3 --> C3C

    class C1,C2,C3,C4 l1
    class C1A,C1B,C1C,C2A,C2B,C2C,C3A,C3B,C3C l2

The capability map is technology-agnostic by design. It describes what the business does before any conversation about how systems support it. This prevents the most common failure mode in Phase B: letting current-state system limitations constrain the definition of future-state business capabilities.

Value Stream and Process Flow

Where the capability map shows structure, the value stream shows flow — how the business delivers value end-to-end across organizational and system boundaries. This is where handoff points, bottlenecks, and integration requirements become visible.

In a large ERP transformation, Phase B is where the decision gets made about whether to adopt standard processes — configure to SAP or Oracle standards — or customize to existing business processes. That is a Business Architecture decision, not a technology decision.

Teams that let the technology team make this call without a completed Business Architecture end up with configurations that mirror broken existing processes and customizations that make future upgrades impossible. The discipline Phase B enforces: document the business process, identify where it differentiates the enterprise competitively, and only then decide what to configure versus customize. Everything else gets standardized.

Phase C has two sub-phases that are frequently treated as one. They are not.

Data Architecture defines what data the enterprise needs, where it lives, who owns it, and how it flows. The critical output is the Data Entity / Business Function matrix — a mapping of which business functions from Phase B create, read, update, or delete which data entities. This matrix is the primary input for identifying master data, integration requirements, and data ownership boundaries.

flowchart LR
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    BF["Business Functions<br>(Phase B Output)"]
    DE["Data Entities<br>Catalog"]
    CRUD["CRUD Matrix<br>Create / Read / Update / Delete"]
    MDM["Master Data<br>Ownership Model"]
    INT["Integration<br>Requirements"]
    DA["Data Architecture<br>Target State"]

    BF --> CRUD
    DE --> CRUD
    CRUD --> MDM
    CRUD --> INT
    MDM --> DA
    INT --> DA

    class BF,DE source
    class CRUD integration
    class MDM,INT target
    class DA reporting

Where this breaks in practice: organizations skip the CRUD matrix because it is tedious to produce. The consequence shows up in Phase D and beyond — conflicting systems of record, duplicated master data, and integration patterns built around the wrong source of truth. The matrix is not optional; it is the evidence base for every master data management and integration decision downstream.

Application Architecture defines the applications the enterprise needs — not necessarily the ones it currently has — and how they interact. The key discipline: derive application requirements from data and business requirements, not from vendor roadmaps. The sequence that works is:

1. Business functions defined in Phase B
2. Data entities and flows from Phase C1
3. Application capabilities needed to support both
4. Current application landscape assessed against those needs
5. Gaps drive build, buy, retire, or consolidate decisions

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef process fill:#e8f5e9,stroke:#2e7d32
    classDef output fill:#e3f2fd,stroke:#1565c0
    classDef decision fill:#f3e5f5,stroke:#6a1b9a

    REQ["Application Requirements<br>from B + C1"]
    BASELINE["Current Application<br>Landscape Baseline"]
    GAP["Gap Analysis"]

    D1["Build"]
    D2["Buy / SaaS"]
    D3["Consolidate"]
    D4["Retire"]

    APPARCH["Application Architecture<br>Target State"]
    INTREQ["Integration<br>Architecture Requirements"]

    REQ --> GAP
    BASELINE --> GAP
    GAP --> D1
    GAP --> D2
    GAP --> D3
    GAP --> D4

    D1 --> APPARCH
    D2 --> APPARCH
    D3 --> APPARCH
    D4 --> APPARCH
    APPARCH --> INTREQ

    class REQ,BASELINE source
    class GAP process
    class D1,D2,D3,D4 decision
    class APPARCH,INTREQ output

The hardest decision in Phase C2 on a real program is application rationalization — deciding what to retire. This is where business politics and architecture integrity collide directly.

The architectural position is clear: retire applications that duplicate capabilities available in the target application landscape. The organizational reality is messier: teams have operational dependencies, customizations, and institutional knowledge tied to legacy systems.

The TOGAF approach provides the arbitration mechanism — decisions are made against the Architecture Vision and Principles established in the Preliminary Phase and Phase A, not against team preference. This is precisely why those phases matter. Without signed-off principles and a Vision document, every rationalization decision becomes a negotiation with no anchor.

Phase D translates application and data architecture requirements into a technology platform specification. It answers: what infrastructure, platforms, and technology standards are needed to deliver the application and data architecture?

Phase D does not select products. It defines technology requirements and standards. Product selection happens in Phase E. Teams that collapse Phase D and vendor selection into a single step are making technology bets before the architecture requirements are fully specified — a sequencing error that creates lock-in without corresponding benefit.

The primary mechanism in Phase D is the Technology Standards Catalog — a curated set of approved platforms, patterns, and standards against which solution proposals are evaluated.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    APP["Application Architecture<br>Phase C Output"]
    DATA["Data Architecture<br>Phase C Output"]
    NFRS["Non-Functional Requirements<br>Performance / Security / Availability"]
    EXISTING["Existing Technology<br>Baseline"]

    TECHREQ["Technology Requirements"]
    STANDARDS["Technology Standards<br>Catalog"]

    COMPUTE["Compute<br>Standards"]
    STORAGE["Storage & Data<br>Platform Standards"]
    NETWORK["Network &<br>Integration Standards"]
    SECURITY["Security &<br>Identity Standards"]

    TECHARCH["Technology Architecture<br>Target State"]

    APP --> TECHREQ
    DATA --> TECHREQ
    NFRS --> TECHREQ
    EXISTING --> TECHREQ

    TECHREQ --> STANDARDS
    STANDARDS --> COMPUTE
    STANDARDS --> STORAGE
    STANDARDS --> NETWORK
    STANDARDS --> SECURITY

    COMPUTE --> TECHARCH
    STORAGE --> TECHARCH
    NETWORK --> TECHARCH
    SECURITY --> TECHARCH

    class APP,DATA,NFRS,EXISTING source
    class TECHREQ,STANDARDS integration
    class COMPUTE,STORAGE,NETWORK,SECURITY target
    class TECHARCH reporting

The most common Phase D failure mode is treating non-functional requirements — performance, availability, security, scalability — as late-stage concerns. NFRs are Technology Architecture inputs, not implementation afterthoughts. NFRs discovered in testing, in production incidents, or in procurement contracts are all expensive discovery moments.

The sequence that works:

1. Extract NFR implications from Phase B — business process SLAs, regulatory requirements
2. Extract NFR implications from Phase C — data volumes, integration frequency, application criticality
3. Document NFRs explicitly in Phase D as technology constraints
4. Use them as evaluation criteria in Phase E vendor and platform assessment

Each domain phase produces its own gap analysis. There is a fourth gap analysis that most programs skip: the cross-domain gap analysis — verifying that the three target architectures are internally consistent.

Inconsistencies that emerge here:

• Business processes defined in Phase B that have no application support identified in Phase C
• Application requirements in Phase C that have no corresponding technology platform in Phase D
• Technology standards in Phase D that cannot support the performance requirements implied by Phase B process volumes

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0
    classDef risk fill:#f3e5f5,stroke:#6a1b9a

    BA["Business Architecture<br>Gap Analysis"]
    CA["Information Systems<br>Gap Analysis"]
    TA["Technology Architecture<br>Gap Analysis"]

    XGA["Cross-Domain<br>Gap Analysis"]

    G1["Unmapped Business<br>Capabilities"]
    G2["Unsupported Application<br>Requirements"]
    G3["Unresolved Technology<br>Dependencies"]

    RMP["Consolidated<br>Roadmap Components"]
    PE["Input to Phase E<br>Opportunities & Solutions"]

    BA --> XGA
    CA --> XGA
    TA --> XGA

    XGA --> G1
    XGA --> G2
    XGA --> G3

    G1 --> RMP
    G2 --> RMP
    G3 --> RMP
    RMP --> PE

    class BA,CA,TA source
    class XGA integration
    class G1,G2,G3 risk
    class RMP,PE target

The cross-domain gap analysis is the final gate before Phase E. If it is skipped, Phase E is built on three independently coherent but mutually inconsistent architectures — and the inconsistencies surface as change requests during implementation, which is the worst possible discovery moment.

Interoperability requirements are not a Phase D concern. They emerge in Phase A, deepen through B, C, and D, and must be tracked continuously across all three domain phases.

The failure mode is treating interoperability as a Phase D integration problem. By Phase D, the decisions that determine integration complexity — data ownership, application boundaries, process handoffs — have already been made in Phases B and C. If those phases did not capture interoperability requirements explicitly, Phase D inherits hidden integration debt with no architectural basis for resolving it.

flowchart LR
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32

    subgraph PHASE_B["Phase B — Business Architecture"]
        BI["Business &<br>Operational Interoperability"]
    end

    subgraph PHASE_C["Phase C — Information Systems"]
        II["Information<br>Interoperability"]
        AI["Application<br>Interoperability"]
    end

    subgraph PHASE_D["Phase D — Technology"]
        TI["Technical<br>Interoperability"]
    end

    BI -->|"defines process boundaries<br>for data sharing"| II
    II -->|"data contracts drive<br>application integration"| AI
    AI -->|"integration patterns drive<br>platform requirements"| TI

    class BI business
    class II,AI application
    class TI technology

What it looks like: Business, Data/Application, and Technology Architecture teams work in parallel sprints, synchronizing at defined intervals rather than handing off sequentially.

Works when: The program is large enough to staff three parallel workstreams, and the Architecture Vision is detailed enough to give each team clear guardrails.

Breaks when: Synchronization discipline is weak. Parallel workstreams that do not synchronize produce architectures that are individually coherent but collectively inconsistent — the cross-domain gap analysis then becomes a reconciliation exercise rather than a verification.

What it looks like: Instead of full BDAT deliverables, the team produces a lean set of architecture decisions and principles, delegating detail to delivery teams.

Works when: Delivery teams are experienced, the program is incremental, and governance can catch deviations early.

Breaks when: The program spans multiple delivery teams or system integrators. Without explicit architecture deliverables, each team makes locally rational decisions that are globally inconsistent. This is the most common cause of integration failures in large multi-vendor programs.

What it looks like: An industry or vendor reference architecture — SAP, Salesforce, Azure Landing Zone — is adopted as the Phase B–D baseline, with gaps identified relative to that reference.

Works when: The reference architecture genuinely fits the business model and the organization has the discipline to adopt standard processes over customization.

Breaks when: The reference architecture is used to justify technology selection that precedes business requirements definition — the reference becomes a vendor sales tool dressed as enterprise architecture.

Phases B, C, and D are where the architecture either earns its keep or reveals its gaps. The sequencing is not arbitrary — business requirements drive information systems requirements, which drive technology requirements. Reversing or collapsing that sequence produces architectures optimized for vendor familiarity or delivery speed at the cost of long-term coherence.

Three disciplines separate programs that execute these phases well from those that do not. First, the gap analysis within each phase must be completed before the next phase begins — target states without gap analysis produce roadmaps with no execution logic. Second, the cross-domain gap analysis must be completed before Phase E — three individually coherent architectures that are mutually inconsistent are worse than one incomplete architecture, because the inconsistencies are invisible until implementation. Third, interoperability requirements must be tracked from Phase B through Phase D continuously — treating them as a Phase D integration problem guarantees that the decisions determining integration complexity have already been made without integration in mind.

Part 3 picks up at the transition from architecture definition into delivery. With domain architectures complete and gap analysis consolidated, Phases E through H govern solution selection, migration planning, implementation oversight, and architectural change management. That is where the architecture either holds under delivery pressure or quietly dissolves into a set of diagrams nobody references.