TOGAF OGEA-103: Applying Architecture Judgment Across Both Exam Parts

OGEA-103 is The Open Group's combined TOGAF Enterprise Architecture Part 1 and Part 2 examination. It offers a direct route toward the TOGAF Enterprise Architecture Practitioner qualification for candidates taking the combined assessment. Official publisher material distinguishes two sections: a forty-question Foundation component that is closed book, followed by eight scenario-based Part 2 questions that are open book using the authorized electronic material provided in the examination interface. The published combined exam time is two hours and thirty minutes. Candidates must use current official policies for section scoring, booking, and any language accommodations.

This combined route should not be confused with the standalone OGEA-101 Foundation examination. A candidate who already holds the qualifying Foundation credential may be better served by the separate Part 2 pathway, subject to the publisher's current eligibility rules. The combined examination requires both precise knowledge of TOGAF concepts and the ability to choose the most appropriate architectural response to a complex organizational scenario. The second ability cannot be developed by memorizing phase names alone.

Understand why the assessment has two different demands

Foundation questions establish whether the candidate recognizes TOGAF terminology, architecture content, governance, and the Architecture Development Method. Their closed-book format rewards conceptual recall and clear distinctions between related constructs. Practitioner scenarios instead ask for judgment when several actions appear plausible. A defensible response must account for the stakeholder concern, current architecture state, organizational constraints, and the particular ADM activity underway.

The existence of reference material in the Practitioner section should not be mistaken for unlimited study time or unrestricted internet access. The approved reference is presented within the exam environment, and the candidate must know where relevant concepts are located. Searching a large text without a conceptual model can consume valuable time. Prepare by connecting a practical decision to the relevant method, artifact, governance mechanism, or iteration strategy before opening the reference.

A combined candidate also faces attention management. After completing a closed-book knowledge section, there is still a substantive judgment assessment to finish. Practice switching from concise factual questions to longer scenarios rather than studying only one format. Learn to read the case's requested decision before examining each possible response. The goal is to apply knowledge efficiently while maintaining enough care to identify hidden constraints.

Interpret the situation before choosing an ADM action

Consider an enterprise acquiring another company with incompatible customer records and separate identity systems. The immediate challenge may be clarifying architecture scope, stakeholder concerns, and current-state dependencies before selecting a target integration platform. A plausible answer that begins purchasing infrastructure might be technically feasible but premature. The architect must first determine what has been agreed, what evidence is missing, and which ADM activity can reduce uncertainty.

Architecture work is iterative. If a later assessment reveals that a proposed solution cannot satisfy a regulatory requirement, the correct response may involve revisiting a prior architecture decision rather than pressing forward to preserve a project schedule. Describe the trigger and the impact on dependent work. Iteration is not synonymous with restarting every phase; it is a deliberate response to changed evidence, scope, or stakeholder needs. A scenario may distinguish candidates who understand controlled iteration from those who follow a rigid flowchart.

Distinguish planning a transition from designing the target state. An excellent future architecture can still fail if its migration sequence ignores business continuity, organizational change, data quality, and temporary coexistence. Evaluate how intermediate states affect services. A combined examination may require judging which next step preserves the integrity of the architecture approach while limiting disruption.

Apply stakeholder concerns and viewpoints deliberately

Architecture viewpoints are not decorative diagrams. They determine how concerns are represented and which decisions a stakeholder can evaluate. A board considering investment priorities may need capability gaps and migration dependencies, while engineers need system interfaces and deployment boundaries. In a scenario, ask who is asking the question and what evidence would answer them. Offering an application-interface model to resolve a portfolio funding dispute may be a weaker choice than presenting capability and transition options.

Conflict between stakeholders is normal. One team may prefer accelerated delivery, another may require tighter controls, and a third may be responsible for long-term maintainability. A strong answer makes the constraints and trade-offs visible, perhaps through structured architecture principles or a governed exception. Do not assume a senior sponsor's preference automatically overrides all other obligations. The architecture process provides a way to surface and resolve competing concerns using agreed decision rights.

When evaluating candidate actions, separate missing information from actual disagreement. If teams use different definitions for a critical business entity, more detailed implementation design may worsen the problem. Establish shared meaning and ownership before committing to integration interfaces. If everyone agrees on terminology but disputes timing, migration planning and stakeholder impact analysis may be the more relevant activity. The same technology can require different architectural responses depending on the underlying problem.

Use governance as a practical constraint on delivery

