TOGAF OGEA-103: From Foundations to Decisions

TOGAF OGEA-103 is not simply a test of definitions. It is The Open Group's combined TOGAF Enterprise Architecture Part 1 and Part 2 examination, covering foundational understanding and scenario-based application in one route to the TOGAF Enterprise Architecture Practitioner qualification. The OGEA-103 examination therefore calls for two different modes of thinking: recognizing the Architecture Development Method and related concepts, then selecting the best course of action in an organizational situation. The Part 1 section is closed book, while the Part 2 section supplies the relevant body of knowledge as an open-book reference. A useful preparation strategy must train both conceptual clarity and practical judgment.

Imagine a bank launching a multi-year effort to modernize payments, customer channels, data governance, and operational resilience. Its architecture team faces conflicting priorities from product owners, compliance leaders, technology operations, and executives. A methodology can help structure decisions, but no diagram or phase name removes those disagreements. The real value of TOGAF is a repeatable way to understand stakeholders, define target outcomes, examine change options, govern implementation, and revisit architecture as the organization learns.

Understand what the ADM is trying to achieve

The Architecture Development Method, or ADM, provides a structured cycle for developing and governing enterprise architecture. The process includes preliminary capability considerations, architecture vision, business architecture, information systems architecture, technology architecture, opportunities and solutions, migration planning, implementation governance, and architecture change management. Requirements management connects these activities rather than appearing only once at the beginning. Memorizing phase letters can support recall, but the important skill is knowing what decisions each phase helps an organization make and which outputs are needed to move responsibly.

A bank's architecture team might begin with a broad modernization vision, then discover that payments regulation requires one capability to be redesigned earlier than planned. The ADM is iterative, not a rigid waterfall script. Architecture work can cycle back to requirements, revisit stakeholder concerns, or refine a target state as evidence improves. A good practitioner recognizes when a decision requires further business clarification rather than inventing a technically detailed answer. The objective is controlled architectural progress aligned with business needs, not mechanical completion of phase documents.

Architecture vision establishes a reason to change

A compelling architecture vision identifies the business problem, intended outcomes, scope, stakeholders, constraints, and an acceptable basis for commitment. It should not begin with a product purchasing decision dressed up as strategy. The bank may want faster product launches, consistent customer information, stronger controls, and lower operational risk. Those are useful directions, but they need measurable definitions and ownership. A vision that promises every benefit without acknowledging trade-offs creates unrealistic expectations and weak later governance.

Stakeholder mapping matters because different groups judge success differently. A product team may prioritize delivery speed; operations may prioritize service continuity; compliance may demand auditable data use. Architecture practice must make these concerns explicit and negotiate constraints rather than declare one perspective universally correct. Communication artifacts should be selected for their audience: executives may need a clear outcome and risk picture, while delivery teams need capability gaps, dependencies, and transition decisions. The method encourages coherent reasoning across both levels.

Business architecture comes before technology assumptions

Business architecture explores capabilities, value streams, organization, and the processes or information needed to achieve goals. It can reveal that the organization's main obstacle is fragmented responsibility rather than outdated servers. The bank might have several customer-onboarding procedures that collect the same information but apply inconsistent controls. Replacing their underlying platforms without aligning policy and ownership may preserve the problem at greater cost. Business architecture clarifies what the enterprise must be able to do and where differences create strategic or operational harm.

Capability mapping can help prioritize investments because it separates a business ability from a specific application. The organization may need reliable fraud assessment even if the supporting vendor, algorithm, or hosting platform changes. Value-stream analysis shows where the capability contributes to customer and business outcomes. These models become useful inputs to later application, data, and technology architecture decisions. An exam scenario that mentions an unresolved business capability is often inviting a governance or requirements response rather than an immediate recommendation to deploy a technology component.

Data and application architecture expose dependencies

Information systems architecture addresses data and application concerns. For the bank, customer identity, payment events, risk decisions, and reconciliation records cross many processes. The architecture team should identify data ownership, authoritative sources, lifecycle controls, and integration patterns. A shared data model may solve certain inconsistencies but can also become a bottleneck if governance is unclear. Application portfolios require evaluation of redundancy, interfaces, business criticality, and lifecycle state, not only infrastructure modernization status.

