Foundation introduces Baseline, Target and Transition Architectures. The Practitioners’ Approach adds a fourth state and explains why the mix of states is the heart of the repository’s information problem.
The EA Landscape holds architectures in four states:
| State | What it is | Why it matters |
|---|---|---|
| Current | What exists today; the baseline | The reference point for all change and the basis of all gap analysis |
| Target | What the stakeholders have approved | The reference point for governing all change |
| Transition | Targets that are partially realised, lying between current and target | Interim states the enterprise moves through on its roadmap |
| Candidate | Produced by the EA team, but not approved to the point where it may govern change | Used for exploring options and trade-offs only |
Transition and candidate states create the most complexity. Add the Landscape’s characteristics (breadth, depth, time and recency), the way states change over time, and several projects working on the same subject, and the variability becomes the core of the information problem. The guide’s response is to minimise ruthlessly the information maintained and make the most of decision records.
A practical way to organise states
The guide describes an example repository arrangement:
- a single, shared current state description, refreshed periodically, which is the basis of all gap analysis; its governance test is that it reasonably represents what exists;
- a consolidated target plus several transition states; when an Architecture Project closes, its descriptions are merged into the consolidated target, which is also used in gap analysis;
- a separate container for every Architecture Project, where candidate options and trade-offs can be explored without affecting anyone else;
- supporting documents that state their own state and recency (where they sit on the timeline); without this they become noise.
Models are taken only as far as the current decision needs; any further detail is produced in a later cycle once that decision is made. The Foundation distinction between draft and approved outputs still applies: an approved output can continue to evolve, but only through change control. Until stakeholders approve it, a candidate is in the guide’s words only a documented opinion and cannot govern implementation (see Chapter 6, Trade-offs and the Steps Common to Every Phase). Figure 3.1 shows this arrangement and how a candidate becomes part of the Target.
Recency and the superior architecture
The guide calls assessing recency the pulse of an Architecture Project. Before relying on earlier work, the practitioner looks at what is being developed in parallel, which targets are being realised and which are approved, and how that affects prior work. Once earlier work has been reviewed and reaffirmed or replaced, its recency is effectively reset. The approved, less detailed superior architecture then guides and constrains the new work (see Chapter 2, Governance, Compliance and the Architect’s Role).
Common trap: A well-developed candidate architecture can be used to govern a project while approval is pending - only an approved Target governs change; a candidate is for exploration and trade-off.