TOGAF ADM: Architecture Development in Practice

The TOGAF Architecture Development Method is often drawn as a cycle of phases, but the diagram is not the method. The real value of the ADM is that it gives architecture work a repeatable decision structure while allowing iteration, tailoring, and feedback as the enterprise learns more about its goals and constraints.

The current TOGAF Practitioner expects candidates to apply the TOGAF Standard rather than merely recognize terminology. Practitioner competence includes using the ADM to develop, sustain, and transform architectures, tailoring the method, applying iteration and partitioning, and connecting architecture work to governance and change.

Treating the ADM as a linear checklist creates weak architecture. Treating it as a structured way to make and govern decisions produces a more realistic operating model.

Preliminary work creates the architecture capability

Before a specific transformation begins, the organization needs an architecture capability: roles, principles, governance, repository conventions, decision rights, and a tailored way of applying the TOGAF Standard. The Preliminary Phase addresses that foundation.

This matters because architecture methods do not execute themselves. If stakeholders do not know who approves principles, how exceptions are handled, or where reusable assets are stored, later phases produce documents without authority.

Tailoring starts here. A regulated bank, a digital startup, and a government program can all use the ADM, but the governance, evidence, cadence, and artifacts appropriate to each will differ.

Phase A aligns the effort around an Architecture Vision

Architecture Vision establishes why the work exists, which stakeholders matter, what scope is included, and what outcomes the architecture should enable. It is where broad business drivers become an architecture engagement that people can support or challenge.

A weak vision is technology-led and vague: “move to cloud,” “modernize the platform,” or “improve data.” A stronger vision explains which capabilities or outcomes must change, what constraints matter, and how success will be recognized.

The vision also creates a contract for scope. Without it, later architecture work can expand until every enterprise problem becomes part of one initiative.

Phases B, C, and D develop domain architectures

Business Architecture, Information Systems Architectures, and Technology Architecture explore different but connected aspects of the target state. The sequence gives structure, but real work often iterates among them because a decision in one domain changes assumptions in another.

A business capability may require new information flows. A data choice may create technology constraints. A platform limitation may force a different process. The ADM expects architects to manage those interactions rather than pretend each domain can be completed independently.

The OGEA-103 tests this integrated practitioner reasoning through both knowledge and scenario-based application.

Gap analysis turns descriptions into change

Baseline and target architectures matter because the difference between them defines change. Gap analysis identifies missing capabilities, redundant elements, work that can be retired, and areas where the target requires new behavior.

The analysis should be specific enough to drive decisions. “Improve integration” is not a useful gap. “Replace point-to-point order integrations with an event contract owned by the order domain” begins to describe architecture work that can be planned and governed.

Gaps also reveal dependencies. A target technology cannot deliver value if the required operating model, skills, data quality, or governance remain unchanged.

Phases E and F turn architecture into a viable roadmap

Opportunities & Solutions groups changes into meaningful work packages and considers transition architectures. Migration Planning then prioritizes and sequences those changes so the roadmap reflects value, dependencies, risk, and delivery capacity.

This is where architecture confronts feasibility. A perfect target state that requires every legacy system to change at once is not a useful roadmap. Transition architectures let the enterprise move in stages while keeping each intermediate state operable.

Architecture also has to coexist with portfolio and product planning. The roadmap should inform investment decisions without becoming a second project-management system.

Phase G connects delivery with architecture governance

Implementation Governance helps ensure delivery remains aligned with agreed architecture. That does not mean architects approve every technical decision. It means material deviations, risks, and architecture contracts are visible and managed through appropriate governance.

Governance should distinguish intentional adaptation from unmanaged drift. Delivery teams may discover better options or new constraints. The architecture process needs a way to assess those findings and update decisions when evidence justifies change.

The Open Group emphasizes architecture as a practiced discipline, which is why governance is part of the method rather than an afterthought.

Phase H keeps architecture relevant after delivery

