TOGAF ADM in Practice — Part 1: Foundation and Architecture Vision

Executive Summary

Most TOGAF documentation functions as a reference manual. It describes the Architecture Development Method (ADM) with technical precision and says almost nothing about when to apply which phase, why the sequence matters, or what breaks when steps are skipped. This white-paper: the first in a four-part series treats the ADM as a practitioner would encounter on a real program with tradeoffs, failure modes, and judgment calls that don’t appear in the standard.

Part 1 covers the foundation: what the ADM actually is, the Preliminary Phase and Phase A: Architecture Vision. These are the phases most teams either rush past or misapply entirely, and they set the ceiling for everything that follows. Parts 2 and 3 carry the method through domain architecture and delivery. Part 4 synthesizes recommendations across the full cycle.

Context

Enterprise architecture frameworks accumulate a reputation problem over time. The more comprehensive they become, the more they read like certification material rather than practitioner guidance. TOGAF is the dominant framework in the field and is not immune to this pattern. Organizations adopt it, stand up EA practices, and then struggle to translate hundreds of pages of structured methodology into coherent decisions on active programs.

The gap is not in the framework. TOGAF is explicit that its concepts are universal, however, its techniques are not while the method is a reasoning scaffold and not a process template. The gap is in how the framework is applied. Teams treat phase sequences as checklists, skip foundational phases under delivery pressure, and then attribute the resulting architectural drift to the framework rather than to the application of it.

This series addresses that gap directly. The audience is architecture practitioners and technical stakeholders who already know what TOGAF is and want applied guidance on how it plays out in real implementations: what to invest in, what to right-size and where the leverage actually sits.

The Series Structure

This whitepaper is Part 1 of four. The series is structured to follow the ADM as a practitioner would encounter it across a real program lifecycle.

Part	Title	ADM Focus	Connects To
Part 1	Foundation — What the ADM Actually Is	Preliminary Phase + Phase A (Architecture Vision)	Sets up the “why” before the “how”
Part 2	Building the Architecture — Domains and Decisions	Phases B, C, D (Business, Information Systems, Technology)	Picks up from Part 1’s Vision output
Part 3	From Blueprint to Reality — Transition and Delivery	Phases E, F, G, H + Change Management	Picks up from Part 2’s Target Architectures
Part 4	Recommendations — What Actually Works	Synthesis across all phases	Caps the full series

Each part is self-contained but explicitly connected. Part 2 opens where Part 1 closes. Part 3 opens where Part 2 closes. Part 4 does not introduce new framework content — it synthesizes judgment from the full cycle.

Analysis

What the ADM Is and What It Isn’t

The ADM is a method, not a process template. That distinction matters more than it sounds.

TOGAF provides concepts that are universal. The techniques, templates, and sequences are examples — starter sets, not mandates. The practitioner implication is direct: use the same concept, not the same technique, not the same template, not the same process. The same concept.

In practice this means:

A repository is a universal concept. Whether it is a SharePoint folder, a Confluence wiki, or an enterprise modeling tool is an implementation decision.
An Architecture Vision is a universal concept. Whether it is a 40-slide deck or a two-page brief depends on organizational maturity and scale of change.
Governance is a universal concept. The mechanism — review boards, lightweight approval gates, or embedded squad rituals — is context-dependent.

Teams that treat TOGAF as a checklist fail. Teams that treat it as a reasoning framework succeed.

The ADM Cycle

flowchart TD
    classDef prelim fill:#fff3e0,stroke:#e65100
    classDef vision fill:#e8f5e9,stroke:#2e7d32
    classDef arch fill:#e3f2fd,stroke:#1565c0
    classDef delivery fill:#f3e5f5,stroke:#6a1b9a

    P["Preliminary Phase<br>(Framework & Principles)"]
    A["Phase A<br>Architecture Vision"]
    B["Phase B<br>Business Architecture"]
    C["Phase C<br>Information Systems Architecture<br>(Data + Application)"]
    D["Phase D<br>Technology Architecture"]
    E["Phase E<br>Opportunities & Solutions"]
    F["Phase F<br>Migration Planning"]
    G["Phase G<br>Implementation Governance"]
    H["Phase H<br>Architecture Change Management"]
    RM["Requirements Management<br>(Central — continuous)"]

    P --> A
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H -->|"triggers new cycle"| A
    RM <-->|"feeds all phases"| A
    RM <-->|"feeds all phases"| B
    RM <-->|"feeds all phases"| C
    RM <-->|"feeds all phases"| D

    class P prelim
    class A vision
    class B,C,D arch
    class E,F,G,H delivery

