The Architecture Development Method

Overview

The Architecture Development Method (ADM) is the core process in TOGAF. It is a generic, iterative method to be configured for the organization and the architecture engagement.

flowchart TB
    P[Preliminary]
    A[A: Architecture Vision]
    B[B: Business Architecture]
    C[C: Information Systems<br/>Data and Applications]
    D[D: Technology Architecture]
    E[E: Opportunities and Solutions]
    F[F: Migration Planning]
    G[G: Implementation Governance]
    H[H: Architecture Change Management]
    R((Requirements<br/>Management))

    P --> A --> B --> C --> D --> E --> F --> G --> H
    H --> A
    R --- A
    R --- B
    R --- C
    R --- D
    R --- E
    R --- F
    R --- G
    R --- H

The sequence is a thinking model, not a prohibition on iteration. Depending on scope, teams may:

revisit earlier work after new evidence;
combine phases;
run data and application work in parallel;
perform only a partial cycle;
run cycles at enterprise, portfolio, product, and solution levels; or
use short architecture increments aligned with delivery.

Before the cycle: request and context

Architecture work is commonly triggered by strategy, performance problems, regulation, a major investment, technology obsolescence, merger, risk, or a formal request. Before detailed work, clarify:

sponsor and decision authority;
business outcome and urgency;
scope and constraints;
existing architecture and change initiatives;
available people and evidence; and
what decision the work must enable.

Preliminary Phase

Purpose

Establish how the organization will perform and govern Enterprise Architecture. This may be done once for a new capability and revisited as it matures.

Key activities

define the enterprise and organizational scope;
assess architecture capability and maturity;
identify existing methods, frameworks, and governance;
tailor the ADM and content approach;
define roles, responsibilities, and decision rights;
establish principles;
choose tools and repository structure;
integrate architecture with strategy, portfolio, delivery, procurement, security, risk, and operations; and
issue the request for architecture work.

Typical outputs

tailored architecture framework;
organization model for Enterprise Architecture;
architecture principles;
governance and repository arrangements; and
initial request for architecture work.

Exit test

The organization knows who performs architecture, how decisions are made, what method will be used, and where controlled architecture content lives.

Phase A: Architecture Vision

Purpose

Align stakeholders on the problem, intended outcome, scope, value, and approach, and obtain authorization for the architecture engagement.

Key activities

confirm drivers, goals, constraints, and readiness;
identify stakeholders, concerns, influence, and communications;
define scope, breadth, depth, time horizon, and architecture domains;
assess business capabilities and transformation readiness at a high level;
create a concise baseline and target vision;
identify risks and high-level requirements;
develop the value proposition and success measures; and
agree the Statement of Architecture Work.

Typical outputs

Architecture Vision;
stakeholder map and communications plan;
draft Architecture Definition Document;
draft Architecture Requirements Specification;
capability assessment;
approved Statement of Architecture Work; and
updated repository and risk log.

Exit test

Sponsors and key stakeholders agree on why the work matters, what it covers, what success means, and how the work will proceed.

Phase B: Business Architecture

Purpose

Describe how the enterprise must operate to achieve the vision.

Areas examined

business strategy and goals;
operating model;
capabilities;
value streams and customer journeys;
organization and actors;
business services and products;
processes and events;
policies, controls, information needs, and measures.

Key activities

Select relevant viewpoints and techniques.
Describe the baseline to the necessary level.
Develop the target Business Architecture.
Analyze gaps.
Identify roadmap components and impacts.
Resolve conflicts and validate with stakeholders.
Update requirements and architecture documents.

Exit test

The target operating model and required business changes are clear enough to guide information-system architecture and planning.

Phase C: Information Systems Architectures

Phase C normally includes Data Architecture and Application Architecture. Their order is contextual and they may be developed iteratively or in parallel.

Data Architecture

Define the major data entities, meaning, ownership, lifecycle, quality, security, location, movement, and governance needed by the business.

Important questions:

What information is critical to each capability and decision?
Who is accountable for it?
What is the authoritative source?
How is it shared, retained, protected, and disposed?
Where do definitions or records conflict?

Application Architecture

Define the application services and systems needed to process and expose information and support business capabilities.

Important questions:

Which application services support which capabilities?
What should be retained, invested in, replaced, consolidated, or retired?
What interactions and interfaces are required?
Where are responsibilities duplicated or missing?

Exit test

Data and application target states, gaps, dependencies, and roadmap candidates are coherent with the Business Architecture.

