OGEA-103 combines Foundation knowledge with Practitioner application, so the most useful study map has two layers. The first layer explains the TOGAF concepts, ADM phases, techniques, governance, and architecture content. The second layer shows how a practitioner uses those elements to define context, manage stakeholders, develop architectures, plan implementation, govern realization, manage change, and maintain requirements.<\/p>\n
The current OGEA-103<\/a> combined exam tests both layers in one sitting: 40 closed-book foundation questions followed by 8 open-book scenario questions. The map below is designed to show how the two sections reinforce each other.<\/p>\n Enterprise Architecture, stakeholders, concerns, views\/viewpoints, building blocks, Architecture Landscape, Enterprise Continuum, capability, governance, and the structure of the TOGAF Standard give architects a shared vocabulary.<\/p>\n Foundation questions test whether that vocabulary is understood. Practitioner questions assume it and ask how the concepts affect a real decision.<\/p>\n The Preliminary Phase establishes architecture capability and governance context. Phase A creates the Architecture Vision. Phases B, C, and D develop domain architectures. Phases E and F organize implementation and migration. Phase G governs implementation. Phase H manages change. Requirements Management interacts with all of them.<\/p>\n A the TOGAF method<\/a> is most useful when the ADM is drawn as an iterative framework rather than a simple linear project plan.<\/p>\n Architecture requirements are identified, refined, prioritized, traced, and governed throughout the ADM. A new requirement can influence current architecture work and a decision in one phase can create or change requirements elsewhere.<\/p>\n The domain map should therefore place Requirements Management in the center rather than after the phases.<\/p>\n Stakeholder management, business scenarios, gap analysis, migration planning, risk\/security integration, capability assessment, interoperability analysis, trade-off analysis, and other techniques support different ADM activities.<\/p>\n The technique is chosen because it solves an architecture problem. Memorizing the name without knowing when it is useful leaves Practitioner scenarios difficult.<\/p>\n The Architecture Vision establishes why architecture work is needed, which stakeholders and concerns matter, the scope and constraints, and how value will be communicated. Practitioner scenarios often begin here because weak scope or stakeholder alignment creates problems throughout the cycle.<\/p>\n Phase A is the bridge between enterprise motivation and structured architecture development.<\/p>\n Business Architecture describes business capabilities\/process\/value and organizational needs. Information Systems Architecture covers data and application concerns. Technology Architecture covers the technology environment that supports them.<\/p>\n The practitioner map should connect baseline, target, gaps, requirements, artifacts, and building blocks across these domains rather than developing each in isolation.<\/p>\n Opportunities and Solutions identifies work packages and transition architectures. Migration Planning prioritizes projects and builds an implementation\/migration plan that considers value, risk, dependencies, resources, and sequencing.<\/p>\n This is where architecture becomes a realistic transformation roadmap rather than a set of target-state diagrams.<\/p>\n Implementation Governance monitors whether projects conform to the architecture, manages deviations, uses architecture contracts or governance mechanisms where appropriate, and ensures architecture decisions remain connected to delivery.<\/p>\n The map should show feedback from implementation back to requirements and change management because delivery can expose new constraints or risks.<\/p>\n Architecture Change Management monitors technology and business change, evaluates requests, determines whether incremental change or a new ADM cycle is needed, and sustains the architecture over time.<\/p>\n This explains why TOGAF Practitioner capability extends beyond creating one target architecture. Enterprise Architecture is a continuing management practice.<\/p>\n Architecture Governance provides decision rights, review, compliance, and accountability, while the Architecture Content Framework organizes deliverables, artifacts, and building blocks. The Architecture Repository supports reuse and institutional memory.<\/p>\nCore concepts provide the common language<\/h3>\n
The ADM is the organizing spine<\/h3>\n
Requirements sit across the whole cycle<\/h3>\n
Techniques turn the ADM into practical work<\/h3>\n
Phase A connects strategy, stakeholders, and scope<\/h3>\n
Phases B, C, and D develop the target across architecture domains<\/h3>\n
Phases E and F turn gaps into a change roadmap<\/h3>\n
Phase G protects architecture intent during implementation<\/h3>\n
Phase H keeps the Architecture Landscape current<\/h3>\n
Governance and content make the whole map reviewable<\/h3>\n