TOGAF OGEA-103: The Combined Foundation-to-Practitioner Route

OGEA-103 is the TOGAF Enterprise Architecture Combined Part 1 and Part 2 examination. The Open Group identifies it as a route to the Practitioner qualification for candidates who want to demonstrate foundation knowledge and scenario-based application in one examination. This distinction matters: OGEA-103 is not simply Part 2 under a different code. It includes the Part 1 closed-book knowledge component and the Part 2 open-book scenario component, each with its own style of reasoning. Candidates must be able to explain the terminology of the TOGAF Standard, 10th Edition and then evaluate architectural decisions in realistic situations. The central preparation challenge is switching from recognizing concepts to prioritizing competing actions under stakeholder, risk and transformation constraints.

Treat the examination as two different mental tasks

In Part 1, the candidate establishes familiarity with architectural concepts, the Architecture Development Method, governance, content and supporting techniques. The examination rewards accurate recognition of the relationships among those elements. In Part 2, a scenario presents a context with multiple plausible approaches and asks which option best reflects sound architectural practice. The ability to recall a phase name is rarely sufficient to rank nuanced responses.

Consider a firm planning to merge several regional technology estates. Part 1 may assess what gap analysis or implementation governance means. A Part 2-style situation may ask how to respond when a proposed migration conflicts with a regulatory commitment or when two stakeholders have different priorities. Several choices might be technically reasonable; the strongest one is often the action that respects the current architecture work, decision rights and evidence available.

Plan preparation around the different cognitive demands. Short concept quizzes help test vocabulary, but they do not reproduce the work of evaluating scenario context. Conversely, attempting complex cases without understanding the ADM leads to superficial reasoning about what sounds prudent. The combined examination requires the two forms of competence to reinforce each other, not compete for study time.

Read the architecture problem before choosing the framework tool

A complex scenario contains many details, but only some drive the decision. Identify the stated business objective, current architecture state, stakeholder concerns, mandatory constraints and phase of work. Distinguish a missing requirement from an implementation deviation, and identify whether a decision has already been approved. Recommending a fresh preliminary assessment when an approved baseline and gap analysis already exist can waste time or undermine governance.

Imagine an insurer undertaking a data-platform modernization. The architecture team has completed a target design and migration plan, but a delivery team proposes replacing a critical integration for convenience. The response should consider whether the proposal changes an architectural requirement, affects agreed risk tolerances, or needs formal assessment under implementation governance. Merely praising innovation or insisting that every previous decision is immutable misses the actual problem.

Use evidence to decide when to revisit earlier work. TOGAF is iterative, but iteration is not an excuse to restart every phase whenever new information appears. Identify exactly which assumptions changed and what targeted review would resolve them. In a scenario assessment, the best choice usually demonstrates proportionate architectural action rather than vague escalation or mechanical obedience to a phase label.

Use the ADM to connect strategy and practical change

The ADM coordinates architecture vision, business architecture, information systems, technology, migration and governance activities. Applying the ADM to scenarios means selecting which architecture work advances an initiative without losing alignment to business outcomes. A company may have a well-defined technology target but insufficient agreement on business capabilities; another may have clear business requirements but no viable transition architecture.

Suppose a university wants to improve student onboarding by integrating identity, admissions, payments and learning systems. An architect must map the baseline processes and target capabilities, identify shared data requirements and recognize the implications of external suppliers. Migration planning should sequence components so that services remain usable during change. A purely technical solution that ignores term-start peaks and registration deadlines is an incomplete architecture decision.

When evaluating possible actions, ask what the current phase is meant to produce and how that output informs the next decision. Some information is required to make a defensible commitment; other detail can be refined during later solution design. The skilled practitioner maintains enough structure to preserve traceability while tailoring the method to the organization's scale, constraints and architecture maturity.

Balance architecture governance with delivery authority

Architecture governance ensures that strategic and regulatory considerations are respected throughout implementation. It should not replace day-to-day engineering leadership. A practitioner needs to know when a delivery team can make a local optimization, when architecture review is needed, and when an approved deviation should be recorded and monitored. The strongest governance response matches the significance and scope of the decision.

For example, a team proposes adopting a different messaging technology because it improves a narrow service. Determine whether the switch affects enterprise integration standards, data protection, operations or other dependent teams. If the impact is small and within delegated authority, formal escalation may be unnecessary. If the change would create a new cross-company platform dependency, architecture governance should assess the consequences before the organization is committed.