Phase D: Technology Architecture

Purpose

Define the technology environment needed to realize the data and application architectures.

Areas examined

platform and infrastructure services;
compute, storage, networks, and edge;
cloud and hosting models;
runtime, middleware, integration, and observability;
endpoint and workplace technology;
identity, security, resilience, and operations;
technology standards, lifecycle, and obsolescence.

Avoid turning the phase into a product shopping list. Describe needed services, quality attributes, standards, and constraints before choosing specific solutions.

Exit test

The target technology services and standards are feasible, secure, operable, and traceable to business and information-system needs.

Phase E: Opportunities and Solutions

Purpose

Integrate the domain architectures and identify practical packages of change.

Key activities

reconcile business, data, application, and technology gaps;
identify dependencies and implementation constraints;
group changes into work packages;
identify reusable solution building blocks;
determine whether transition architectures are required;
evaluate build, buy, reuse, partner, and retire options;
assess readiness, benefits, costs, and risks at a high level; and
draft the Architecture Roadmap and implementation strategy.

Exit test

There is a coherent set of work packages and transition states capable of realizing the target architecture.

Phase F: Migration Planning

Purpose

Turn the candidate roadmap into an agreed, prioritized, resourced, and viable Implementation and Migration Plan.

Key activities

confirm dependencies and value;
estimate cost, benefit, effort, and risk;
prioritize work packages;
align with portfolio and financial planning;
define transition states and release increments;
assign owners and measurable outcomes;
update the business case; and
obtain approval for the roadmap.

Prioritization should be transparent. A simple score can combine strategic fit, value, urgency, risk reduction, cost, and dependency enablement, but judgment remains necessary.

Exit test

The roadmap is funded or fundable, sequenced, owned, and integrated with the organization’s delivery and portfolio mechanisms.

Phase G: Implementation Governance

Purpose

Help delivery realize the intended architecture while handling legitimate learning and change.

Key activities

agree Architecture Contracts or equivalent commitments;
connect architecture requirements to delivery controls;
perform compliance reviews at meaningful decision points;
advise implementation teams;
assess deviations, risks, and architecture debt;
approve, reject, or time-limit exceptions;
update architecture and repository content; and
confirm that implemented solutions are fit for purpose.

Governance should not be a late design tribunal. Architects should engage early and make review evidence proportionate to risk.

Exit test

Implementation outcomes, deviations, and residual risks are known and accepted by the right authorities.

Phase H: Architecture Change Management

Purpose

Monitor the environment and architecture, realize value, and decide when change requires maintenance or a new ADM cycle.

Change sources

strategy or operating-model changes;
customer and market signals;
new regulation or risk;
delivery learning;
performance and incident trends;
technology lifecycle or innovation;
architecture debt; and
benefits-realization evidence.

Change responses

Change magnitude	Likely response
Small and within existing architecture	Managed maintenance
Material but bounded	Partial ADM cycle
Strategic or cross-enterprise	New ADM cycle

Exit test

The architecture remains useful, monitored, and connected to actual outcomes rather than becoming a historical snapshot.

Requirements Management

Requirements Management is continuous, not a final phase.

flowchart LR
    E[Elicit] --> A[Analyze]
    A --> P[Prioritize]
    P --> T[Trace]
    T --> V[Verify]
    V --> C[Control change]
    C --> E

Maintain:

a unique identifier;
statement and rationale;
source and owner;
priority and status;
acceptance or verification method;
links to goals, architecture elements, work packages, and tests; and
change history.

Iteration dimensions

TOGAF recognizes several useful kinds of iteration:

between phases to refine understanding;
within a phase to explore alternatives;
over the whole ADM cycle as the enterprise changes; and
across levels and scopes where related architecture efforts interact.

Plan feedback points deliberately instead of pretending all information is available at the start.

Scoping an ADM cycle

Define scope along at least four dimensions:

breadth — which parts of the enterprise;
depth — how much detail;
time period — baseline and target horizons; and
domains — business, data, application, technology, and cross-cutting concerns.

Also state exclusions, assumptions, dependencies, and authority.

Common ADM mistakes

treating the cycle as a mandatory waterfall;
beginning with technology instead of outcome and stakeholder concern;
documenting the entire baseline regardless of relevance;
creating target diagrams without requirements or decisions;
leaving planning until after detailed architecture;
confusing governance with paperwork or centralized control;
failing to update the architecture from implementation evidence; and
running one giant cycle where smaller coordinated cycles would learn faster.

Next: Architecture domains