Scenario Practice Workbook: TOGAF EA Practitioner ([Candidate or study group])

Practice log for the scenario-based part of the TOGAF Enterprise Architecture Practitioner certification (exam OGEA-102, or the Part 2 section of OGEA-103 and the Section 2 questions of the OGEA-10B bridge), aligned with the TOGAF Standard, 10th Edition. It gives a repeatable analysis method (locate the phase, name the stakeholders and concerns, find the governing artefacts, rank every answer option with a reason), six fictional practice scenarios written for this template, an error log and an open-book navigation plan. It contains no text from the TOGAF Standard or from any study guide: it uses only the names of ADM phases and deliverables. Study the content itself from your own licensed copy. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and exam facts
2. Readiness tracker by phase
3. Scenario analysis method
4. Phase and deliverable locator
5. Stakeholder and concern worksheet
6. Fictional practice scenarios
7. Attempt log
8. Error pattern analysis
9. Open-book navigation plan
10. Exam-day plan
11. Glossary and references

1. Purpose and exam facts

Scenario questions test judgement rather than recall. Each presents an organisation, a situation in the architecture work and four candidate responses that all sound reasonable. The candidate who scores well is the one who reads the scenario as a practising architect would: where are we in the work, who cares about the outcome, which agreed artefact governs the next step, and which response moves the work forward without skipping governance. This workbook drills that reading habit with original scenarios.

1.1 Exam codes and paths

1.2 Format as stated in the Open Group datasheets

All three exams are supervised and delivered at Pearson VUE test centres or online through OnVUE. Part 2 awards 40 marks across 8 questions, so a single question carries several marks; check the current examination rules from the Open Group for how marks are allocated between the options before you plan your answer strategy. Candidates who also complete the Learning Studies in an accredited course earn an additional Applied Practitioner badge.

1.3 Licence rule for this workbook

The TOGAF Standard is a licensed publication of The Open Group. This workbook uses only the names of ADM phases and deliverables. Do not paste text from the standard, a study guide or course material into it, and do not write summaries of it here. Where the method below says "check the standard", open your own licensed copy and record only a page or section pointer in section 9.

2. Readiness tracker by phase

3. Scenario analysis method

The method below is original to this workbook. It does not restate the standard; it is a reading discipline for any scenario question.

3.1 Option tests

Apply these tests to each option in step 5. They are judgement heuristics written for this workbook.

• Fit to state: an option that belongs to a later phase is usually premature; one that belongs to an earlier phase is usually redundant unless the scenario signals that earlier work is missing or invalid.
• Concern coverage: the best option addresses the concern of the stakeholder with decision authority and does not ignore the concern of a stakeholder with a veto (legal, regulator, security).
• Governance respect: an option that bypasses an agreed contract, principle or board is weak even when it would be faster.
• Reuse before create: an option that builds on artefacts already in the repository beats one that starts again.
• Proportion: an option that matches effort to the size of the problem beats one that launches a full new cycle for a small change, or one that patches a structural problem.
• Traceability: an option that keeps requirements, decisions and changes traceable beats one that relies on informal agreement.

4. Phase and deliverable locator

5. Stakeholder and concern worksheet

For real engagements, keep stakeholders in the Stakeholder Register (project/stakeholder-register).

6. Fictional practice scenarios

Each scenario gives a context, a question and four options, followed by a model ranking and the reason for each position. The model ranking applies the method in section 3; argue with it in your log if your reasoning differs.

6.1 PS-01 Brightwater Water: starting the engagement

Example: Brightwater Water is a fictional regional water utility. Last year it set up a small architecture team, and the executive board approved a set of architecture principles and a governance board. The Chief Operating Officer now asks the architecture team to support a smart metering programme intended to cut leakage and automate billing. The finance director, the head of field operations and the regulator liaison each describe the scope differently: finance sees a billing project, operations sees a sensor network, the regulator liaison worries about billing accuracy rules. No document yet records what the engagement covers.

Question: what should the lead architect do next?

Model ranking: A, C, B, D. A fits the start of Phase A: a request exists, scope is disputed and stakeholders must agree before detailed work. C is useful work but belongs later; it would also proceed without an agreed scope. B repeats Preliminary work the scenario says is already done. D jumps to solutions and lets vendors shape scope, which ignores the regulator concern.

6.2 PS-02 Kestrel Health: conflicting concerns in the target design

Example: Kestrel Health is a fictional hospital group formed by merging two trusts, each with its own patient administration system. An approved Statement of Architecture Work asks for a single target architecture within nine months. During business and data architecture work, the clinical directors insist that no patient administration downtime is acceptable, while the data protection officer warns that combining patient records from both trusts needs a documented lawful basis and a data minimisation review. The application team has already proposed choosing the larger trust's system.