The cycle is iterative, not waterfall. Phases do not have to proceed strictly in sequence — Segment Architectures can start as soon as relevant areas are identified, and Capability Architectures can run in parallel sprints.

This is where most teams fail in Year 1: they treat the ADM as a gate-by-gate waterfall and then blame the framework when delivery stalls. The ADM’s iterative nature is not a workaround — it is the design. Large programs cannot wait for a completed Technology Architecture before beginning delivery planning. Parallel workstreams, scoped per segment or capability, are the expected operating model.

The Preliminary Phase — The Work Everyone Skips

The Preliminary Phase answers one question before architecture work begins: are we set up to do this properly?

It establishes:

Scope of the enterprise affected by the architecture effort
Governance and support from the leadership needed to enforce architectural decisions
Architecture principles — the standing rules that govern every decision in every subsequent phase
The EA capability itself — tools, team structure, and repository approach

Why This Phase Gets Skipped

Organizations under delivery pressure want to jump to Phase A or directly to Phase B. The reasoning is predictable: we know what we’re building, let’s get started.

The failure mode is equally predictable. Architecture principles get invented mid-program to justify decisions already made. Governance has no teeth because it was never formally established. The repository becomes a documentation graveyard because no one agreed on its purpose upfront. These are not edge cases — they are the default outcome when the Preliminary Phase is treated as optional.

Architecture Principles — The Highest-Leverage Preliminary Output

Principles are not values statements. They are decision-making instruments with real consequences.

A well-formed architecture principle has four components:

Component	Purpose	Example
Name	Short, memorable reference	”Data is an Enterprise Asset”
Statement	The rule itself	”Data is managed as a shared enterprise resource, not owned by individual applications”
Rationale	Why this principle exists	”Siloed data ownership creates integration debt and blocks cross-functional analytics”
Implications	What this requires architecturally	”All master data must have a defined system of record; application-local data stores require justification”

Principles operate in a hierarchy: Enterprise Principles → Architecture Principles → Segment-specific principles. Subsidiary principles cannot contradict those above them.

In real implementations, this hierarchy is the arbitration mechanism when two teams disagree about an architectural decision. Without documented principles, every disagreement becomes political. With them, the principles decide. The investment in the Preliminary Phase is largely an investment in making that arbitration function work without escalation.

Phase A — Architecture Vision

Phase A is where the scope, stakeholders, and direction of the architecture effort are formally established. Its output — the Architecture Vision — is the reference point for every subsequent phase.

What Phase A Produces

Statement of Architecture Work — the agreed scope and approach, signed off by sponsors
Architecture Vision document — a high-level view of the future state and the value it delivers
Stakeholder map and concern register — who cares about what, documented explicitly
First-cut constraints — time, budget, organizational boundaries, regulatory requirements

The Architecture Vision in Real Programs

The Vision document has one job: create enough shared understanding among stakeholders that subsequent phases can proceed without relitigating scope.

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

    S1["Business Drivers<br>& Strategy"]
    S2["Stakeholder<br>Concerns"]
    S3["Existing Architecture<br>Baseline"]
    S4["Constraints &<br>Principles"]

    V["Phase A<br>Architecture Vision"]

    O1["Statement of<br>Architecture Work"]
    O2["Approved<br>Architecture Vision"]
    O3["Updated Principles<br>& Constraints"]
    O4["Input to<br>Phase B"]

    S1 --> V
    S2 --> V
    S3 --> V
    S4 --> V

    V --> O1
    V --> O2
    V --> O3
    V --> O4

    class S1,S2,S3,S4 input
    class V process
    class O1,O2,O3,O4 output

Pros and Cons of Investing Heavily in Phase A

	Detail
Pro	Stakeholder alignment before expensive architecture work begins
Pro	Explicit constraints prevent scope creep in Phases B through D
Pro	Vision document acts as the north star when phase outputs conflict
Con	Can become a prolonged stakeholder negotiation exercise — governance-heavy organizations overdo it
Con	In fast-moving programs, a detailed Vision can be stale by the time Phase B completes
Con	Risk of producing a Vision that reflects political compromise rather than architectural clarity

Right-Sizing Phase A Investment

Phase A depth should match the scale and novelty of the change:

Incremental program (single capability, known domain): lightweight Vision — two pages, focused stakeholder set, fast approval
Segment-level transformation (multiple business units, new platforms): full Vision with formal stakeholder review and signed Statement of Architecture Work
Enterprise Strategic Architecture (organization-wide, multi-year): Vision must be broad enough to establish context for all Segment and Capability Architectures below it

