The Open Group OGEA-103: Study Plan: What to Practice

OGEA-103 is the TOGAF Enterprise Architecture combined Part 1 and Part 2 examination. The OGEA-103 exam combines a 40-question, one-hour closed-book Foundation section with an eight-question, 90-minute open-book Practitioner section, for a total scheduled exam length of 2 hours and 30 minutes.

The two sections require different preparation. Part 1 rewards accurate recall of TOGAF concepts and structure. Part 2 rewards application, analysis, and the ability to rank scenario answers. A good study plan develops those skills in parallel instead of spending weeks on memorization and leaving practitioner reasoning until the end.

Week 1: build the TOGAF mental map

Start with the structure of the TOGAF Standard, core Enterprise Architecture concepts, the ADM, requirements management, architecture content, governance, and the purpose of supporting techniques.

Use OGEA-101 as the internal Foundation boundary. By the end of the week, you should be able to draw the ADM and explain what each major phase contributes without opening reference material.

Add architecture capability and governance to the map, not only the ADM phases. Enterprise architecture is sustained by roles, processes, governance, repository content, and organizational commitment beyond a single project.

Explain the difference between the architecture method and the architecture capability that uses it. This helps prevent Part 1 questions from blending governance structures with ADM activities.

Week 2: learn ADM inputs, outputs, and decision purpose

Take one enterprise transformation and carry it through Preliminary, Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, opportunities and solutions, migration planning, implementation governance, and change management.

Do not memorize outputs independently. Ask what decision each artifact enables, which stakeholder needs it, and how it becomes input to the next stage. This creates a connected method rather than a list of phases.

Add iteration deliberately. After completing a first pass, introduce a merger, regulatory constraint, or new digital channel and decide which ADM phases need to be revisited. TOGAF is designed to support change, not a one-time linear architecture project.

Keep architecture scope visible. Enterprise, segment, capability, and solution-level work may require different depth. The same method can be tailored rather than forcing every engagement to model the entire enterprise.

Week 3: practice stakeholder and requirements management

Create a stakeholder map with concerns, influence, decision rights, and appropriate communication views. Then add a new regulatory or business requirement halfway through the scenario and trace how the architecture changes.

Requirements management runs across the ADM. Practice identifying when a changed requirement needs a local design adjustment versus a larger architecture decision or new iteration.

Use competing stakeholder concerns deliberately. A security leader may want tighter control while a product leader wants faster delivery. Architecture should make the tradeoff visible and identify principles or requirements that constrain the decision.

Record requirements with source, rationale, priority, and traceability. When a requirement changes, you should know which architecture decisions and artifacts need review.

Week 4: work on techniques, content, and building blocks

Practice gap analysis, business scenarios, interoperability or risk considerations, migration analysis, and other TOGAF techniques at the level required to support decisions. Use the techniques on your scenario instead of memorizing labels.

Review deliverables, artifacts, catalogs, matrices, diagrams, views, viewpoints, and architecture building blocks. Explain which item communicates to stakeholders and which represents reusable architecture content.

Use gap analysis against baseline and target states and then connect each gap to a work package, dependency, or architecture decision. A list of gaps becomes valuable only when it informs change.

Practice viewpoints by audience. Build an executive capability view and a technical integration view from the same architecture. Each should be accurate but intentionally different because stakeholder concerns differ.

Week 5: study governance and implementation

Architecture governance should connect approved designs to real delivery. Practice conformance reviews, architecture contracts or governance mechanisms, exception handling, and what happens when implementation evidence reveals that an architecture assumption was wrong.

The PMP exam is a useful project-management boundary. Delivery management and enterprise architecture collaborate, but TOGAF governance is not a replacement for schedule, resource, procurement, or project-control methods.

Create a conformance-review checklist for one project. Include architecture principles, required building blocks, security or risk requirements, approved deviations, and evidence the delivery team must present.

Then simulate a nonconformance. Decide whether the team should correct implementation, request a waiver, or trigger an architecture change. Governance should make deviations visible and deliberate, not simply punish teams for discovering new information.

