# 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.

```mermaid
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

1. Select relevant viewpoints and techniques.
2. Describe the baseline to the necessary level.
3. Develop the target Business Architecture.
4. Analyze gaps.
5. Identify roadmap components and impacts.
6. Resolve conflicts and validate with stakeholders.
7. 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.

```mermaid
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](03-architecture-domains.html)