Phases and Purpose of the Architecture Development Method Cycle

Welcome. This module moves from TOGAF concepts to the method that organizes architecture work: the Architecture Development Method, or ADM. Today you will learn the order of its phases and what each contributes. Think of this as a map, not yet a detailed set of instructions. Later lessons will examine the individual phases and how architects adapt the method in practice.

By the end, you should be able to look at an activity—such as defining a business architecture, planning a migration, or reviewing an implementation—and place it in the right part of the ADM cycle.

What the ADM is for

An enterprise architecture describes how an organization is structured and how its different parts should work together to meet its goals. The ADM is TOGAF’s method for developing that architecture and managing it through change. It helps an organization move from understanding a need, through defining a desired architecture, to planning and governing its realization. It also provides a way to respond when circumstances change.

Start with a short excerpt from the TOGAF Standard, 10th Edition. This is an accessible sample, not the full Standard; the lesson supplies the phase-level explanation you need.

Two features of that description matter. First, the ADM covers a lifecycle, not merely the production of a design document. Second, although its phases have a logical order, their work is not sealed into one-way compartments. An output drafted early can be refined later.

Read the shape of the cycle

The following diagram is worth learning as a map of purposes. The Preliminary Phase sits above the lettered cycle. Phases A through H run around it. Requirements Management sits in the center because requirements must be considered throughout, rather than only at one stop along the way.

A brief video gives you a spoken tour of the same structure. Use it to hear the phase names in order; we will make the distinctions between them more precise below.

There is a useful caution here: logical sequence does not mean rigid waterfall. The cycle shows what kinds of questions architecture work must answer. If work in a later phase exposes a problem with an earlier assumption, architects may revisit that assumption. For Foundation preparation, learn the phase names and their usual progression first; later in the course, you will study iteration more closely.

Establish the work, then define the architecture

Before beginning a particular architecture effort, an organization needs a way to do architecture work. That is the overall concern of the Preliminary Phase. It prepares the enterprise architecture capability: for example, the organization establishes how architecture will be governed, which principles will guide decisions, and how it will use or tailor the method. The Preliminary Phase is not simply “Phase A with a different name.” It concerns the conditions under which architecture work can be carried out.

Phase A — Architecture Vision begins a particular architecture development cycle. Here the emphasis shifts to a proposed change: What problem or opportunity is being addressed? What is in scope? Who has a stake in the outcome? What high-level future direction is worth pursuing? Phase A establishes a shared vision and seeks authorization for the architecture work. The vision is deliberately high-level; the detailed architecture is developed in subsequent phases.

The next three phases develop the architecture across distinct domains:

• Phase B — Business Architecture considers how the business operates: its capabilities, processes, organization, and related business arrangements. Its question is, broadly, what must the business be able to do, and how should it operate?
• Phase C — Information Systems Architectures covers Data Architecture and Application Architecture. Data Architecture addresses the data the enterprise needs and how it is structured and managed. Application Architecture addresses the applications and their interactions in support of the business.
• Phase D — Technology Architecture addresses the technology services and infrastructure needed to support the applications and data—for example, computing platforms and networks.

These phases can compare a baseline (what exists) with a target (what is intended). A gap between them helps reveal what must change. The domain order is meaningful: a proposed technology platform should support the needed information systems, which should support the intended business operation. But the relationship also works in the other direction during analysis: a discovery about feasibility or constraints in one domain can require revisiting another.

Notice the counting trap. There are four architecture domains—Business, Data, Application, and Technology—but they occupy three lettered phases, B through D, because Phase C contains both Data and Application Architecture.

Find a feasible route and govern its realization

A target architecture describes a desired state; it does not, by itself, tell an organization how to reach it. The ADM therefore changes emphasis after Phase D.

Phase E — Opportunities and Solutions identifies plausible ways to realize the target. It brings together changes found across the architecture domains and considers implementation options, groups of work, and possible intermediate states. Its central question is: What work could take us toward the target, and through what feasible route?

Phase F — Migration Planning turns those possibilities into a more settled plan. It considers priorities, dependencies, resources, and timing to produce an Implementation and Migration Plan. One distinction to retain is that Phase E identifies and shapes the route; Phase F prioritizes and plans the journey in more detail. Planning does not first appear in F—Phase E already begins to consider implementation—but F is where migration planning is brought to completion.

The next two phases keep architecture relevant as change happens:

Phase G — Implementation Governance provides architectural oversight while solutions are implemented. The concern is whether implementation remains consistent with the agreed architecture and its requirements, and how to handle deviations. Phase G does not mean that the architecture team personally builds every system or runs every project; it governs implementation from an architecture perspective.

Phase H — Architecture Change Management considers the architecture’s continued fitness as the environment changes. Are the intended benefits being realized? Have new needs, constraints, or opportunities emerged? Does the existing architecture need an adjustment, or is further architecture work required? Phase H is not just an administrative “finish” to the cycle. It is part of keeping the architecture useful over time and can prompt a new cycle.

Throughout all of this runs Requirements Management. A requirement is a need or condition the architecture must address. Such needs may be discovered, clarified, or changed in any phase. That is why Requirements Management appears at the center of the diagram rather than between two lettered phases. For now, remember its continuous position and purpose; a later lesson will cover how requirements are recorded, traced, prioritized, and controlled.

Follow one change through the map

Suppose an organization wants customers to complete a service application more quickly, without losing necessary checks. This one objective touches several parts of the enterprise, so “install a faster application” is not yet an adequate architecture response.

The Preliminary Phase provides the established way to conduct and govern architecture work. In Phase A, architects clarify the desired outcome, the scope of the effort, and whose concerns must be considered. Phase B examines the current application-handling process and the business operation needed to improve it. Phase C examines the data required for decisions and the applications that capture, exchange, and use that data. Phase D examines whether the underlying technology can support those arrangements.

With a target better understood, Phase E considers feasible sets of changes: perhaps some process changes can deliver value early, while application changes depend on data improvements. Phase F orders the work into a workable migration plan. During Phase G, implementation is checked against the agreed architecture. In Phase H, the organization monitors whether the changed service still meets its objectives and considers new pressures on the architecture. If a requirement changes at any point—for example, the checks that must be performed—Requirements Management ensures that the change is considered across the affected architecture work.

The example shows why the ADM is more than a list of design specialties. Each phase contributes a different answer to one connected change problem. The architecture domains explain what must work together; the later phases address how to realize and sustain the intended change.

For a quick memory check, look away from the diagram and reconstruct the cycle in four groups: prepare (Preliminary), set direction and define (A–D), plan and govern realization (E–G), and manage ongoing change (H). Then place Requirements Management across all four groups. If you can do that while naming each lettered phase, you have the map needed for the detailed lessons ahead.

Key takeaways

The ADM is TOGAF’s method for developing and managing the lifecycle of an enterprise architecture. Its logical sequence is Preliminary; A Architecture Vision; B Business Architecture; C Information Systems Architectures; D Technology Architecture; E Opportunities and Solutions; F Migration Planning; G Implementation Governance; and H Architecture Change Management. Requirements Management operates continuously across the cycle. The sequence gives architecture work structure without requiring every real initiative to proceed in a rigid, one-pass line.

Next, you will look more closely at the Preliminary Phase: what an organization needs to put in place before architecture work can operate effectively.