Week 6: begin Part 2 ranking practice

Use scenario questions and rank all answer choices from best to worst. The combined exam’s practitioner section uses gradient scoring, so several answers may be partly reasonable while one is most appropriate.

Before checking the reference material, state the ADM context, stakeholder concern, and objective. Then use the provided open-book content only to confirm a point. This develops judgment instead of search dependence.

Create a rule for explaining your ranking: best answer fits the scenario and method directly, second-best is useful but incomplete, third is contextually weak, and worst is inconsistent with the stated objective. This turns gradient scoring into a repeatable analysis process.

Avoid selecting an answer simply because it contains more TOGAF vocabulary. Practitioner questions reward fit and sequence, not density of framework terms.

Week 7: practice open-book navigation

The Part 2 reference material includes the TOGAF Fundamental Content and applicable Series Guides. Learn where ADM, techniques, content, governance, agility, business capabilities, value streams, risk/security integration, and digital-enterprise guidance live.

Set a short timer to locate specific concepts. You should be able to find confirmation quickly after you have already reasoned about the scenario. If basic navigation takes several minutes, the open-book format can become a time trap.

Use bookmarks or the exam interface’s reference organization during practice rather than relying on browser search habits that may not exist in the real environment. Know the document structure and major headings.

Record the concepts that repeatedly force you into the reference material. If the same basic topic requires lookup every time, move it into closed-book memory so Part 2 time is reserved for genuinely nuanced questions.

Week 8: integrate architecture with service and delivery contexts

Use ITIL Foundation Version 5 as a boundary for service-management thinking. TOGAF can define target enterprise capabilities and structures, while ITIL can guide how digital products and services are operated and improved.

The distinction helps in scenarios where delivery, operations, or service concerns appear. Architecture should address enterprise direction and structural coherence without trying to replace every delivery or service-management method.

Add one agile-delivery scenario where architecture decisions must be made incrementally. Decide what minimum architectural direction is needed now and what can evolve through later iterations without losing governance.

This helps you apply TOGAF in modern delivery environments rather than assuming enterprise architecture always means a long, sequential documentation phase before implementation begins.

Final week: simulate both exam sections

Run a closed-book Part 1 set under time, take a short reset, then complete scenario-style Part 2 practice with reference material. Review errors separately: knowledge gaps versus application errors.

If you fail one section in the real combined exam, The Open Group allows the failed part to be retaken separately after the applicable waiting period. That is useful policy context, but preparation should still aim for balanced readiness across both sections in one sitting.

Practice the full duration at least once. The combined exam is long enough that concentration becomes part of performance. Learn how to pace Part 1 without rushing and how to reserve deliberate reasoning time for the eight Part 2 scenarios.

Review the retake and exam-day policies before scheduling, especially if you plan OnVUE. Logistics should be settled before the study plan ends so the final week can focus on architecture rather than exam administration.

Use one architecture case as your final memory anchor.

Write a compact case with business goals, stakeholders, baseline and target states, requirements, gaps, architecture content, migration, governance, and change. Reconstruct the decision flow without notes.

The TOGAF Enterprise Architecture Practitioner credential is the qualification OGEA-103 is designed to achieve through the combined route.

The The Open Group exam inventory can help place OGEA-101, OGEA-102, OGEA-103, and bridge options. OGEA-103 readiness still means both recall and application.

Choose a case complicated enough to require several iterations but simple enough to remember. A merger, cloud transformation, or new digital platform works well because business, data, application, technology, migration, and governance concerns all appear naturally.

Reconstruct the case from a blank page the day before the exam. If you can place TOGAF concepts into that story, you are more likely to recognize them inside unfamiliar Part 2 scenarios.

Finish by ranking three alternative architecture responses to one final scenario and explain why the best answer fits the ADM context, stakeholders, and requirements more completely than the others.

That comparison is the final bridge from Foundation recall to Practitioner judgment.

Keep the final case simple enough to recall quickly, but rich enough to include stakeholders, requirements, gaps, migration, governance, and iteration.

img