TOGAF ADM for OGEA-103

The Architecture Development Method is the core operating model behind TOGAF Enterprise Architecture, and OGEA-103 candidates need to understand more than the names of its phases. The combined exam expects knowledge of the method in Part 1 and application of that method in Part 2. That means you should be able to recognize the purpose of a phase, explain its outputs and relationships, and decide how the ADM should respond when an architecture engagement changes direction.

The OGEA-103 exam expects candidates to treat the ADM as a decision system. The cycle connects a sequence of questions: Are we ready to do architecture? What are we trying to achieve? What should the business, information systems, and technology look like? How do we get there? How is implementation governed? What happens when circumstances change?

The Preliminary Phase establishes the capability to do architecture

Before an enterprise can run an ADM cycle effectively, it needs an architecture capability. The Preliminary Phase addresses the organization, governance, principles, methods, responsibilities, and tailoring needed to make the practice work in its context. Candidates sometimes treat this as administrative setup, but it determines who has authority, what standards apply, and how architecture work connects with other management disciplines.

In a scenario, signs of a Preliminary Phase problem include unclear architecture ownership, inconsistent methods across business units, no governance body, or a framework that has not been adapted to the organization. The correct response is usually not to rush into target-state modeling. It is to establish the capability and operating conditions that make later architecture work credible.

Phase A turns a request into an authorized Architecture Vision

Phase A clarifies scope, stakeholders, concerns, business goals, constraints, and the high-level vision. It also secures approval to proceed. This phase matters because architecture projects can fail before technical design begins if the scope is ambiguous or key stakeholders do not agree on outcomes.

For exam scenarios, watch for problems involving competing expectations, unclear boundaries, missing sponsors, or uncertainty about whether a proposed architecture effort should proceed. Phase A thinking asks what value the work should deliver and who must support it. The broader TOGAF 10th Edition framework helps place this activity in context, but the exam usually rewards the action that makes the engagement coherent and governable.

Phases B, C, and D build the domain architectures

Business Architecture, Information Systems Architectures, and Technology Architecture describe different dimensions of the enterprise. The important exam skill is not simply matching domain names. You need to understand that each domain moves from baseline understanding toward a target state, identifies gaps, and produces architecture content that supports later planning.

Phase B considers capabilities, organization, processes, value, and business behavior. Phase C develops data and application architecture. Phase D addresses technology services and infrastructure. Real work can iterate across these areas because a target business capability may require application changes that in turn depend on technology decisions. The ADM is structured, but it is not a rigid waterfall.

Requirements Management is continuous, not a final checkpoint

Requirements Management sits at the center of the ADM because requirements evolve as architecture understanding improves. A new stakeholder concern, regulatory constraint, or technical finding can affect work already in progress. The method therefore maintains requirements across phases rather than treating them as a document written once at the beginning.

In scenario questions, this matters when new information emerges. The right response is rarely to ignore the change because a previous phase is “complete.” Instead, assess the impact, update requirements, and determine which architecture work must iterate. This is one of the clearest examples of why ADM fluency requires understanding interaction rather than memorizing a linear sequence.

Requirements should be traceable to stakeholder concerns and architecture decisions. When one changes, candidates should ask which views, gaps, work packages, transition states, or compliance checks are affected. That traceability is what turns requirements management from a register into an active control on the architecture process.

Conflicting requirements also deserve explicit treatment. Architecture work often balances cost, speed, security, resilience, and standardization rather than satisfying each independently. The ADM provides a structure for making and governing those trade-offs, not a promise that every stakeholder preference will survive unchanged.

Phase E identifies solutions and packages the work

Opportunities and Solutions connects target architectures with implementation possibilities. The focus shifts from describing desired architecture to identifying major solution components, work packages, and transition architectures. This is where architecture begins to become an executable change portfolio.

A common error is to select products too early. Phase E is not permission to abandon architecture reasoning and jump to procurement. The architecture gaps, dependencies, principles, and requirements still shape the solution. If a scenario describes multiple possible work packages, think about how they contribute to the target and whether intermediate architecture states are required.

Phase F turns architecture options into a migration plan

Migration Planning prioritizes projects and work packages and aligns them with value, risk, cost, dependency, and organizational capacity. The best sequence is not always the technically cleanest one. Enterprises have funding cycles, operational constraints, regulatory deadlines, and change capacity that influence the roadmap.

Practice ranking work packages using explicit criteria. Then explain why one sequence should precede another. That habit makes Part 2 questions easier because several options may be technically valid while only one reflects a disciplined migration decision.

Phase G governs implementation against the architecture

Implementation Governance exists because an approved architecture can drift during delivery. Projects make design decisions, vendors introduce alternatives, deadlines create pressure, and new constraints appear. Architecture governance checks whether implementation remains conformant and manages deviations when it does not.