Architectural choices need traceability to requirements. If the goal is reliable regulatory reporting, a data-lineage issue may matter more than the user interface. If the goal is faster product delivery, tightly coupled applications may be the central constraint. The ADM helps evaluate alternative building blocks and transition architectures without declaring one target diagram final for the entire program. The relevant outcome is a defensible set of dependencies and standards that support implementation and later change management.

Technology architecture translates without narrowing the problem

Infrastructure, networks, cloud services, integration platforms, and security components belong in technology architecture. They must satisfy the chosen application and data requirements rather than dictate them prematurely. A proposal to move every system to one cloud provider may be attractive for standardization but inappropriate for some sovereignty, latency, licensing, or resilience requirements. Architecture teams should examine constraints and nonfunctional characteristics before choosing. Standards are most helpful when they reduce ambiguity and unnecessary variation, not when they force unsuitable products into every business situation.

The architect should also distinguish architecture principles from implementation instructions. A principle favoring auditable identity access can guide many platforms; an instruction to configure a specific gateway is a deployment detail. Both can matter, but they operate at different decision levels. TOGAF's content framework helps maintain relationships among architecture descriptions, requirements, and deliverables. The method remains valuable when the organization changes technology stacks because the underlying reasoning is not tied to one vendor's interface.

Transition architectures make change executable

An ambitious target state does not mean the enterprise can replace every current system at once. Opportunities and Solutions and Migration Planning help identify work packages, dependencies, transition architectures, and a feasible sequence. The bank may need a modern identity service before consolidating channels, or an improved data-quality process before automating reporting. A roadmap should show which capabilities become available at each stage and which risks persist during coexistence. Sequence matters because an apparently independent project can rely on business definitions or infrastructure being delivered elsewhere.

Trade-offs become most concrete here. One option may deliver a quick benefit but introduce technical debt; another may take longer yet reduce long-term operating costs. Architecture work should make the reasoning visible to decision makers. A staged migration can be more resilient than a single cutover, but running old and new platforms concurrently also creates reconciliation and support costs. Strong scenario answers acknowledge those costs rather than treating a phased roadmap as automatically low risk. Each transition should offer a measurable outcome and an explicit basis for continuing, adapting, or stopping.

Governance is a means of learning and control

Implementation governance checks whether delivery aligns with the architecture and whether deviations are handled consciously. An architecture board should not exist only to approve documents. It needs a workable process for compliance assessment, change requests, exceptions, and decision records. In a complex program, exceptions may be justified by urgent business needs, but their impact and expiration should be understood. Unrecorded exceptions accumulate until the target architecture no longer describes the running organization.

Architecture change management keeps the system useful after initial implementation. New regulations, business acquisitions, threats, and customer expectations can invalidate assumptions. Rather than force every change through a complete restart, the organization should assess scope and significance, then decide whether a limited change or a new architectural cycle is appropriate. The broader TOGAF foundation exam emphasizes the conceptual vocabulary; the combined OGEA-103 requires using that vocabulary to support practical recommendations with credible reasoning.

Prepare for the two kinds of assessment

For Part 1, be able to distinguish phases, architecture concepts, governance responsibilities, and common deliverables without confusing neighboring terms. For the scenario-focused Part 2, read the organizational problem before considering the answer choices. Identify the stakeholder concern, current ADM context, missing evidence, and risk of moving too quickly. A technically detailed option may be weaker than an option that first clarifies requirements or obtains appropriate governance. Use the built-in Part 2 reference material to check concepts, but do not assume that searching a definition will replace judgment under time pressure.

Practice by taking one case study through architecture vision, capability analysis, application and data design, migration planning, and governance. At each stage, write down the decision that would most reduce uncertainty. Then create a new constraint, such as a regulatory change or technology failure, and explain how the ADM helps respond. The goal is to demonstrate why a recommendation fits the stated organization. That's the bridge from TOGAF terminology to practitioner competence that makes the combined exam more demanding and more useful than memorization alone.