Question: how should the architect proceed with the target architecture?

Model ranking: B, C, D, A. B is mid-cycle work in Phases B and C: it turns concerns into requirements, keeps options open and records the result in the agreed deliverables. C is a reasonable fallback if analysis fails, but pausing before analysis is premature. D addresses only one concern and reverses the natural dependency of technology on data and application decisions. A pre-empts the architecture and ignores a stakeholder who can stop the processing.

6.3 PS-03 Corvane Mutual: budget cut after the target is agreed

Example: Corvane Mutual is a fictional insurer. Its board approved an Architecture Definition Document for a new policy and claims platform with a three-year roadmap. A month later, the budget is cut by 30 percent. The portfolio office asks the architecture team what can still be delivered and in what order. Several work packages depend on a new customer data hub.

Question: what is the best response?

Model ranking: A, C, B, D. A works in Phases E and F with the portfolio office, keeps the agreed target as the direction and respects dependencies. C is defensible only if the cut invalidates the business goals; the scenario does not say so, so it is disproportionate. B changes an approved deliverable without governance. D loses architectural control and breaks the dependency on the data hub.

6.4 PS-04 Corvane Mutual: a delivery partner deviates

Example: Implementation of the Corvane Mutual claims platform is under way. An Architecture Contract with the delivery partner requires event-based integration through the enterprise integration platform. A compliance review finds that the partner has built direct database links between the claims and billing systems to meet a deadline. The programme director argues that the deadline matters more.

Question: what should the architect do?

Model ranking: C, B, D, A. C is Phase G governance: it uses the existing contract, makes the deviation visible, lets the authorised body decide and keeps remediation traceable. B upholds the architecture but ignores a legitimate business concern and the board's role. D treats one project's shortcut as a reason to change the enterprise target without a change process. A hides the deviation and creates unmanaged technical debt.

6.5 PS-05 Larch Rail: a regulation changes after go-live

Example: Larch Rail is a fictional train operator that completed a ticketing modernisation last year. A new accessibility regulation now requires every ticket channel to support assisted booking and to record accessibility requests for audit. The change affects the mobile app, the booking API and the customer data model, but not the core fare engine.

Question: how should the architecture team respond?

Model ranking: A, C, B, D. A fits Phase H: it assesses impact before choosing the scale of response, and it keeps requirements traceable. C would deliver part of the change quickly but misses the API and data model impact and the audit record. B is disproportionate for a bounded change. D risks non-compliance with a legal deadline.

6.6 PS-06 Larch Rail: a requirement changes in the middle of the cycle

Example: During application architecture work for a new freight booking service at Larch Rail, the commercial director announces that freight customers must be able to book through partner platforms, not only through the Larch portal. Data architecture is nearly complete; technology architecture has not started.

Question: what should happen to this new requirement?

Model ranking: B, D, C, A. B is requirements management in action: it captures the change, checks its effect on completed work and keeps stakeholders aligned. D may become necessary if the change alters the engagement goals, but impact should be assessed first. C may be right if the sponsor confirms it is out of scope, yet dismissing it without assessment ignores the commercial director. A defers a change that affects business and data decisions already in progress.

7. Attempt log

Summary measures to track per round: share of top choices correct, share of full rankings matching, average time per scenario and the most frequent error type.

8. Error pattern analysis

Example: after round 1 the log shows ERR-04 three times and ERR-03 twice; the next study block focuses on Phase G scenarios and on the Architecture Contract and Compliance Assessment deliverables in the licensed copy.

9. Open-book navigation plan

Navigation rules: use the open book to confirm a judgement you have already made with the method, not to discover the answer. If a lookup takes longer than two minutes, answer from your ranking and move on.

10. Exam-day plan

Example: 8 scenarios x 11 minutes = 88 minutes, leaving 2 minutes of the 90 for a final check of flagged items. For the bridge Section 2, 4 questions in 40 minutes gives 10 minutes each; trim step 4.

Readiness gate before booking:

11. Glossary and references

11.1 Glossary

11.2 References

Standard and licence note

Structure aligned with the certification structure published by The Open Group for the TOGAF Enterprise Architecture Practitioner certification (exam codes OGEA-101, OGEA-102, OGEA-103 and OGEA-10B, format facts as stated in the datasheets linked from the certification page on 2026-10-23) and with the TOGAF Standard, 10th Edition. TOGAF and ArchiMate are registered trademarks of The Open Group. This template uses only the names of ADM phases and deliverables; all text, including the analysis method and the six fictional scenarios, is original and was written without reference to the text of the standard or any study guide. This template is not affiliated with or endorsed by The Open Group. Check the current certification page, datasheets and examination rules before use. Template licence: MIT.