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

OGEA-103 is The Open Group's combined TOGAF Enterprise Architecture Part 1 and Part 2 examination. It offers a direct path toward the TOGAF Enterprise Architecture Practitioner qualification and should not be mistaken for a separate new edition of the TOGAF Standard. The Open Group's materials describe a combined examination comprising 40 Foundation multiple-choice questions and eight scenario-based Practitioner questions. The sections have different reference conditions: Part 1 is closed book, while Part 2 provides specified reference materials within the testing interface. The combined examination uses a 150-minute overall time allocation according to official candidate guidance.

This distinction should shape preparation. Knowing the Architecture Development Method's phases and artifacts is necessary, but the Practitioner section asks for judgments in imperfect organizational situations. The most appropriate answer often depends on stakeholder priorities, scope, risk, decision rights, and the evidence available. A plan that only memorizes definitions may be enough to recognize terminology and still be inadequate for evaluating complex architecture options.

Decide whether a combined examination fits

The Open Group offers a staged route through OGEA-101 and OGEA-102 as well as the OGEA-103 combined option. For a candidate already comfortable with the Foundation body of knowledge, the combined route may align with a focused study plan. Someone learning enterprise architecture for the first time may prefer to complete the Foundation learning before attempting the full Practitioner reasoning. The better choice depends on existing competence, confidence with scenarios, registration rules, and the time available.

The combined exam has distinct pass requirements for its two sections. The Open Group's FAQ explains that if a candidate fails one part, only that part must be retaken after the applicable waiting period; however, the combined examination does not award the Foundation qualification merely because the Foundation section is passed while the other fails. This policy is important when comparing the perceived efficiency of one appointment with the flexibility of separate exams. Verify the current policy and available languages through the official registration system.

The OGEA-101 Foundation exam forms the conceptual base. Practitioner readiness requires applying those concepts to architecture problems where several plausible options have different strengths and weaknesses.

Interpret architectural scenarios before choosing an action

Scenario-based questions may describe a business problem, the current architecture capability, organizational constraints, stakeholders, and a set of possible next actions. A productive first step is identifying what the situation is actually asking the architect to accomplish. Is the issue an unclear vision, a missing business capability model, conflicting stakeholder concerns, an inadequate transition plan, or ungoverned implementation change? Choosing a familiar ADM technique without diagnosing the scenario can produce an answer that sounds official but does not address the problem.

Separate facts from assumptions. An organization may be described as having a mature architecture board but incomplete application inventories. That does not automatically imply that governance is the first thing to establish; the missing information may be more relevant to the task. Conversely, an excellent diagram cannot compensate for an unresolved decision-rights dispute that prevents agreement on a target architecture.

When comparing alternatives, identify why one is stronger in the given context. The best answer may balance timeliness, stakeholder engagement, traceability, and the need for sufficient detail rather than maximizing one attribute alone. The exercise resembles professional decision-making more than recalling a definition.

Apply ADM tailoring and iterative development

A rigid interpretation of the ADM can be ineffective in a real organization. TOGAF allows adaptation to the enterprise's maturity, the scope of change, and the chosen delivery approach. Practitioner scenarios may expect the architect to select appropriate iteration cycles, define what outputs are needed, and coordinate architecture activity with projects and portfolios.

Consider a program modernizing several customer-facing applications. Business capabilities and target information needs may be relatively clear, but network, identity, and hosting constraints remain uncertain. It may be prudent to iterate between information-systems and technology architecture work while keeping the business outcomes and requirements traceable. Finishing every catalog before engaging a technical delivery team would not necessarily improve the result.

Tailoring must be justified. Removing an approval stage can reduce delay, yet it may expose the enterprise to unacceptable risk if the stage enforces a regulatory constraint. The architect should understand which control objective needs preserving and whether a more efficient mechanism can achieve it.

Manage stakeholders and enterprise-level tradeoffs

Architecture work is influenced by stakeholders who own budgets, processes, platforms, data, risks, and compliance. Effective engagement requires recognizing their concerns and adapting communication accordingly. A CIO may need an enterprise roadmap, a product owner may need constraints on a delivery decision, and a regulator may need evidence that a specific obligation was addressed.