The key idea is that governance is active. It can include architecture contracts, compliance reviews, issue resolution, and controlled exceptions. If a scenario shows an implementation team departing from an agreed architecture, do not assume the architect should redesign everything or simply approve the change. Determine the governance path, assess the deviation, and protect the intended outcomes.

Phase H keeps architecture relevant after implementation

Architecture Change Management monitors whether the architecture remains fit for purpose and determines when change requires a new cycle. Not every operational change justifies a full architecture initiative, but significant strategic, technological, regulatory, or business shifts may require renewed architecture work.

This is where the ADM becomes cyclical. Architecture is not finished when a program goes live. The enterprise continues to change, so architecture capability needs mechanisms for monitoring, impact assessment, and deciding the appropriate level of response.

Iteration is a feature of the ADM

The ADM supports iteration within phases, between phases, and across cycles. That flexibility is often misunderstood. Iteration does not mean doing the phases in a random order. It means revisiting work deliberately when new knowledge or changed conditions make it necessary. Scope, governance, and requirements still provide control.

When a scenario introduces a new requirement late in the cycle, ask what must be revisited and how far the impact reaches. A change affecting only a technology standard may require less iteration than a change that alters the business outcome or stakeholder agreement.

Iteration can occur within a phase, between phases, or across cycles as the enterprise changes. The reason matters: new information, implementation feedback, changed strategy, or a governance finding may justify revisiting earlier work. Exam questions are easier when iteration is understood as controlled learning rather than evidence that the original architecture failed.

Iteration does not mean restarting the whole ADM without discipline. The architect should identify which earlier assumptions changed, which deliverables are affected, who must approve the revised decision, and whether the change alters the roadmap or governance conditions. That traceability is what keeps an iterative method from becoming uncontrolled rework.

Prepare for the combined exam by linking every phase to a decision

For each ADM phase, write three things: its purpose, a typical problem it resolves, and the evidence that shows the phase has achieved its goal. This creates a practical memory structure. For example, Phase A resolves scope and commitment problems; Phase F resolves sequencing and prioritization problems; Phase G resolves implementation-conformance problems.

The OGEA-103 combined format includes both knowledge and scenario reasoning, so you need this dual view. If you can explain the ADM in plain language and then apply it to an unfamiliar enterprise situation, you are working at the level expected for the TOGAF Enterprise Architecture Practitioner path rather than merely memorizing phase names.

For broader certification context, The Open Group certifications connect the exam to the wider portfolio. For OGEA-103 specifically, however, the ADM remains the essential discipline: a structured way to move from purpose and scope through architecture definition, transition, governance, and change.

The ADM also depends on architecture content and repositories that preserve decisions across phases. Catalogs, matrices, diagrams, requirements, principles, and roadmaps are not independent paperwork. They represent different views of the same architecture problem. When studying, practice tracing how a stakeholder concern becomes a requirement, how the requirement influences target architecture, and how the resulting gap appears in implementation planning. This makes the content model easier to understand than memorizing artifact names in isolation.

Tailoring deserves attention because the ADM is intentionally adaptable. An organization can adjust the method for its scale, governance, delivery model, and existing management processes, but tailoring should be deliberate and governed. Skipping a phase because the team is impatient is not the same as tailoring. In scenario questions, distinguish a justified adaptation from a shortcut that removes a necessary decision or control.

Architecture capability and the ADM reinforce each other. A good method cannot compensate for missing authority, unclear roles, or absent governance. Likewise, a strong architecture board cannot produce useful outcomes if the method does not connect business drivers to target states and implementation. OGEA-103 questions can therefore cross boundaries between the cycle itself and the organizational capability that supports it.

When reviewing the full cycle, tell the story in your own words from trigger to change management. If you need to rely on phase letters to remember what happens, your understanding may still be too mechanical. The exam becomes easier when you can describe the logic of the method without jargon and then map that logic back to the official terminology.

A useful ADM check is to ask what decision becomes possible at the end of each phase. Phase A should leave enough shared vision and authorization to proceed; domain phases should create coherent baseline and target views; Opportunities & Solutions should organize implementation choices; Migration Planning should produce a prioritized path; Implementation Governance should protect conformance; Architecture Change Management should decide how the architecture responds to new pressure. Thinking in decisions prevents phase names from becoming a rote sequence detached from purpose.

Requirements Management should be visible in every scenario. A requirement can be discovered, clarified, changed, or retired as architecture work progresses, and that change can force earlier assumptions to be revisited. Do not treat the requirements repository as a passive list. Practice tracing one requirement through business, data, application, technology, migration, and governance decisions. That exercise shows why iteration is deliberate rather than evidence that the ADM was followed incorrectly.