The Open Group OGEA-103: What the Exam Tests

OGEA-103 is the combined TOGAF Enterprise Architecture Part 1 and Part 2 examination based on the TOGAF Standard, 10th Edition. The OGEA-103 exam is designed for candidates who want to earn the TOGAF Enterprise Architecture Practitioner qualification directly rather than taking the Foundation and Practitioner exams separately.

The combined format has two very different sections: a closed-book Part 1 section with 40 simple multiple-choice questions and an open-book Part 2 section with eight scenario-based complex multiple-choice questions. The exam therefore tests both knowledge of the TOGAF approach and the ability to apply it to realistic enterprise architecture decisions.

Foundation knowledge still matters in a practitioner exam

The first section requires candidates to know the structure, terminology, concepts, and purpose of the TOGAF approach well enough to answer without reference materials. That includes the Architecture Development Method, Enterprise Architecture concepts, governance, content, stakeholders, requirements, and the broader role of architecture in organizational change.

The OGEA-101 Part 1 exam represents the Foundation portion when taken separately. Candidates using OGEA-103 should prepare that knowledge to the same standard because the combined route does not remove the closed-book requirement.

Practitioner questions are about application and analysis

The Open Group describes Practitioner-level competency as applying and analyzing the TOGAF Standard in real architecture work. Candidates are expected to tailor the ADM, apply iteration and partitioning, develop architectures through ADM phases, use supporting techniques, manage requirements, and support implementation and change.

This changes the way you study. Knowing that gap analysis exists is not enough; you should understand when to use it and what decision it informs. Knowing stakeholder management terminology is not enough; you should be able to identify which stakeholder concern matters to the architecture and how the engagement strategy changes.

ADM phases should form one connected method

Study the Architecture Development Method as a flow rather than a sequence of isolated definitions. Architecture Vision frames the work, Business Architecture and Information Systems Architecture develop target states, Technology Architecture defines the technology view, and later phases shape opportunities, migration, governance, and change.

The important skill is understanding what input and decision belongs at each point. A migration plan should not be invented before gaps and dependencies are understood, and implementation governance cannot compensate for a target architecture that never addressed stakeholder requirements.

Build one scenario and carry it through the ADM several times with different levels of detail. For a merger, for example, the first cycle may establish business capability and information priorities, while later iterations refine technology and migration decisions. This makes iteration and partitioning practical rather than abstract.

Also note where the method can be tailored. The TOGAF Standard is not intended to force every organization into one rigid sequence. Practitioner competence includes adapting the method while preserving the purpose of architecture development, governance, requirements, and stakeholder alignment.

Requirements management operates across the cycle

Architecture requirements are not a one-time document created before design begins. Requirements are identified, changed, validated, prioritized, and traced throughout the ADM. A decision in technology architecture can reveal a business constraint, while implementation planning can expose a requirement that needs clarification.

Practice tracing one requirement across several phases. For example, a regulatory data-residency requirement affects business policy, data architecture, technology choices, migration planning, and governance. This kind of traceability makes the method feel practical rather than procedural.

Stakeholder management shapes architecture communication

Enterprise architecture succeeds only when the right people understand the decisions that affect them. Practitioner questions can require you to distinguish stakeholders by power, interest, concern, decision authority, or influence and then decide how architecture views or communications should address those needs.

Do not assume every stakeholder needs the same diagram. Executives may need capability and outcome views, solution teams may need detailed building blocks and interfaces, and governance bodies may need evidence of compliance. Architecture communication is part of the architecture work.

Create a stakeholder matrix for your practice scenario and write the concern each person or group actually has. The CFO may care about cost and investment timing, operations may care about supportability, security may care about control and risk, and product leaders may care about speed and customer outcomes.

Then choose an architecture view for each audience. A good practitioner does not bury everyone under the same detailed model. They select viewpoints and artifacts that make the relevant decision understandable without losing architectural integrity.

Architecture content provides reusable structure