Tradeoffs should be recorded. Reusing a common service may reduce long-term operating complexity while slowing one project's immediate delivery. Decentralized autonomy may accelerate local change while creating duplicate capabilities and inconsistent security controls. A defensible architecture decision identifies the value gained, cost and risk accepted, and authority responsible for approving the choice.

Architecture viewpoints help explain decisions without overwhelming every stakeholder with the same information. A capability map can support investment prioritization; a dependency view can expose migration risk; an architecture roadmap can help program owners sequence delivery. An artifact that looks comprehensive but does not support a decision is not necessarily the most appropriate output.

Connect gaps to migration planning

Gap analysis compares baseline and target architectures to identify capabilities that must be introduced, removed, changed, or retained. Those gaps feed work packages and transition planning. A common weak answer jumps from a desired future state directly to a project list without analyzing dependencies, implementation risks, sequencing, or intermediate operational states.

Transition architectures can be necessary when an enterprise cannot move safely from baseline to target in a single step. For example, replacing a customer-data platform may require coexistence between old and new applications, dual reporting for a limited period, data-validation controls, and a staged decommissioning plan. Those arrangements should be explicit, time-bounded where feasible, and connected to risk ownership.

The TOGAF Architecture Development Method helps frame these relationships, but a candidate should practice explaining why a particular migration sequence supports business benefits and reduces operational disruption. A schedule is not a good roadmap unless it shows how architectural dependencies and constraints were considered.

Govern implementation without freezing all change

Practitioner-level judgment often involves situations where delivery teams discover constraints that were not evident during architecture design. Implementation governance should provide a mechanism for conformance assessment, exception handling, and resolution of important deviations. It should not be a ceremonial approval that happens once and is forgotten.

Decide whether a proposed variation undermines an architecture principle, changes a required capability, or simply reflects a lower-level implementation choice that can remain within agreed boundaries. Treating every local change as a fundamental architecture violation creates bureaucracy; allowing every project to redefine shared standards creates fragmentation. Good governance separates these cases and records who has the authority to decide.

Architecture change management also applies when enterprise circumstances change after initial approval. A merger, new data residency rule, or major platform change may invalidate a target assumption. The architect should determine whether the existing work needs a focused update, a new iteration, or a larger reconsideration of the business and technology context.

Practice ranking plausible responses by their consequences

The Practitioner section may present several answers that use legitimate TOGAF activities. The candidate's challenge is to identify the response that best fits the described situation. Build a comparison method: what is the current architectural problem, which stakeholders are affected, what evidence is missing, what stage of the work is underway, and what consequences could follow from each option? Then judge the options against those factors rather than choosing the one containing the most familiar terms.

For example, when a proposed migration lacks agreement on business priorities, producing a detailed technology design may be premature even though a technology model will eventually be needed. When implementation teams repeatedly violate an agreed data-governance principle, creating more architecture views may not resolve the underlying absence of decision rights or compliance review. The appropriate intervention changes with context.

After each practice case, write a two-sentence rationale for the preferred answer and a concise reason why the nearest alternative is weaker. This technique teaches comparative judgment. It also improves use of the permitted reference materials: instead of searching a large body of knowledge for the question's exact wording, the candidate can identify which architecture concept governs the decision.

Use the open-book reference strategically

The Practitioner portion of the combined examination provides an electronic reference through the testing system. This is not unrestricted access to personal notes or the internet. Candidates should become familiar with the organization and terminology of the permitted body of knowledge, but should not rely on searching the reference for every answer under time pressure. Scenario judgment still requires understanding which part of the method applies and why.

The Foundation portion is closed book, so core terminology must be learned well enough to recognize and apply it without aids. Develop a reference map from architecture concepts to ADM activities, content, governance, and transition planning. Then practice scenarios where the context changes: a centralized enterprise may face different stakeholder and governance challenges from a federated one.

The Open Group certifications distinguish foundational knowledge from applied architecture judgment, while issuer materials determine the current eligibility and exam rules. Preparing for OGEA-103 is strongest when the candidate can explain the architecture problem, compare realistic approaches, and choose the option that best satisfies the organization's actual needs—not merely select the option containing the most TOGAF terminology.