Section 1: Understanding the Part 2 Exam
The OGEA-103 Part 2 exam tests your ability to apply TOGAF in realistic, ambiguous enterprise architecture situations — not your ability to recall definitions. Understanding its exact format before you study is critical.
| Attribute | Detail |
|---|---|
| Questions | 8 scenario-based questions |
| Time | 90 minutes (≈ 11 minutes per question) |
| Pass mark | 60% across all scenarios |
| Answer format | Each question has 5 options; select the BEST 2 or 3 |
| Scenario length | 200–400 words per question stem |
| Scoring | Gradient (partial credit for partially correct selections) |
| Open book? | Yes — the TOGAF Standard document is permitted |
| What is tested | Applying TOGAF in ambiguous situations, NOT pure recall |
Because Part 2 uses gradient scoring, always select an answer — never leave blank. Even a partially correct selection earns partial marks. If you identify 2 clearly correct options out of a "choose 3" question, guess the third from your remaining candidates rather than leaving it empty.
Open Book — What It Really Means
Open book does not mean you can look everything up. At 11 minutes per question, you have roughly 4–5 minutes of reading time and 6–7 minutes of analysis. You should already know TOGAF well; the standard is a confirmation tool, not a learning tool during the exam. Know the table of contents well enough to navigate to a section in under 60 seconds.
Section 2: Part 2 Question Anatomy
Every Part 2 question follows the same anatomy. Recognising the structure immediately lets you extract what matters and ignore noise.
- Context paragraph — Describes the organisation, its industry, and current situation. Read quickly; extract: organisation type, current ADM phase (if stated), and any stated constraints (budget, time, regulation).
- Your role — Always the Enterprise Architect. Never a project manager, business analyst, or developer. TOGAF's answer is always the EA perspective.
- The event or trigger — Something has happened: a change request, a governance conflict, a stakeholder objection, a regulatory deadline. This is the decision point.
- The question stem — Tells you exactly what TOGAF concept to apply: "What should the EA recommend?" / "What is the MOST appropriate action?" / "Which TWO answers BEST describe...?"
- Five answer options — Usually: one clearly wrong, one plausible-but-incomplete, one good, two best. Your task: eliminate the wrong ones, then distinguish good from best.
Eliminate answers that: (1) bypass governance — TOGAF always routes through governance; (2) skip or reorder ADM phases without justification; (3) let project managers override architecture decisions; (4) ignore stakeholders or treat communication as optional; (5) propose a technical fix instead of an architectural response.
Section 3: Common Part 2 Themes
Eight scenario types account for the majority of Part 2 questions. Recognising the theme in the first paragraph directs which TOGAF concepts to apply.
| Theme | Signal Words | Core TOGAF Concept | Typical Best Answer Direction |
|---|---|---|---|
| ADM phase selection & iteration | "skip", "go back", "which phase" | ADM phase sequence; iteration types | Follow the ADM; justify return to earlier phase; use transition architectures |
| Stakeholder conflict | "disagrees", "objection", "concerns" | Stakeholder management; views & viewpoints | Engage via Architecture Vision; create tailored view; escalate through governance |
| Governance decisions | "non-compliant", "dispensation", "waiver" | Architecture Contract; Architecture Board; Phase G | Raise compliance concern; seek dispensation if justified; document formally |
| Trade-off analysis | "cost vs compliance", "faster vs safer" | Architecture principles; risk management | Apply principles; document trade-off; do not silently compromise compliance |
| Architecture scope decisions | "scope creep", "boundary", "limit" | Statement of Architecture Work; Preliminary Phase | Refer to Statement of Architecture Work; raise change request if scope must change |
| Transition architecture selection | "phased", "interim state", "too large" | Transition Architecture; Architecture Roadmap | Define transition architectures; iterate ADM per transition; do not skip to target |
| Change management decisions | "new regulation", "merger", "technology change" | Phase H; change request; ADM re-cycle trigger | Assess impact; raise Architecture Change Request; determine whether to re-cycle ADM |
| Capability & organisation readiness | "not ready", "skills gap", "sponsorship" | Architecture Capability; Preliminary Phase | Address capability before proceeding; involve sponsor; do not skip Preliminary |
Section 4: Decision Framework for Part 2
Apply this five-step process to every question. Practice it until it is automatic — it should take 30 seconds to execute the first three steps.
- Identify the situation. Which ADM phase is the organisation in? Who are the key actors (Enterprise Architect, sponsor, project manager, vendor, regulator)? Write a two-word summary in the margin: e.g. "Phase E / scope".
- Identify the constraint or tension. What is the pressure in the scenario? Time pressure? Cost pressure? Compliance risk? Stakeholder objection? Every scenario has exactly one primary tension. Name it.
- Apply TOGAF principles. Ask: "What does TOGAF say about this situation?" — Use your knowledge (not the book yet). The answer almost always comes from one of: ADM phase guidance, governance process, stakeholder management, or architecture principles.
- Eliminate answers that violate TOGAF principles. Remove any option that bypasses governance, skips phases without justification, ignores stakeholders, or is a technical/project solution rather than an architectural one.
- Select the most architecturally sound answer. Among the remaining options, prefer the answer that is most complete, most aligned with TOGAF governance, and most appropriate to the EA role — not the one that is merely "correct" in a project management sense.
Part 2 distractors are often "pragmatic" options that sound reasonable in real life: "approve the change to keep the project moving", "skip the review to meet the deadline", or "let the team decide". These are almost never the TOGAF best answer. TOGAF always prioritises governance integrity over speed. When in doubt, choose the answer that follows the process — even if it is slower.
Section 5: Worked Scenario Examples
Scenario A — Transition Architecture (Phase E)
A. Accept the project manager's recommendation — saving 6 months reduces risk of business change fatigue.
B. Define two or three transition architectures that each represent a stable, deployable state; iterate the ADM for each transition.
C. Escalate the dispute to the CIO for resolution before proceeding with Phase E.
D. Return to Phase A to update the Architecture Vision before deciding on transition states.
Why B: TOGAF explicitly requires transition architectures when the gap between Baseline and Target is too large to bridge in a single step — which 36 months across five systems clearly is. Each transition architecture must be a stable, deployable state. The ADM is iterated per transition state (Phases E and F for each). This is the core of transition architecture iteration.
Why not A: This bypasses a TOGAF-mandated process. "Reducing overhead" does not override architecture governance. Eliminating transition states dramatically increases delivery risk.
Why not C: Escalating a process question to the CIO is not the EA's first action. The EA should resolve this through architecture governance, not executive escalation.
Why not D: Returning to Phase A is only appropriate if the Architecture Vision itself has changed. The vision here is unchanged; the dispute is about how to execute Phase E.
Scenario B — Governance Dispensation (Phase G)
A. Approve the deviation immediately because the technical benefit is clear and quantified.
B. Reject the solution and instruct the team to reimplement using only SIB-approved standards.
C. Raise a compliance exception; ask the team to submit a formal dispensation request to the Architecture Board with technical justification; defer the approval decision to the Board.
D. Add Kafka to the SIB retroactively to resolve the non-compliance.
Why C: Phase G compliance reviews that identify non-conformance trigger the dispensation process — not a unilateral EA decision. The Architecture Board, not the individual EA, has the authority to grant dispensations. The EA's role is to identify the non-conformance, document it, and route it through governance. This is the architecturally correct process.
Why not A: The EA does not have unilateral authority to approve deviations from the SIB. This bypasses governance.
Why not B: Immediate rejection without considering a dispensation is inflexible and may be incorrect — the technology may be genuinely superior. TOGAF provides the dispensation process precisely for this situation.
Why not D: Adding Kafka to the SIB retroactively to cover a compliance failure is not a governance action — it is a cover-up. SIB updates require their own evaluation and approval process.
Scenario C — Regulatory Change (Architecture Change Management)
A. Continue with the current Phase F plan — regulations are a legal matter for the compliance team, not the EA.
B. Immediately pause the ADM cycle and raise an Architecture Change Request to incorporate the regulatory requirement; assess impact on the current roadmap and transition architectures; propose an expedited work package for data residency controls.
C. Add a brief data residency section to the current Phase F plan and continue without returning to earlier phases.
D. Restart the ADM from Phase A to fully incorporate the new regulatory requirement.
Why B: A significant regulatory change with a 3-month deadline is exactly the type of external driver that triggers an Architecture Change Request (Phase H concept, but applicable mid-cycle). The EA must assess the impact on the current roadmap, determine whether a new work package can address the requirement within the 3-month window, and update the transition architectures accordingly. This is the TOGAF change management response.
Why not A: Data residency is an architectural concern (data architecture, technology architecture, governance). Declaring it "not the EA's problem" violates the EA's scope and responsibilities.
Why not C: Adding a brief section without impact assessment ignores the fact that data residency may require changes across the Business, Data, Application, and Technology architectures — all of which need re-evaluation.
Why not D: Restarting from Phase A is disproportionate. A change request and targeted impact assessment is the correct level of response; a full ADM restart would take months and miss the 3-month deadline.
Notice the consistent pattern across all three scenarios: the best answer always (1) follows TOGAF's defined process, (2) routes through governance rather than bypassing it, (3) responds proportionately — not ignoring the issue, not overreacting with a full restart, and (4) maintains the EA role — not deferring to project managers, CIOs, or compliance teams to make architectural decisions.
Section 6: Open Book Strategy
Using the TOGAF Standard effectively during Part 2 requires knowing where things are — not reading entire chapters during the exam.
- Architecture Development Method (ADM) overview Part II, Ch 4
- ADM Phase inputs, steps, outputs (per phase) Part II, Ch 5–14
- Architecture Principles format & examples Part III, Ch 20
- Stakeholder Management & viewpoints Part III, Ch 24
- Architecture Governance & Architecture Board Part VI, Ch 44–46
- Architecture Contracts & compliance Part VI, Ch 47
- Standards Information Base Part V, Ch 41
- Architecture Change Management (Phase H) Part II, Ch 13
- Transition Architectures Part II, Ch 11 (Phase E)
- Architecture Capability Framework Part VII
Time Management: 90 Minutes for 8 Questions
- Minutes 0–2: Read the scenario and identify the theme and phase. Do not read the answer options yet.
- Minutes 2–5: Apply Steps 1–3 of the decision framework mentally. Form a hypothesis about the best answer.
- Minutes 5–8: Read all five options. Eliminate two, confirm your hypothesis, select answers.
- Minutes 8–11: Verify: does your selection follow TOGAF governance? Is it from the EA perspective? If unsure, consult the book on one specific point only.
- Reserve 5 minutes at the end to review any flagged questions.
The most common open-book mistake is spending 5+ minutes searching the TOGAF Standard for a specific fact when you should trust your preparation. Use the book only to confirm a governance process step or verify a phase output when genuinely uncertain. If you have studied all 17 chapters of this guide, you already know 95% of what Part 2 tests.
Section 7: Exam Day Checklist
Before You Sit
- Confirm you have the TOGAF Standard document accessible (printed or digital, per exam provider rules)
- Tab or bookmark the TOGAF Standard at: ADM overview, governance chapters, Phase G, Phase H, and principles
- Know your exam format: Part 1 first (40 MCQ, 60 min, closed book) then Part 2 (8 scenarios, 90 min, open book)
- Remember: you must pass Part 1 before Part 2 scores are counted
During the Exam
- Always read the entire scenario before looking at the answer options
- Identify your role (Enterprise Architect) and the core tension in every question
- Use the decision framework — resist answering from instinct alone
- Flag difficult questions and move on — return with fresh eyes
- Never leave an answer blank (gradient scoring rewards partial selections)
- Avoid changing answers unless you have a specific TOGAF reason to do so
Common Mistakes to Avoid
- Choosing "pragmatic" answers that bypass governance — TOGAF always routes through governance
- Selecting answers that let project managers make architectural decisions
- Over-using the open book — it costs time and rarely changes the answer
- Confusing "a correct action" with "the BEST action" — both can be true, only one is best
- Ignoring the ADM phase context — the same action can be correct in one phase and wrong in another
Revision Summary — Chapter 17
- Part 2: 8 scenarios, 90 minutes, 60% pass, open book; gradient scoring means always select an answer.
- Every question tests EA application, not recall — always answer from the Enterprise Architect perspective.
- The five-step decision framework: identify situation → identify constraint → apply TOGAF → eliminate violations → select best answer.
- The most common distractor is the "pragmatic" answer that bypasses governance — it is almost never the TOGAF best answer.
- Eight themes dominate Part 2: ADM iteration, stakeholder conflict, governance/dispensation, trade-off analysis, scope decisions, transition architectures, change management, and capability readiness.
- Open book strategy: know where to find things fast; use the book to confirm, not to learn during the exam.
- Time per question: 11 minutes. Reserve the last 5 minutes for review of flagged questions.
- Transition architectures are required when the baseline-to-target gap is too large for a single delivery step — this is the most tested single concept in Part 2.
Final Practice: Part 2-Style Questions
Five scenario questions in Part 2 format. Each has five options; identify the BEST two answers, then reveal the explanation.
A. Comply with the CFO's instruction — executive authority supersedes architecture process.
B. Explain that Phase C addresses Data and Application architectures which are essential inputs to Phase D; skipping Phase C creates an incomplete architecture.
C. Escalate to the CEO to overrule the CFO immediately.
D. Create a tailored view of Phase C outputs that demonstrates the business value of data and application architecture to the CFO, using business-relevant language.
E. Proceed to Phase D but document the skipped phase as a risk in the project log.
Explanation: B and D are best. B correctly applies TOGAF's ADM sequence: Phase C (Information Systems Architecture) produces inputs that Phase D (Technology Architecture) depends on. Skipping it violates the ADM. D applies the stakeholder management principle — create a viewpoint and view that is relevant to this stakeholder's concerns, translating architecture value into business language. A surrenders architecture governance to executive authority. C is disproportionate escalation. E documents risk but does nothing to prevent the architectural deficiency.
A. Approve the go-live — business urgency takes priority over architecture compliance in exceptional circumstances.
B. Block the go-live permanently until all three principle violations are remediated.
C. Document the principle violations formally as a compliance exception and require the project team to submit a dispensation request with a time-bound remediation plan.
D. Remove the three principles from the Architecture Principles catalogue to resolve the violation.
E. Present the compliance findings to the Architecture Board with a recommendation; allow the Board (not the EA alone) to make the go-live decision.
Explanation: C and E are best. C follows the TOGAF dispensation process: document the non-conformance, require a formal request, and attach a remediation commitment. E correctly routes the decision to the Architecture Board — the EA identifies and presents the issue but does not have unilateral authority to approve or permanently block a deployment. A surrenders governance. B is disproportionate — a managed dispensation is the correct mechanism. D is a governance failure that retroactively eliminates standards to conceal violations.
A. Raise an Architecture Change Request documenting the impact of the merger on the current ADM cycle and Target Architecture; present it to the Architecture Board.
B. Complete Phase F as planned — the merger will be addressed in the next ADM cycle.
C. Immediately restart the ADM from Phase A to fully incorporate the merger context.
D. Assess whether the current Phase F plan remains valid for any domains unaffected by the merger; continue those work packages while pausing affected domains pending re-assessment.
E. Delegate the merger's architectural implications to the project management office.
Explanation: A and D are best. A correctly invokes the Architecture Change Request process (Phase H concept applicable mid-cycle) to formally document and assess the change's impact. D demonstrates proportionate response — not all five domains are necessarily affected equally; continuing unaffected work packages is efficient and consistent with TOGAF's iterative nature. B ignores a material change to the Target Architecture. C is disproportionate — a change request and impact assessment is the right level of response. E delegates architectural responsibility to a non-architecture function.
A. Proceed with Phase A without the stakeholder's input and document the gap as an assumption.
B. Engage the stakeholder one-to-one to understand their specific concerns; create a business-language view of the architecture that is relevant to their strategic interests.
C. Escalate to the architecture sponsor to engage the stakeholder and communicate the strategic importance of their participation.
D. Remove the stakeholder from the stakeholder map so their absence does not block progress.
E. Commission a separate consultancy firm to provide the stakeholder's perspective.
Explanation: B and C are best. B applies TOGAF stakeholder management — understand the stakeholder's perspective, address their concerns directly, and tailor communication using a viewpoint relevant to their role. C appropriately uses the sponsor's authority to drive engagement; this is a legitimate escalation path in Phase A when stakeholder participation is blocked. A proceeds without critical input, creating architectural risk. D removes a stakeholder from governance, which would create compliance and completeness issues. E introduces an unnecessary external party rather than resolving the engagement problem.
A. Each transition architecture represents a stable, clinically operable state — this reduces patient care risk by ensuring no single step creates an unrecoverable operational failure.
B. TOGAF requires three transition architectures for all programmes over 3 years — this is a mandatory compliance requirement.
C. Transition architectures allow the EA team to bill for three separate architecture engagements, which is more economical for the organisation.
D. Transition architectures enable the organisation to course-correct between delivery steps — if clinical or regulatory requirements change mid-programme, each transition point is an opportunity to re-align without restarting the full programme.
E. The programme director does not have authority over architecture decisions — the EA should proceed regardless of their objection.
Explanation: A and D are best. A presents the transition architecture benefit in clinical (business) terms — stability and risk reduction per step — which addresses the programme director's concern about patient benefit. D articulates the change resilience benefit: each transition state is a re-alignment checkpoint, which is especially valuable in a regulatory environment like healthcare where requirements evolve. B is false — TOGAF does not mandate a specific number of transition architectures. C is irrelevant and inappropriate. E is incorrect — stakeholder buy-in matters, and the EA should persuade through evidence, not override by authority.