The TOGAF approach distinguishes deliverables, artifacts, views, viewpoints, and building blocks. Candidates should understand how architecture content helps teams communicate consistently without assuming every organization must produce every possible artifact.

A useful exercise is to take one architecture decision and represent it as a stakeholder-facing view, a more detailed artifact, and a reusable building block. Then explain which item becomes part of the architecture repository and which is primarily a communication vehicle.

Governance connects architecture to implementation

Architecture governance ensures that delivery remains aligned with agreed architecture and that deviations are visible, reviewed, and managed. This is different from project management. A project can be on time and on budget while still violating architecture principles or creating long-term technical debt.

The PMP exam is a useful adjacent boundary. Project management coordinates delivery, scope, schedule, stakeholders, resources, and risk; enterprise architecture defines and governs the structural direction within which projects and products should operate.

Practice a deviation scenario. A delivery team discovers that the approved architecture is expensive or technically difficult and proposes an alternative. Decide how the exception should be assessed, who needs to approve it, what new risk is introduced, and whether the architecture itself should change.

This is important because governance is not simply enforcing compliance. It also provides a controlled way to learn when implementation evidence shows that the original architecture assumption was wrong.

Part 2 rewards best-fit answers, not just correct facts

The Practitioner section uses scenario-based complex multiple-choice with gradient scoring. The best answer receives more points than a partially appropriate answer, which means several choices can contain technically reasonable TOGAF ideas.

Practice ranking options rather than asking only whether each statement is true. Which action best fits the scenario, ADM phase, stakeholder need, and architectural objective? This is why the open-book reference is not a shortcut: the challenge is judgment, not locating a definition.

Use gradient scoring as a study clue. When reviewing a scenario, rank all four answer choices from best to worst and justify the ordering. This forces you to distinguish an action that is generally sensible from the action that is most appropriate for the specific phase, concern, and constraint.

After ranking, use the open-book reference only to confirm a disputed point. This creates the same decision pattern you need in the real Part 2 section and reduces the temptation to search the book before you understand the problem.

Use the open book strategically

The Part 2 electronic Body of Knowledge should be treated as a confirmation resource, not as the primary way to solve the scenario. If you spend most of the time searching for basic concepts, you may not have enough time to compare the quality of the answer choices.

Build familiarity with the structure of the TOGAF material before exam day. Know where ADM guidance, techniques, content, governance, and other major topics live so you can confirm a detail quickly after you have already formed a reasoned answer.

Practice navigation under a timer. Give yourself two minutes to locate a specific concept in the Body of Knowledge and then return to the scenario. The goal is to confirm a point without allowing the reference material to replace architectural reasoning.

Enterprise architecture and service management solve different problems.

The ITIL Foundation Version 5 exam represents a different management perspective centered on digital product and service value, lifecycle, practices, and continual improvement. TOGAF Enterprise Architecture is broader structural guidance for developing and governing enterprise architecture.

The disciplines can support the same transformation without replacing one another. Architecture may define target capabilities, systems, information, and technology direction; service management helps the organization create, deliver, support, and improve the resulting products and services.

Prepare with architecture decisions, not vocabulary alone.

Take a transformation scenario and run it through the method: identify stakeholders and concerns, create an Architecture Vision, define baseline and target states, perform gap analysis, identify opportunities, create a migration approach, and define governance. Record why each step exists.

The The Open Group certification inventory can help you locate the Foundation, Part 2, bridge, and combined exam targets. For OGEA-103, the key is to combine closed-book fluency with practitioner judgment so the framework can be applied rather than merely recited.

Include one agile or digital-transformation example in your preparation. The Open Group explicitly positions the 10th Edition for modern, agile, and digital contexts, so practice how architecture can guide incremental delivery without becoming a large up-front documentation exercise.

Keep a short decision log during practice: issue, relevant stakeholder, ADM context, options, chosen approach, and reason. By exam week, that log becomes a compact set of applied examples that are easier to recall than isolated definitions.

• Category: All Certifications Certifications