Getting this calibration wrong in either direction is expensive. An overbuilt Vision for an incremental program signals institutional dysfunction. An underbuilt Vision for a strategic transformation means every subsequent phase will be relitigating scope.

Alternate Approaches

Two common alternatives to the full ADM-from-Preliminary approach, and where they break down:

Skip Preliminary and Phase A, Jump Straight to Phase B

Context: Organizations with existing EA practices, known domain, experienced team.

Works when: Principles and governance are already mature and documented.

Breaks when: The program touches new stakeholders or crosses organizational boundaries. The missing Vision means no shared reference point when conflicts arise, and the missing principles mean those conflicts get resolved by seniority rather than by architecture.

Context: Startup-scale teams, small programs, co-located stakeholders.

Works when: All decision-makers are in the room daily and scope is genuinely bounded.

Breaks when: Stakeholder turnover occurs or the program expands. Undocumented agreements evaporate. The Architecture Vision is not bureaucratic overhead — it is institutional memory that survives personnel change.

Scoping the Architecture — The Four Dimensions

Before Phase A closes, four scoping decisions must be explicit. Leaving any of them implicit is a risk carried into every subsequent phase.

flowchart TD
    classDef dim fill:#e3f2fd,stroke:#1565c0
    classDef risk fill:#f3e5f5,stroke:#6a1b9a

    SC["Architecture Scope<br>— Four Dimensions —"]

    D1["Breadth<br>Which parts of the enterprise?"]
    D2["Depth<br>How much detail per domain?"]
    D3["Time Period<br>Baseline → Transition → Target"]
    D4["Domains<br>Business / Data / Application / Technology"]

    R1["Risk: Too broad →<br>architecture exceeds resources"]
    R2["Risk: Inconsistent depth →<br>cross-domain gaps"]
    R3["Risk: Moving target →<br>Transition Arch becomes unstable"]
    R4["Risk: Domain gaps →<br>interoperability failures later"]

    SC --> D1 --> R1
    SC --> D2 --> R2
    SC --> D3 --> R3
    SC --> D4 --> R4

    class D1,D2,D3,D4 dim
    class R1,R2,R3,R4 risk

On depth: the rule is sufficient for its purpose and no more. Inconsistent depth across domains is worse than uniform shallowness — it creates false confidence in the well-documented domains and invisible gaps in the under-documented ones.

On time period: the pattern of Baseline → Transition Architecture(s) → Target Architecture is the mechanism for managing delivery risk. Transition Architectures should not evolve during their implementation window. The moving-target failure mode — where the Transition Architecture keeps absorbing new requirements while teams are actively building against it — is the most common cause of program drift in large transformation programs.

On breadth: the instinct to scope broadly to be comprehensive is almost always wrong in Year 1. A narrower scope executed with depth and integrity builds more organizational trust in the EA practice than a wide scope executed superficially. Breadth can expand as the practice matures.

On domains: gaps between domains are more dangerous than gaps within them. An incomplete Business Architecture is a known risk. A Business Architecture and Technology Architecture that don’t connect — because the Information Systems layer was underspecified — is an invisible risk that surfaces during implementation.

Conclusion

Part 1 establishes the reasoning foundation for the series. The ADM is an iterative, judgment-driven method — its value is in the concepts it enforces, not the templates it provides. The Preliminary Phase and Architecture Vision are the highest-leverage, most commonly skipped work in enterprise architecture. The four scoping dimensions must be explicit before domain architecture work begins. And the right-sizing of Phase A investment is itself an architectural decision: calibrate it wrong and the cost is borne across every subsequent phase.

Three things to carry forward:

Principles before phases. No architecture work should begin without documented, hierarchical architecture principles. They are the arbitration mechanism for every decision that follows.
Vision before domains. Phase A is not a prologue — it is the governing document for Phases B through D. Skipping it does not accelerate the program; it defers the scope negotiation into the domain phases where it is far more expensive to resolve.
Scope explicitly across all four dimensions. Breadth, depth, time period, and domains must each be a conscious decision. Implicit scoping is deferred risk.

Part 2 picks up here. With Vision approved and scope locked, the architecture work moves into the domain phases — Business Architecture (Phase B), Information Systems Architecture (Phase C: Data and Application), and Technology Architecture (Phase D). That is where the architecture earns its keep or reveals its gaps. The domain phases are where the structural decisions get made, and where the tradeoffs between completeness and velocity become unavoidable.