Overview
Implementing the Architecture covers Phases E (Opportunities and Solutions), F (Migration Planning) and G (Implementation Governance). It has 15 learning outcomes, the most of any area except Supporting the ADM Work.
In Phase E you consolidate gaps from Phases B to D, review corporate change attributes, constraints and readiness, choose an Implementation and Migration Strategy, group work into work packages and define Transition Architectures. In Phase F you assign business value to work packages, estimate resources and timings, prioritize migration projects by cost, benefit and risk, confirm the Architecture Roadmap and complete the Implementation and Migration Plan. In Phase G you confirm scope and priorities with development teams, guide deployment, carry out compliance reviews and close implementation, using Architecture Contracts and the Implementation Governance Model. Risk and security run through all three phases, and the syllabus closes with balancing opportunity against viability.
How it's tested
Scenarios here involve planning and governing delivery. You may be asked how to group work, which strategy fits, how to prioritize projects or how to handle an implementer's deviation. Best answers keep a clear line from the architecture to value-based, risk-aware plans and governed implementation.
-
Strategy fit
The organization's appetite for risk and disruption is described. You choose between greenfield, revolutionary and evolutionary approaches, or quick win, achievable targets and value chain methods.
-
Value-based prioritization
There is more change than budget or capacity. Strong options assign business value, assess risk and dependencies, and sequence work into Transition Architectures that each deliver value.
-
Governed deviation
An implementer wants to depart from the architecture. The best option uses compliance review, Architecture Contract terms and the Architecture Board, not informal approval or blanket refusal.
A telecom operator must replace its billing and CRM systems but cannot risk a single cut-over. A revolutionary big-bang approach is fast but risky; doing nothing preserves stability but loses the market. The best option chooses an evolutionary strategy, defines Transition Architectures that each deliver usable value, groups dependent gaps into work packages and prioritizes them with a business value and risk assessment.
Learning outcomes 15
Official learning outcomes from the The Open Group outline, in outline order.
5.1 Understand risk and security considerations for Phases E, F and GBloom level 2. Managing risk and security during planning and delivery.
- What it means
- Implementation introduces new risks: transition states may expose temporary vulnerabilities, migration can affect data integrity, and suppliers may deliver insecure components. Phases E to G must plan, prioritize and govern security work alongside functional change.
- What to understand
- Security work packages are prioritized with other work, risks are assessed for each Transition Architecture, and compliance reviews in Phase G include security criteria. Residual risk after mitigation must be accepted by an appropriate authority, not assumed.
- How it shows up
- Options that check the security of interim states and include security in Architecture Contracts tend to score highest.
- Common confusion
- Assuming a secure target guarantees secure transitions.
5.2 Describe the steps to create the Implementation and Migration StrategyBloom level 1. How Phase E arrives at a strategy.
- What it means
- Phase E determines key corporate change attributes, identifies business constraints for implementation, reviews and consolidates gap analysis results, reviews consolidated requirements, reconciles interoperability requirements, refines dependencies and confirms readiness and risk before formulating the strategy.
- What to understand
- The strategy sets the overall approach, sequencing and implementation method for the change. It is informed by the organization's culture, capacity and constraints and by the Implementation Factor Catalog, which records factors and their impact on implementation decisions.
- How it shows up
- Expect a question about what must be known before choosing a strategy; constraints, dependencies and readiness are typical answers.
- Common confusion
- Choosing a strategy before consolidating gaps and dependencies.
5.3 Apply the three basic approaches to implementationBloom level 3. Greenfield, revolutionary and evolutionary.
- What it means
- Greenfield builds a new capability from scratch where nothing exists. Revolutionary implementation changes radically, often in one major step with a hard cut-over. Evolutionary implementation moves through incremental, planned steps, often aligned to Transition Architectures.
- What to understand
- Choice depends on risk tolerance, urgency, existing assets and organizational readiness. The TOGAF Standard also describes implementation methods: quick win (snapshots), achievable targets, and value chain. These combine with the approach to shape the roadmap.
- How it shows up
- A scenario's risk appetite and existing systems usually point to one approach; evolutionary fits most risk-averse, legacy-heavy organizations.
- Common confusion
- Calling any new system greenfield even when existing systems and data must be migrated.
5.4 Apply identifying and grouping work packagesBloom level 3. Turning gaps into deliverable units of change.
- What it means
- Gaps and solutions from Phases B to D are consolidated, often in a Consolidated Gaps, Solutions and Dependencies Matrix, and grouped into work packages that can be delivered as projects or programmes. Grouping considers dependencies, shared solutions and existing initiatives.
- What to understand
- Good grouping reduces duplication, respects dependencies and allows value to be delivered early. Existing activities are reviewed and may be merged, changed or stopped. Work packages also consider reuse of building blocks and whether to buy, build or reuse solutions.
- How it shows up
- The best option groups related gaps around dependencies and shared solutions rather than by original organizational silo.
- Common confusion
- Treating every individual gap as its own project.
5.5 Apply creating and documenting Transition ArchitecturesBloom level 3. Defining intermediate stable states.
- What it means
- Transition Architectures describe the enterprise at significant intermediate states between baseline and target. Each should be stable, deliver measurable business value and provide a foundation for the next step. They are documented in the Architecture Definition Document and roadmap.
- What to understand
- Techniques such as the Architecture Definition Increments Table and Transition Architecture State Evolution Table help plan which increments occur in each transition. Transitions let the organization realize benefits early, manage risk and adjust plans as conditions change.
- How it shows up
- Options defining transitions that cannot operate on their own, or that deliver no value, tend to score low.
- Common confusion
- Treating Transition Architectures as project phases rather than architecture states.
5.6 Apply assessing the impact of migration projects and coordination needsBloom level 3. Understanding how projects affect each other and the business.
- What it means
- Migration projects interact: they share resources, change the same systems or depend on each other's outputs. The architect assesses these impacts and the coordination needed among projects, operations and the wider portfolio, using management frameworks such as portfolio, project and operations management.
- What to understand
- Phase F confirms how the Implementation and Migration Plan interacts with enterprise management frameworks. Impacts on business operations, such as downtime or staff retraining, must be planned. Poor coordination leads to conflicting changes and wasted effort.
- How it shows up
- Look for options that coordinate through the existing portfolio and project management frameworks rather than bypass them.
- Common confusion
- Assuming the architecture team should run all migration projects itself.
5.7 Understand how to assign business value to work packagesBloom level 2. Valuing work to support prioritization.
- What it means
- Each work package is assessed for business value, for example through performance, productivity, customer or risk benefits, using techniques such as the Business Value Assessment and a value and risk matrix. Critical success factors and measures link value to business goals.
- What to understand
- Value is assessed alongside risk and cost so that high-value, lower-risk work can go early. Value must trace to the goals and KPIs agreed earlier. Packages with low value may still be needed if other valuable work depends on them.
- How it shows up
- Options that prioritize by visible business value and risk score higher than those based on technical preference.
- Common confusion
- Valuing work only by cost or by technical elegance.
5.8 Describe prioritizing the migration projectsBloom level 1. Ordering projects by cost, benefit and risk.
- What it means
- Migration projects are prioritized using a cost and benefit assessment and risk validation, taking into account dependencies, resources and the agreed Transition Architectures.
- What to understand
- Prioritization is negotiated with stakeholders and confirmed through governance. Risks are re-validated because priorities can change residual risk. The result shapes the Implementation and Migration Plan.
- How it shows up
- A question may ask which factor should drive priority; combine benefit, cost, risk and dependencies.
- Common confusion
- Prioritizing solely on the order in which gaps were found.
5.9 Describe confirming the Architecture RoadmapBloom level 1. Finalizing the sequence of change.
- What it means
- In Phase F the Architecture Roadmap is confirmed and the Architecture Definition Document updated, reflecting the agreed Transition Architectures, work packages and timing.
- What to understand
- The roadmap lists work packages on a timeline and shows progression through transitions to the target. It is a living deliverable that Phase H and later cycles may revise.
- How it shows up
- Expect roadmap confirmation as a late Phase F step before completing the Implementation and Migration Plan.
- Common confusion
- Confusing the Architecture Roadmap with the detailed project plan.
5.10 Understand the outputs needed for implementationBloom level 2. What Phases E and F must hand to delivery.
- What it means
- Outputs include the Implementation and Migration Plan, finalized Architecture Roadmap and Transition Architectures, updated Architecture Definition Document and Architecture Requirements Specification, an Implementation Governance Model, and change requests for the Architecture Capability arising from lessons learned.
- What to understand
- The Implementation Governance Model defines how the architecture will be governed during delivery. These outputs give Phase G what it needs to set up Architecture Contracts, deploy solutions and run compliance reviews.
- How it shows up
- When asked what must exist before Phase G, look for the Implementation and Migration Plan and the Implementation Governance Model.
- Common confusion
- Expecting signed Architecture Contracts as a Phase F output; they are finalized in Phase G.
5.11 Understand the inputs to Phase GBloom level 2. What Implementation Governance starts from.
- What it means
- Phase G receives a Request for Architecture Work for implementation, the Implementation and Migration Plan, the Implementation Governance Model, the Architecture Definition Document and Architecture Requirements Specification, the Architecture Roadmap, Transition Architectures and draft Architecture Contracts.
- What to understand
- These inputs define what must be built and how compliance will be judged. Missing or weak inputs, such as an absent governance model, make it hard to hold implementers to the architecture.
- How it shows up
- Scenarios with unclear compliance criteria may reward options that confirm the ARS and governance model before reviews start.
- Common confusion
- Thinking Phase G starts only from the solution design produced by the implementer.
5.12 Apply execution of Implementation GovernanceBloom level 3. Governing delivery against the architecture.
- What it means
- Phase G confirms scope and priorities with development management, identifies deployment resources and skills, guides solution development, performs Enterprise Architecture compliance reviews, implements business and IT operations, and performs a post-implementation review before closing.
- What to understand
- The architect's role is to guide and verify, not to build. Compliance reviews check conformance with the architecture and may lead to change requests or dispensations. Post-implementation reviews capture lessons that may feed Phase H.
- How it shows up
- When implementation diverges, prefer options that use compliance reviews and governance to decide between rework, dispensation or architecture change.
- Common confusion
- Assuming the architect can approve deviations informally to keep projects moving.
5.13 Understand the outputs that support Architecture GovernanceBloom level 2. Phase G deliverables.
- What it means
- Phase G outputs include signed Architecture Contracts, Compliance Assessments, Change Requests, architecture-compliant solutions deployed, and implementation recommendations from impact analysis.
- What to understand
- These outputs record what was agreed and what was checked, providing evidence for the Architecture Board and the Governance Log. Change requests raised here are inputs to Phase H.
- How it shows up
- Questions may ask where a deviation is recorded or escalated; Compliance Assessments and Change Requests are key.
- Common confusion
- Thinking Phase G only produces deployed systems.
5.14 Apply Architecture Contracts with implementersBloom level 3. Agreements between architecture and delivery parties.
- What it means
- An Architecture Contract is a joint agreement between development partners and sponsors on deliverables, quality and fitness for purpose of an architecture. Contracts can exist between the architecture function and business users, or between the architecture function and implementers.
- What to understand
- Contracts state the architecture to be implemented, requirements, conformance expectations, timescales and how compliance will be checked. They make governance enforceable, including for external suppliers. Breaches are handled through compliance reviews and the Architecture Board.
- How it shows up
- For supplier deviations, options that refer to the Architecture Contract terms and governance process usually score best.
- Common confusion
- Treating the Architecture Contract as a commercial procurement contract.
5.15 Understand balancing opportunity and viabilityBloom level 2. Weighing what is desirable against what is achievable.
- What it means
- Opportunities identified in the architecture must be balanced against what the organization can realistically deliver, considering cost, risk, capacity, readiness and constraints. The aim is a plan that delivers real value and can actually be executed.
- What to understand
- Too much ambition overloads the organization and fails; too little loses value. Transformation readiness, risk assessment and business value assessment inform this balance. Decisions are made with stakeholders and documented, and may change as Phase H monitors results.
- How it shows up
- When stakeholders push for everything at once, the best option sequences the most valuable, viable change first.
- Common confusion
- Treating viability as a reason to drop the target rather than to sequence it.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Implementation and Migration Strategy
Overall approach, sequencing and method for implementing the change.
- Remember
- Formulated in Phase E after consolidating gaps, constraints and readiness.
- Tested as
- Strategy-fit scenarios.
- Trap
- Choosing it before knowing dependencies.
-
Greenfield, revolutionary, evolutionary
The three basic implementation approaches.
- Remember
- Evolutionary suits incremental, lower-risk change.
- Tested as
- Applying-level outcome 5.3.
- Trap
- Using greenfield where legacy must migrate.
-
Quick win, achievable targets, value chain
Implementation methods that shape how increments are chosen.
- Remember
- Combined with the basic approach.
- Tested as
- Roadmap shape questions.
- Trap
- Confusing them with the three approaches.
-
Work package
A set of actions to achieve one or more objectives, delivered as a project or programme.
- Remember
- Groups related gaps and dependencies.
- Tested as
- Grouping scenarios.
- Trap
- One package per gap.
-
Transition Architecture
A stable intermediate state between baseline and target.
- Remember
- Each should deliver business value.
- Tested as
- Sequencing scenarios.
- Trap
- Treating it as a project phase.
-
Implementation Factor Catalog
Records factors affecting implementation, their descriptions and deductions.
- Remember
- Supports the Phase E strategy.
- Tested as
- Phase E technique questions.
- Trap
- Using it to list gaps only.
-
Consolidated Gaps, Solutions and Dependencies Matrix
Brings together gaps from all domains with potential solutions and dependencies.
- Remember
- Basis for grouping work packages.
- Tested as
- Phase E grouping.
- Trap
- Skipping dependency analysis.
-
Business Value Assessment
Technique using value and risk to compare work packages.
- Remember
- Used in Phase F prioritization.
- Tested as
- Prioritization scenarios.
- Trap
- Prioritizing by technical preference.
-
Implementation Governance Model
Defines how implementation will be governed.
- Remember
- Output of Phase F, input to Phase G.
- Tested as
- Readiness for Phase G.
- Trap
- Thinking governance is set up ad hoc in Phase G.
-
Architecture Contract
Agreement on deliverables, quality and fitness for purpose with implementers or business users.
- Remember
- Signed in Phase G.
- Tested as
- Supplier deviation scenarios.
- Trap
- Treating it as a purchase contract.
-
Compliance Assessment
Record of a compliance review's findings.
- Remember
- Supports Board decisions and Phase H.
- Tested as
- Deviation handling.
- Trap
- Doing reviews only at the end.
-
Opportunity vs. viability
Balancing desirable change with what can realistically be delivered.
- Remember
- Informs sequencing, not abandonment.
- Tested as
- Over-ambitious sponsor scenarios.
- Trap
- Choosing the most ambitious option.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Greenfield vs. revolutionary vs. evolutionary
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Greenfield | New implementation where no relevant capability exists | No legacy to migrate | Assuming greenfield because the technology is new |
| Revolutionary | Radical change, often a single major cut-over | Fast but high-risk | Choosing it for risk-averse organizations |
| Evolutionary | Incremental change through planned transitions | Lower risk, value delivered progressively | Thinking it means no target state |
Phase E vs. Phase F vs. Phase G
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Phase E: Opportunities and Solutions | Consolidate gaps, choose strategy, group work packages, define transitions | What to deliver and in what shape | Doing detailed scheduling here |
| Phase F: Migration Planning | Value, estimate, prioritize, confirm roadmap, complete plan | When and in what order | Skipping business value assessment |
| Phase G: Implementation Governance | Contracts, guide deployment, compliance reviews, close | Governing the actual build | Letting the architect build solutions |
Architecture Roadmap vs. Implementation and Migration Plan
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Architecture Roadmap | Work packages and transitions on a timeline from baseline to target | Architecture-level sequence | Using it as a detailed project schedule |
| Implementation and Migration Plan | Detailed plan for projects, resources and timing | Delivery-level planning | Producing it before priorities are set |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Big bang for speed
- What candidates pick
- Replace all legacy systems in one cut-over to reach the target faster.
- Why it looks right
- It promises quick benefits.
- Why it's wrong
- Where risk tolerance and readiness are low, an evolutionary approach with value-delivering transitions is more viable.
Clue to watch for Critical operations, regulators or past failed projects are mentioned.
-
Everything is priority one
- What candidates pick
- Start all work packages in parallel because the sponsor wants all benefits.
- Why it looks right
- It satisfies the sponsor.
- Why it's wrong
- Capacity and dependencies make this unviable; value, cost and risk assessment should set priorities.
Clue to watch for Limited budget, shared resources or dependencies.
-
Informal waiver
- What candidates pick
- The lead architect agrees the supplier can use a different integration approach.
- Why it looks right
- It keeps the project on schedule.
- Why it's wrong
- Deviations should be assessed in a compliance review and decided under the Architecture Contract and by the Architecture Board.
Clue to watch for A supplier or project team asks to depart from standards.
-
Rigid refusal
- What candidates pick
- Reject any deviation and require the supplier to comply exactly.
- Why it looks right
- It seems to protect the architecture.
- Why it's wrong
- Governance may approve a dispensation or trigger architecture change if the deviation has merit; blanket refusal ignores that.
Clue to watch for The deviation offers clear benefits or reflects new technology.
-
Silo grouping
- What candidates pick
- Create one work package per department's gaps.
- Why it looks right
- Ownership is clear.
- Why it's wrong
- Grouping should follow dependencies and shared solutions, or duplication and conflicts follow.
Clue to watch for Several departments need the same capability.
-
Secure target, insecure path
- What candidates pick
- Approve the roadmap because the target architecture passed security review.
- Why it looks right
- The end state is secure.
- Why it's wrong
- Interim states can introduce vulnerabilities; each Transition Architecture needs risk assessment.
Clue to watch for Temporary interfaces or parallel running are described.
Answer framework
Use these checks to rank options in planning and implementation scenarios.
- Identify which phase the scenario is in and whether the issue is strategy, grouping, prioritization or governance of delivery.
- Judge the organization's risk tolerance, readiness and legacy, then choose the implementation approach and method that fit, usually evolutionary for complex legacy estates.
- Prefer options that group gaps by dependencies and shared solutions and define Transition Architectures that each deliver measurable value.
- Check that prioritization uses business value, cost, risk and dependencies, and that it is confirmed with stakeholders and governance.
- In Phase G, choose options that use Architecture Contracts, compliance reviews and the Architecture Board to handle deviations, dispensations or change requests.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this area as three linked mini-topics. Start with Phase E: read its steps and write them as a flow from consolidating gaps to defining transitions. Learn the three implementation approaches and the three methods, then practise choosing among them for organizations with different risk appetites and legacy estates.
Move to Phase F next. Focus on business value assessment and prioritization, and on the difference between the Architecture Roadmap and the Implementation and Migration Plan. Sketch a small roadmap with two Transition Architectures and say what value each one delivers.
Then study Phase G and Architecture Contracts. Write out what a contract contains and the paths a deviation can take: rework, dispensation or architecture change. Link compliance assessments and change requests to Phase H.
Finally, connect the risk and security outcome and the opportunity versus viability outcome to everything above; both are lenses for ranking options. In practice scenarios, ask three questions: does this option fit the organization's risk appetite, does it deliver value in stages, and does it keep governance intact? An option that satisfies all three is usually worth 5 points.
FAQ
How many OGEA-102 questions cover Implementing the Architecture?
The Open Group does not publish a count for Implementing the Architecture. It is one of the eight areas covered by the 8 scenarios and has 15 outcomes, so planning and governance situations are likely.
What are the three basic implementation approaches?
Greenfield, revolutionary and evolutionary. They differ in whether there is anything to migrate and in how much change happens at once.
Where are Architecture Contracts signed?
They are drafted earlier but finalized and signed in Phase G, where they are used to govern implementation by delivery teams or suppliers.
Why must Transition Architectures deliver value?
Each transition may be the state the enterprise operates in for a long time. If it delivers no value, benefits are delayed and the programme becomes vulnerable to cancellation.
What is the Implementation Governance Model?
A Phase F output that defines how implementation will be governed, including roles, processes and checkpoints, and which Phase G uses.
Does the architect manage the migration projects?
No. Projects are run through the organization's portfolio and project management frameworks; the architect guides, coordinates and checks compliance.
What does balancing opportunity and viability mean in practice?
Sequencing the most valuable change the organization can realistically absorb, considering cost, risk, capacity and readiness, rather than attempting everything or abandoning the target.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered strategy, work packages, transitions, prioritization and Implementation Governance. Test whether you can rank options when ambition meets limited capacity.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way