Home / enterprise-architecture-it-governance / TOGAF Enterprise Architecture Practitioner (TOGAF Standard, 10th Edition), Part 2 exam OGEA-102 / Cheat Sheet
TOGAF Enterprise Architecture Practitioner (TOGAF Standard, 10th Edition), Part 2 exam OGEA-102

TOGAF Practitioner Cheat Sheet

TOGAF Practitioner Rewards the Governed, Just-Enough Next Step — Not Reciting the ADM

OGEA-102 gives you eight open-book scenarios scored 5, 3, 1 or 0. The skill tested is ranking four plausible options by how well each applies the ADM to that organisation's situation.

Check Your Readiness →
Among the harder certs
Avg: Not published by The Open Group
Pass: 750 / 1000
Most candidates understand TOGAF Enterprise Architecture Practitioner (TOGAF Standard, 10th Edition), Part 2 exam OGEA-102 concepts — and still fail. This exam tests how you apply knowledge under pressure.

OGEA-102 Syllabus Map (TOGAF Standard, 10th Edition)

The Open Group publishes no area weights, and one scenario can draw on several areas. Each question describes an organisation and offers four options: the best earns 5 points, the next 3, then 1 and 0. The TOGAF library is provided in the exam, so judgement decides the score, not lookup.

  1. 01
    Context for Enterprise Architecture (weight not published) — Architecture Capability, governance, conformance levels, partitioning, security as a cross-cutting concern
  2. 02
    Stakeholder Management (weight not published) — identify, classify by power and interest, set the approach, tailor views and the Communications Plan
  3. 03
    Phase A: The Starting Point (weight not published) — scope in four dimensions, Architecture Vision, readiness assessment, approved Statement of Architecture Work
  4. 04
    Architecture Development (weight not published) — common steps in Phases B, C and D: baseline, target, gaps, impacts, stakeholder review, ADD and ARS
  5. 05
    Implementing the Architecture (weight not published) — Phases E, F and G: implementation approach, work packages, Transition Architectures, Architecture Contracts
  6. 06
    Architecture Change Management (weight not published) — Phase H: simplification, incremental or re-architecting change, value realization, Governance Log
  7. 07
    Requirements Management (weight not published) — baselining, changed requirements, Requirements Impact Assessment, keeping the ARS current
  8. 08
    Supporting the ADM Work (weight not published) — business scenarios, gap analysis, ABBs vs SBBs, Architecture Repository, risk, iteration cycles

Wrong instinct vs correct approach

Midway through Phase B, a newly appointed Chief Risk Officer says she was never consulted and will not support the work
✕ Wrong instinct

Ask the sponsor to override her objection and continue

✓ Correct approach

Update the Stakeholder Map and Communications Plan: she is now high power and high interest, a key player. Address her concerns with tailored views and route any new requirements through Requirements Management before finalising Phase B.

In Phase C, architects learn another programme is building an overlapping customer account service after their own stakeholders approved the design
✕ Wrong instinct

Finalise the design because the project's stakeholders signed it off

✓ Correct approach

Resolve impacts across the Architecture Landscape before finalising: engage the other programme, assess overlap and reuse, and take conflicts to Architecture Governance. Approval by one project's stakeholders does not cover effects on other architectures.

A council wants three citizen portals merged; unions resisted past reorganisations and personal data rules are strict
✕ Wrong instinct

Start detailed baseline modelling of every business process

✓ Correct approach

Complete Phase A first: set scope across breadth, depth, time period and domains, include unions and data protection stakeholders, run a Business Transformation Readiness Assessment, frame security, and get the Statement of Architecture Work approved.

After deployment, a change request arrives that would restructure how several architecture domains fit together
✕ Wrong instinct

Update the existing architecture documents under change management

✓ Correct approach

Phase H classifies change as simplification, incremental or re-architecting. Re-architecting needs a new Request for Architecture Work and a fresh ADM cycle starting at Phase A; document updates suit only simplification or some incremental changes.

Know these cold

  • ▸ Gradient scoring per question — est answer 5, second 3, third 1, distractor 0
  • ▸ Request for Architecture Work is a Phase A input; the approved Statement of Architecture Work is its output
  • ▸ ADD describes the architecture qualitatively; the ARS holds measurable criteria implementers must meet
  • ▸ ABBs are product-neutral and defined in Phases B to D; SBBs name products from Phase E
  • ▸ Phase E decides what to deliver, Phase F when and in what order, Phase G governs the build
  • ▸ Greenfield has no legacy, revolutionary is fast but risky, evolutionary delivers value progressively
  • ▸ Phase C data and application architectures can be developed in either order or in parallel
  • ▸ Compliant and Conformant differ; Non-conformant means a specified feature was implemented incorrectly
  • ▸ Classify stakeholders by power and interest before choosing views; key players are managed closely
  • ▸ Initial risk drives the choice of mitigation; residual risk after mitigation needs explicit acceptance

Can you answer these without checking your notes?

In this scenario: "Midway through Phase B, a newly appointed Chief Risk Officer says she was never consulted and will not support the work" — what should you do first?
Update the Stakeholder Map and Communications Plan: she is now high power and high interest, a key player. Address her concerns with tailored views and route any new requirements through Requirements Management before finalising Phase B.
In this scenario: "In Phase C, architects learn another programme is building an overlapping customer account service after their own stakeholders approved the design" — what should you do first?
Resolve impacts across the Architecture Landscape before finalising: engage the other programme, assess overlap and reuse, and take conflicts to Architecture Governance. Approval by one project's stakeholders does not cover effects on other architectures.
In this scenario: "A council wants three citizen portals merged; unions resisted past reorganisations and personal data rules are strict" — what should you do first?
Complete Phase A first: set scope across breadth, depth, time period and domains, include unions and data protection stakeholders, run a Business Transformation Readiness Assessment, frame security, and get the Statement of Architecture Work approved.

Common Exam Mistakes — What candidates get wrong

Picking the option that produces the most architecture documentation

The purpose of EA is guiding effective change. When teams are already delivering, the top answer usually sets up just-enough governance or targets the specific change, rather than pausing delivery for a detailed enterprise-wide target architecture.

Letting the lead architect settle disputes the Architecture Board should own

Exceptions, dispensations and conflicts between projects go to the Architecture Board so the decision carries authority and lands in the Governance Log. An option where the architect decides alone and simply informs teams rarely scores 5.

Mixing up the Request for Architecture Work, Statement of Architecture Work and Architecture Contract

The Request for Architecture Work is a Phase A input from the sponsor. The sponsor approves the Statement of Architecture Work at the end of Phase A to authorise the project. Architecture Contracts govern implementation in Phase G.

Adding a late stakeholder requirement straight into the target design

Changed requirements go through Requirements Management: record, reprioritise and run a Requirements Impact Assessment, which may revisit gap analysis in earlier phases. Direct insertion skips prioritisation and hides the effect on work already approved.

Deferring security to Phase D or to a final review

Security runs through every phase: security stakeholders, regulation and risk appetite are framed in Phase A, and data classification arises in Phases B and C. Options that schedule a security assessment after design completes cause rework and rank low.

Resources to help you pass TOGAF 10 Practitioner on your first attempt

Eight gradient-scored scenarios: test whether you reliably pick the best TOGAF option, not the second best.