Architecture Change Management recognizes that the enterprise does not stop changing after a roadmap finishes. New regulation, products, technology, risks, acquisitions, and operating data can invalidate assumptions in the target state.

The organization therefore needs triggers for architecture change. Some changes can be handled through normal governance; others justify a new ADM cycle or a significant revision of existing architecture.

This prevents architecture from becoming a static document set. A living architecture capability observes change and decides when the current guidance is no longer sufficient.

Requirements Management runs through the whole method

Requirements are not collected once and frozen. They are discovered, refined, challenged, and sometimes changed as architecture work progresses. Requirements Management connects those changes across ADM phases and preserves traceability to stakeholder concerns and architecture decisions.

This continuous role explains why the ADM is iterative. A technology constraint discovered in Phase D may change a requirement that affects Business Architecture. A migration dependency may require revisiting the target or accepting an interim state.

The strongest way to prepare for the ADM is to follow one transformation end to end and ask what decision each phase is trying to make, what evidence it needs, and which earlier assumptions might need to be revisited. That turns the ADM from a diagram into a working architecture method.

Iteration and partitioning keep the ADM usable at enterprise scale

Large organizations rarely run one ADM cycle for the entire enterprise at the same level of detail. Architecture work is partitioned by scope, domain, product, geography, capability, or change initiative, and those partitions must remain coherent. Enterprise-level direction may establish principles and target capabilities while solution or domain architecture develops more detailed decisions.

Iteration occurs within phases, between phases, and across architecture cycles. Stakeholder feedback can require revisiting the Architecture Vision. Technology findings can change a business or information-system assumption. Migration planning can expose a dependency that makes the target sequence unrealistic. Returning to earlier reasoning is not failure; it is the method responding to better information.

The architect needs to distinguish productive iteration from endless reconsideration. Decision criteria, scope, governance gates, and traceability help the team know when new evidence is material enough to reopen a choice. Otherwise the ADM can become a loop with no commitment, or the opposite problem: a rigid sequence that ignores facts discovered later.

Partitioning and iteration are therefore practical controls. They let different architecture teams work at appropriate depth while preserving alignment, and they let the method adapt as understanding improves without abandoning governance.

Architecture artifacts should also be managed as a connected body of knowledge rather than isolated phase deliverables. Principles, requirements, capability models, target-state views, building blocks, roadmaps, and governance decisions should be traceable enough that a change in one area can reveal downstream impact. A repository is useful when it supports that reuse and traceability, not merely because every document has a storage location.

The ADM also works alongside delivery methods rather than competing with them. Agile product teams can provide rapid discovery and implementation feedback while architecture maintains enterprise-level constraints, shared capabilities, standards, and cross-product dependencies. The method must be tailored so architecture decisions arrive early enough to guide delivery without turning every iteration into an approval queue.

This is the practitioner-level point behind the method: the ADM is a governance and learning system for architecture change. Its phases make decisions explicit, its iterations absorb evidence, and its governance keeps local delivery aligned with broader enterprise outcomes.

Architecture decisions should also record alternatives and rationale. When teams revisit a choice months later, the value is not only knowing what was selected but why other options were rejected under the constraints that existed at the time. This turns the ADM into organizational memory and prevents repeated debates when the same trade-off reappears.

Finally, architecture work should define when a decision is sufficiently complete to move forward. Perfect information is rarely available. The ADM supports responsible commitment by making assumptions, risks, constraints, and governance visible so delivery can proceed while uncertain areas remain subject to review.

The method becomes easier to apply when each phase has a clear decision owner and exit question. Architecture work can otherwise produce many artifacts without reaching an explicit commitment. Defining what must be understood, who decides, and what evidence is sufficient gives each cycle momentum while preserving the ability to revisit assumptions when new information is material.

Architecture debt should be visible inside that governance model. A transition decision may intentionally accept a temporary duplication, manual control, or non-standard platform. Recording the reason, owner, and expected retirement condition keeps temporary compromises from becoming permanent architecture by accident.