Architecture States

TL;DR

In TOGAF, architecture is managed as time-based states: where you are now (Baseline), where you want to go (Target), and any approved intermediate steps (Transition Architectures).

TOGAF Architecture States infographic

Why architecture states matter

Architecture is not static. It is a snapshot at a point in time.

In TOGAF, states are differentiated by three things:

point in time
stakeholder approval status
value realization

When organizations change, architects need to answer:

What is the current state?
What future state is approved?
Do we need intermediate states to reduce risk?

State	What it means	Stakeholder approval	Value realization
Baseline Architecture	Current state (as-is) of the enterprise architecture	already in operation	current value is already being delivered
Target Architecture	Approved future state (to-be) to be achieved	approved	expected future value
Transition Architecture	Intermediate future state on the path to target; an architecturally significant interim point in time	approved	partial value delivered earlier
Architecture Alternatives (practical planning term)	One or more future options evaluated before selecting a target	under evaluation	potential value only
Resting State (practical planning term)	A stable operating point where change can pause while value continues	accepted operating state	value continues even if change is paused

Note

Baseline, Target, and Transition are the primary TOGAF architecture states used in planning and roadmaps. Architecture alternatives and resting state are practical planning concepts used by many teams.

Baseline and target are the core pair

These two states define the direction of change:

Baseline: where we are now
Target: where we want to be

Everything else supports movement between these two.

When to use transition architectures

You use transition states when “big bang” change is too risky or impractical.

Common reasons:

budget or time constraints
high delivery risk
technical dependencies
business readiness limits

A transition architecture should still be a usable, value-producing state — not just half-finished design work.

Architecture alternatives

Before finalizing a target architecture, teams often evaluate multiple candidate options.

Example options could differ by:

cloud strategy
integration pattern
buy vs build application choices
rollout model

After evaluation and stakeholder approval, one alternative becomes the target architecture.

Resting state

Sometimes programs pause due to budget cycles, mergers, regulation, or priority shifts.
A resting state defines a stable point where operations can continue and still deliver business value until change resumes.

Example: A bank completes Phase 1 of a core banking migration. The new payments module is live, but legacy lending still runs on the old system. This interim state is stable enough to operate while the next phase is planned and funded. That is a resting architecture.

Practical flow

flowchart LR
    B["Baseline<br/>(as-is)"]
    E{"Evaluate<br/>Candidates"}
    C1["Candidate A"]
    C2["Candidate B<br/>(approved)"]
    T["Target Architecture<br/>(to-be)"]
    TR1["Transition 1<br/>(interim stable state)"]
    TR2["Transition 2<br/>(interim stable state)"]

    B --> E
    E --> C1
    E --> C2
    C1 -. "not selected" .-> T
    C2 -->|"approved as target"| T
    B --> TR1 --> TR2 --> T

Step by step:

Document Baseline Architecture.
Define multiple architecture alternatives (if needed).
Select and approve one as the Target Architecture.
Plan one or more Transition Architectures.
Move through transitions until target is reached.

In TOGAF’s Architecture Development Method (ADM), these states are reflected in baseline/target definition and migration roadmap planning.