Implementation Governance ensures that delivery stays aligned with the approved architecture and that deviations are visible. In a scenario, an implementation team might request an exception because a standard service cannot meet a release date. A poor response would either approve it without analysis or reject it without considering business impact. Better reasoning identifies the relevant architecture principles, the risk and consequences of the deviation, alternative approaches, and the authorized approval process.

Architecture compliance reviews must be timely enough to influence decisions. If a review occurs only after a major deployment, architectural control may exist on paper but provide little protection. Define accountable owners, evidence expectations, and remediation or exception paths. A controlled exception may be appropriate when its scope and expiry are clear; an undocumented exception creates technical debt that future teams may mistake for an accepted standard.

Governance also involves transition state. During a merger, temporary integrations may be unavoidable. The decision should explain which transitional risks are accepted, how data quality will be checked, and what marks the end of the temporary arrangement. Architecture judgments are better when the timing of choices and responsibilities are explicit. The practitioner is expected to manage real organizational constraints rather than insist on an ideal design divorced from delivery.

Compare solution options using architecture content

Candidates should understand how architecture descriptions, building blocks, deliverables, and repository assets support alternative evaluation. A reference architecture may accelerate the design of a common capability, but its reuse requires an assessment of context, constraints, and required variation. A business capability is not the same thing as a particular software product, and an architecture building block is not always a deployable solution component. This abstraction helps avoid decisions driven solely by vendor familiarity.

A practical comparison includes expected outcomes, required changes, costs, operational effects, security exposure, and dependencies. The favored option should respond to the stated concern and architecture principles. If a decision depends on a fact not provided by the scenario, identify the gap rather than inventing favorable assumptions. More technical detail is not necessarily the better answer; the question may ask for governance, stakeholder alignment, or further discovery rather than a design specification.

Repositories and existing enterprise standards can serve as starting points, but they should not become unexamined rules. When a standard conflicts with a new regulatory need, the architect should use the change and governance mechanisms to evaluate the conflict. When a historical diagram is out of date, it should not be treated as conclusive evidence. Practitioner-level reasoning balances reuse with evidence of present applicability.

Practice cases should contain distractors that are partly sensible. Suppose the architecture team has identified a critical data-quality gap but has not yet agreed on business ownership. A detailed technology implementation plan could be an eventual necessity, yet establishing responsibility and shared definitions might be the best immediate action. Explain why the alternatives are premature, not why they are universally wrong. This is the essence of situation-dependent architecture judgment.

A second case can involve a business sponsor who wants an accelerated rollout while a security reviewer identifies an unresolved requirement. Assess whether the responsible next step is risk evaluation, stakeholder agreement, a governed exception, or further technical investigation. The answer depends on who has decision authority, the nature of the obligation, and what is already known. Practicing with these variables develops a reliable method of interpreting scenarios.

During an open-book section, reference material is a support for reasoning rather than a substitute for it. Form a tentative answer, locate the relevant TOGAF concept in the authorized material, and check whether the wording or circumstances require revision. A candidate who starts by searching for every phrase can lose time without understanding what the question actually asks. By contrast, a candidate who memorizes answer patterns may ignore a crucial change in stakeholder concern.

When reviewing missed scenarios, write a concise explanation of the deciding fact. Examples include a missing architecture requirement, the wrong governance authority, an unassessed migration dependency, or a misidentified ADM activity. This diagnosis is more useful than simply recording the chosen option and lets candidates prepare for new situations rather than variations of a remembered question.

Practice scenario evaluation without memorizing answer patterns

Create several cases with contrasting constraints: a cloud migration with uncertain data sovereignty, a merger with duplicate business capabilities, and an application replacement with high availability obligations. For each case, identify the stage of architecture work, the stakeholder concern, key missing facts, and the risks of acting too soon. Generate multiple plausible responses and explain why one is more aligned with the TOGAF method at that moment. This exercise mirrors the reasoning task without reproducing confidential exam questions.

Review publisher-authorized case materials and use the permitted open-book reference when preparing for Part 2. Learn to locate sections quickly while making your reasoning independently of quotations. Practice the Foundation concepts without reference material, then alternate to case judgments using the correct conditions. The skill of deciding which concept matters is as important as the skill of finding its definition.

The Open Group explains that when only one part of a combined exam is passed, candidates generally need to retake the missing part rather than repeating the entire combined examination; confirm the policy applicable to your attempt before registering again. The broader message is that OGEA-103 measures two connected capabilities: knowing the framework and using it to direct responsible architecture decisions when the situation is messy, constrained, and changing.