Practitioner cases often test this proportionality. An overbearing review process can slow delivery without improving outcomes; no oversight can create uncontrolled architecture drift. Describe the evidence necessary to justify an exception, its owner and its expected duration. Governance works when it makes real trade-offs visible and reviewable, not when it produces a blanket yes or no irrespective of business context.

Work with stakeholders who disagree for valid reasons

Enterprise transformations regularly contain conflicting concerns. Security may prefer strict central control, operations may need uninterrupted service, business leaders may prioritize market timing and developers may require flexibility. A practitioner should not assume that one function's perspective is universally superior. Use architecture viewpoints to expose the impact of alternatives and enable accountable decisions.

Consider a public agency consolidating citizen services. A central data repository may simplify reporting but introduce privacy and residency concerns; leaving data entirely in separate systems may preserve autonomy while making service delivery harder. Develop views that show data flows, business capabilities, access boundaries and likely costs. Stakeholders can then weigh the options against shared objectives rather than argue about incompatible diagrams.

Strong scenario reasoning distinguishes stakeholder concerns from stated preferences. Someone may say they want an immediate platform replacement while their underlying need is improved reporting reliability. The architect can meet the need through a phased approach that preserves essential services. The best answer often names the decision-making process that produces an informed compromise rather than favoring the most senior or most emphatic participant.

Choose migration steps that preserve value and reversibility

Transition architectures and migration planning translate a desired state into a sequence that can be funded, governed and operated. An end-state diagram alone does not explain how to move from today's fragmented systems to tomorrow's integrated capabilities. Dependencies, data conversion, workforce readiness and service continuity shape the plan. The architect should identify which capabilities can be delivered incrementally and which require coordinated change.

Imagine a retailer replacing a legacy order-management system. Moving every store at once might be technically possible but introduces significant business risk. A pilot with a defined data reconciliation method, explicit success criteria and a fallback option may reduce uncertainty. Yet a pilot that cannot represent real peak traffic can produce false confidence. Sequence choices need to reflect actual operational constraints and risk appetite.

Use migration analysis to expose trade-offs in cost, risk, time and value. A low-cost path that leaves multiple incompatible interfaces in place may create long-term complexity. A large transformation with no interim benefit may become politically or financially unsustainable. Practitioner judgment means selecting a path whose benefits, dependencies and governance can be explained to the people funding and implementing it.

Use the open-book component for reasoning, not frantic lookup

The Open Group's combined exam makes the Part 2 reference material available in the appropriate section. Open-book does not mean every answer can be found by searching for one phrase. Scenario options may all contain concepts mentioned in the standard; the task is to judge which application best fits the described state, constraints and decision rights. Candidates who depend entirely on lookup can lose time while failing to resolve the underlying trade-off.

Practice with case studies by reading the question and the scenario before consulting the reference. Summarize the architecture problem in one sentence and identify the decisive constraint. Then assess each answer for what it assumes, what it would achieve and what it might ignore. An action that sounds thorough can be wrong if it repeats completed work or treats a local issue as an enterprise-wide redesign.

Learn where essential topics reside in the reference material and understand how to navigate them efficiently. Do not try to memorize an entire book word for word. Build a conceptual map that connects ADM activities, governance, requirements, architecture content and migration decisions. That map reduces lookup time and allows a candidate to see why a plausible answer may be less suitable than a more context-aware alternative.

Prepare with full cases and explicit option critique

Build two kinds of practice. First, test the terminology and concept relationships expected of OGEA-101 (TOGAF Part 1). Second, work through longer architecture scenarios where multiple reasonable options compete. Write down the governing business objective, the evidence available, the important missing information and the action most consistent with appropriate architecture practice. Explain why each rejected option is premature, too broad or insufficiently governed.

A useful case involves a merger, a multi-cloud policy change or a new digital service operating under strong data-residency constraints. Begin with agreed stakeholder concerns, map baseline and target capabilities, propose migration alternatives and then add a late discovery that forces revision. This tests whether the learner can use the method adaptively without abandoning rigor.

The official exam structure is forty Part 1 multiple-choice questions plus eight Part 2 scenario-based items, with different reference rules in each section. Confirm current timing, scoring and accommodations with The Open Group before booking. The combined route is valuable when a candidate is ready to demonstrate both foundation understanding and responsible architectural choice. It does not eliminate the need for real project judgment after certification.