Section 1: What Is Enterprise Architecture?
Enterprise Architecture (EA) is the practice of translating an organisation's business vision and strategy into effective enterprise change. It does this by creating, communicating, and improving key requirements, principles, and models that describe the enterprise's future state and enable its evolution. EA operates at the level of the whole enterprise — crossing departmental boundaries — rather than at the level of an individual project or solution.
The process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key requirements, principles, and models that describe the enterprise's future state and enable its evolution. — The Open Group, TOGAF Standard
EA vs Solution Architecture vs Technical Architecture
A common source of confusion — and a frequent Part 1 question — is the distinction between EA and other architecture disciplines. The table below summarises the key differences:
| Dimension | Enterprise Architecture | Solution Architecture | Technical Architecture |
|---|---|---|---|
| Scope | Entire organisation | A specific project or initiative | Technology layer of a solution |
| Time horizon | Long-term (3–10 years) | Medium-term (months to 2 years) | Short-term (implementation cycle) |
| Primary audience | Executives, board, senior stakeholders | Business owners, project managers | Developers, infrastructure teams |
| Focus | Strategy, transformation, alignment | Functional design of a solution | Infrastructure, platforms, APIs |
| TOGAF domains covered | Business, Data, Application, Technology | Primarily Application & Data | Primarily Technology |
| Governance artefacts | Architecture Roadmap, Principles, Vision | Solution Design Document | Infrastructure design, platform specs |
Why EA Matters
Organisations invest in EA for four primary reasons, all of which appear regularly in OGEA-103 scenarios:
- Alignment: Ensures IT investments directly support business strategy and reduce waste from misaligned projects.
- Risk reduction: Provides a structured way to understand the impact of changes, avoiding unintended consequences across the enterprise.
- Agility: Creates a reusable set of building blocks and standards that accelerate delivery of new capabilities.
- Cost optimisation: Identifies duplication, rationalises application portfolios, and enables shared services across the enterprise.
The Open Group and TOGAF
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. It developed TOGAF (The Open Group Architecture Framework) as a vendor-neutral, technology-agnostic enterprise architecture framework. TOGAF is the world's most widely used EA framework, adopted by more than 80% of Global 50 organisations.
The OGEA (Open Group Enterprise Architecture) series is the current generation of The Open Group's EA certification programme, replacing the older TOGAF 9 certification series.
Part 1 frequently asks you to distinguish EA scope from solution architecture scope. Remember: EA spans the entire enterprise over years, whereas solution architecture addresses a single initiative over months. The exam also tests the four EA value drivers — alignment, risk, agility, cost — in scenario stems.
Section 2: TOGAF Standard Overview
History: TOGAF 9.2 to TOGAF 10 / OGEA Series
TOGAF has evolved through several major releases:
| Version | Year | Key Change |
|---|---|---|
| TOGAF 8 | 2003 | First version explicitly named "TOGAF" |
| TOGAF 9 | 2009 | Introduced Content Framework, Architecture Repository, Capability Framework |
| TOGAF 9.2 | 2018 | Restructured into three books; minor additions to content framework |
| TOGAF Standard (10th Ed.) | 2022 | Modular structure; digital business focus; updated ADM guidance; new OGEA certifications |
The current certification series aligns with TOGAF Standard, 10th Edition (TOGAF 10). The exams are branded OGEA-101 (Part 1 Foundation), OGEA-102 (Part 2 Practitioner), and OGEA-103 (Combined, which is what this guide prepares you for).
OGEA-103 Exam Structure
| Attribute | Part 1 — Foundation (OGEA-101) | Part 2 — Practitioner (OGEA-102) |
|---|---|---|
| Question format | 40 multiple-choice questions | 8 complex scenario questions (gradient scoring) |
| Time allowed | 60 minutes | 90 minutes |
| Pass mark | 55% (22 of 40 correct) | 60% (minimum 60% across all scenarios) |
| Open book? | No — closed book | Yes — TOGAF Standard document permitted |
| What it tests | Recall, comprehension, definitions, phase sequences | Application, analysis, scenario judgment, best-fit selection |
| OGEA-103 sequencing | Taken first within the combined session | Taken second; Part 1 must be passed to continue |
In the OGEA-103 combined session you sit Part 1 (40 MCQ, 60 min, closed book) and then immediately Part 2 (8 scenarios, 90 min, open book). You must pass both parts. Memorise: 55% for Part 1, 60% for Part 2. Part 2 uses gradient scoring — even a partially correct answer earns partial marks, so always select an answer.
Section 3: The Architecture Development Method (ADM)
The ADM is the core of the TOGAF Standard. It provides a tested, repeatable process for developing and managing the lifecycle of an enterprise architecture. The ADM is iterative — it can be applied at the enterprise level, at the level of a single segment or capability, and it can be cycled multiple times as the enterprise evolves.
A step-by-step approach to developing an enterprise architecture. It defines the sequence of steps to take, the inputs required, and the outputs to produce at each phase. The ADM is iterative, cyclical, and adaptable to the needs of the organisation.
ADM Lifecycle Diagram
The ADM is represented as a cycle with Requirements Management at the centre, surrounded by phases that work around the cycle. Below is an inline SVG representation:
ADM Phase Summary Table
Every phase must be known for Part 1 (sequence, purpose) and Part 2 (inputs, outputs, key activities):
| Phase | Name | Core Purpose | Key Output(s) |
|---|---|---|---|
| P | Preliminary | Prepare the organisation; define principles; establish Architecture Capability | Tailored Architecture Framework; Architecture Principles; Governance Model |
| A | Architecture Vision | Gain sponsor approval; develop high-level vision; identify stakeholders | Statement of Architecture Work; Architecture Vision; Stakeholder Map |
| B | Business Architecture | Develop Baseline and Target Business Architecture | Business Architecture Document; Gap Analysis; Updated Architecture Definition Document |
| C | Information Systems Architecture | Develop Data Architecture and Application Architecture | Data Architecture; Application Architecture; Gap Analysis (C) |
| D | Technology Architecture | Develop Target Technology Architecture; identify technology components | Technology Architecture Document; Gap Analysis (D) |
| E | Opportunities & Solutions | Identify delivery vehicles (projects, programmes); generate Architecture Roadmap | Implementation and Migration Plan (draft); Architecture Roadmap; Work Packages |
| F | Migration Planning | Finalise the Architecture Roadmap and Implementation Plan with priorities | Migration Plan (finalised); Prioritised Work Packages; Transition Architectures |
| G | Implementation Governance | Oversee implementation projects; ensure architecture conformance | Architecture Contracts; Compliance Assessments; Change Requests |
| H | Architecture Change Management | Manage changes to the architecture; determine whether to re-cycle the ADM | Architecture Updates; Change Requests; ADM cycle trigger decision |
| RM | Requirements Management | Manage architecture requirements throughout all phases (continuous) | Requirements Impact Assessments; updated Requirements Repository |
Candidates often confuse Phases E and F. Remember: Phase E is about identifying opportunities and generating the roadmap concept; Phase F is about finalising and prioritising that roadmap into a detailed migration plan. Phase E = options; Phase F = committed plan.
Section 4: Architecture Domains (BDAT)
TOGAF organises enterprise architecture into four domains, commonly called BDAT. Each domain addresses a distinct layer of the enterprise, and they are interdependent — changes in one domain cascade through the others.
Business · Data · Application · Technology — the four domains that together constitute a complete enterprise architecture. Each has a corresponding ADM phase: B (Phase B), D & A (Phase C), T (Phase D).
| Domain | ADM Phase | Primary Question Answered | Example Artefacts |
|---|---|---|---|
| Business | Phase B | How does the business operate? | Business capability map, value streams, org charts, process models |
| Data | Phase C | What data does the enterprise use and how is it managed? | Conceptual data model, data flow diagrams, data governance policy |
| Application | Phase C | Which applications support the business and how do they interact? | Application portfolio, application interaction diagrams, interface catalogue |
| Technology | Phase D | What technology infrastructure supports the applications? | Technology standards catalogue, platform diagrams, network diagrams |
Note that Data and Application Architecture are both developed in Phase C (Information Systems Architecture). Phase C has two sub-phases: C1 (Data) and C2 (Application). The order (data before application) may be reversed if the organisation's approach warrants it. Part 2 scenarios may test whether you recognise this flexibility.
Section 5: ADM Iteration
One of the most important — and most underestimated — concepts in TOGAF is iteration. The ADM is explicitly designed to be applied iteratively, at multiple levels. TOGAF defines three forms of iteration that frequently appear in Part 2 scenario questions:
1. Architecture Landscape Iteration
The ADM can be run at different levels of the architecture landscape: Strategic (enterprise-wide, long-term), Segment (a major business area), or Capability (a specific capability or project). You iterate between these levels, using outputs from the higher level as inputs to the lower level.
2. Transition Architecture Iteration
When the gap between Baseline and Target architectures is too large to bridge in one step, you define intermediate states called Transition Architectures. Each represents a stable, deployable state of the enterprise. You iterate through each transition architecture in sequence, running relevant ADM phases for each step.
3. ADM Phases Iteration
Within a single ADM cycle you can revisit earlier phases — for example, returning to Phase A after completing Phase D if new stakeholder concerns emerge that alter the Architecture Vision. This backward iteration is explicitly supported by the ADM.
Part 2 scenario questions commonly present a situation where a large transformation is underway and ask which approach best handles it. The correct answer almost always involves defining transition architectures and iterating the ADM per transition state, rather than trying to move directly from baseline to target in one pass. Recognise phrases like "incremental delivery", "phased rollout", or "interim state" as signals to apply transition architecture iteration.
Section 6: Key ADM Concepts
The following six concepts form the conceptual vocabulary of the ADM. Each has a precise definition that is tested in Part 1:
Definition
A high-level, aspirational view of how the enterprise will look after the architecture project is complete. Created in Phase A; provides context and direction for all subsequent ADM phases. Approved by the sponsor in the Statement of Architecture Work.
Definition
The detailed description of the desired future state of the enterprise (or a domain thereof) after the transformation is complete. Developed across Phases B, C, and D. Contrasted with the Baseline Architecture to produce the Gap Analysis.
Definition
A description of the current state of the enterprise. Developed alongside (or prior to) the Target Architecture in Phases B, C, and D. Represents "where we are now" as opposed to "where we want to go."
Definition
An intermediate architecture that represents a stable, deliverable state of the enterprise between the Baseline and Target. Used when a direct transition is not feasible in a single step. Defined in Phases E and F. Each transition architecture must be viable and deployable in its own right.
Definition
A time-sequenced plan showing the work packages and transition architectures needed to move from Baseline to Target. First generated in Phase E and refined in Phase F. Lists Work Packages, their priority, dependencies, and estimated timescales.
Definition
A systematic comparison of the Baseline Architecture against the Target Architecture to identify what needs to change. Performed at the end of each domain phase (B, C, D). Gaps are categorised as: items present in baseline but not target (to be eliminated), items in target but not baseline (to be created), and items in both (to be modified or retained).
Section 7: Architecture Principles
Architecture Principles are general rules and guidelines that represent a consensus across the enterprise regarding how the architecture should be developed and governed. They endure beyond individual projects and are defined in the Preliminary Phase.
Good Principle Characteristics
TOGAF requires every principle to be documented in a four-part format. A principle without all four parts is incomplete and will not be correctly interpreted by stakeholders:
| Element | Description | Characteristics |
|---|---|---|
| Name | A memorable, short label for the principle | Should be specific enough to convey meaning, not generic (e.g. "Data is an Asset" not "Data Principle 1") |
| Statement | A sentence that clearly articulates the principle | Unambiguous; written in the present tense; leaves no room for misinterpretation |
| Rationale | The business reasons for the principle | Explains why the principle exists; highlights the value to the enterprise; references strategic drivers |
| Implications | The practical consequences of adhering to the principle | Addresses what must happen to comply; may list costs, constraints, or required changes to current behaviour |
Example Architecture Principles
Statement
Data is an asset that has value to the enterprise and is managed accordingly.
Rationale
Data is the foundation for decisions. Effective management of data helps the enterprise fulfil its mission, improve operational efficiency, and comply with regulatory requirements.
Implications
The enterprise must identify data owners for all critical data sets. Processes must be established to maintain data quality. Systems must treat data as a shared enterprise resource, not a local application asset.
Statement
Applications are independent of specific technology choices and operate across different technology environments.
Rationale
Independence from technology gives the enterprise the flexibility to adopt new technology as it evolves, prevents lock-in to specific vendors, and reduces the cost of technology refresh.
Implications
Applications must use open standards and APIs. Platform-specific features must be avoided unless explicitly approved. Testing environments must include multiple technology configurations.
Statement
Each data element has a single authoritative source within the enterprise, which all other systems must use.
Rationale
Eliminating duplicate data stores reduces inconsistency, improves data quality, and simplifies maintenance. A single authoritative source enables enterprise-wide reporting and reduces reconciliation effort.
Implications
A data stewardship programme must identify the authoritative system for each critical data element. Interfaces must be established to share data rather than copy it. System migration projects must incorporate data consolidation activities.
How Principles Guide the ADM
Principles defined in the Preliminary Phase become a key input to every subsequent ADM phase. When evaluating architecture options in Phases B, C, D, and E, the architect must check that proposed solutions comply with established principles. If a project wishes to deviate from a principle, it must request a dispensation from the Architecture Board, with documented justification.
Principles questions account for approximately 8–12% of Part 1 marks. The exam tests: (a) the four-part format — Name, Statement, Rationale, Implications — in that order; (b) what makes a good principle (understandable, robust, complete, consistent, stable); and (c) how principles are applied during governance (compliance vs. dispensation). Never confuse Rationale (the "why") with Implications (the "what must change").
Section 8: Exam-Critical Facts
Part 1 Question Types
Part 1 uses multiple-choice questions with four options (A–D). Question styles include:
- Definition recall: "Which of the following BEST defines X?" — tests precise TOGAF terminology
- Sequence identification: "Which phase of the ADM follows Phase C?" — tests phase order
- Output identification: "Which of the following is a key output of Phase A?" — tests phase deliverables
- Concept matching: "Which concept BEST describes [scenario]?" — tests conceptual understanding
- Negative questions: "Which of the following is NOT a characteristic of a good principle?" — tests depth
Most Frequently Tested Topics
Based on the OGEA-103 exam syllabus, the following topics carry the highest question density in Part 1:
| Topic | Approx. % of Part 1 | Key Things to Know |
|---|---|---|
| ADM Phase Sequence & Purposes | ~25% | Phase names, sequence (Prelim → A → B → C → D → E → F → G → H), core purpose of each |
| Key Outputs per Phase | ~20% | Distinguish inputs from outputs; know 2–3 primary outputs per phase |
| Architecture Principles | ~10% | Four-part format; characteristics of good principles; how they are used |
| Architecture Domains (BDAT) | ~10% | Which domain is addressed in which phase; what each domain covers |
| Enterprise Continuum & Repository | ~10% | Foundation / Common / Industry / Org-specific; the six repository classes |
| Content Framework | ~8% | Deliverables vs. Artefacts vs. Building Blocks (ABB vs. SBB) |
| Governance (Architecture Board, Contracts) | ~7% | Phase G activities; Architecture Contracts; compliance assessments |
| Requirements Management | ~5% | It is continuous; it does NOT directly manage other phases; it stores & feeds requirements |
| Stakeholder Management | ~5% | Stakeholder identification in Phase A; viewpoints vs. views; stakeholder map |
ADM Phase Sequence — Must Memorise
Key Outputs Per Phase — Cheat Sheet
- Tailored Architecture Framework
- Architecture Principles
- Governance model
- Architecture Repository (established)
- Statement of Architecture Work
- Architecture Vision
- Stakeholder Map
- Architecture Definition Document (draft)
- Baseline Business Architecture
- Target Business Architecture
- Gap Analysis (Business)
- Baseline & Target Data Architecture
- Baseline & Target Application Architecture
- Gap Analysis (Data, Application)
- Baseline & Target Technology Architecture
- Gap Analysis (Technology)
- Architecture Definition Document (updated)
- Draft Architecture Roadmap
- Work Package list
- Transition Architecture list
- Implementation & Migration Plan (draft)
- Finalised Architecture Roadmap
- Prioritised Work Packages
- Finalised Transition Architectures
- Implementation & Migration Plan
- Architecture Contracts
- Compliance Assessments
- Change Requests
- Architecture-compliant solutions
- Architecture Updates
- Change Requests (assessed)
- ADM cycle trigger decision
- Requirements Impact Assessments
- Updated Requirements Repository
- Prioritised requirements (per phase)
1. Confusing the Statement of Architecture Work (Phase A output, defines scope) with the Architecture Definition Document (the actual architecture across B, C, D). 2. Saying Requirements Management "manages" the other phases — it does not; it is a repository/process for requirements that feeds into all phases. 3. Placing Phase E before Phase D — the correct order is D then E. 4. Thinking architecture principles are created in Phase A — they are created in the Preliminary Phase.
Revision Summary — Chapter 01
- EA translates business strategy into change across the whole enterprise; it operates at a higher level and longer time horizon than solution or technical architecture.
- TOGAF Standard (10th Edition) is the basis for OGEA-103; Part 1 is closed-book (40 MCQ, 55% pass); Part 2 is open-book (8 scenarios, 60% pass).
- The ADM is iterative, cyclic, and adaptable; it runs from Preliminary Phase through Phases A to H, with Requirements Management continuous throughout.
- The four BDAT domains — Business (Phase B), Data & Application (Phase C), Technology (Phase D) — must all be covered for a complete enterprise architecture.
- Baseline Architecture = current state; Target Architecture = future state; Transition Architecture = stable intermediate state; Gap Analysis = structured comparison of baseline vs. target.
- Architecture Principles use the four-part format: Name, Statement, Rationale, Implications. Defined in the Preliminary Phase; used in governance throughout the ADM.
- The three forms of ADM iteration (landscape, transition, phases) are essential knowledge for Part 2 scenario questions involving large, complex transformations.
- Memorise: Phase E generates the draft roadmap; Phase F finalises and prioritises it. Phase G governs implementation; Phase H manages ongoing change.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. Develop the Architecture Vision and obtain sponsor approval
B. Prepare the organisation, define architecture principles, and establish the Architecture Capability
C. Perform a gap analysis between Baseline and Target architectures
D. Generate the Architecture Roadmap and identify work packages
Explanation: Option B is correct. The Preliminary Phase is about preparation — setting up the architecture practice, tailoring the TOGAF framework, and defining the principles that will govern all subsequent ADM activity. Option A describes Phase A (Architecture Vision). Option C describes the Gap Analysis activity performed in Phases B, C, and D. Option D describes Phases E and F.
A. Requirements Management is performed only during Phases A and B
B. Requirements Management directly controls the sequence of all other ADM phases
C. Requirements Management operates continuously throughout all ADM phases, managing requirements that flow into and out of each phase
D. Requirements Management is performed as the first step of the Preliminary Phase
Explanation: Option C is correct. Requirements Management is a continuous process at the centre of the ADM lifecycle. It does not occur at a fixed point — it operates throughout all phases. It does not "control" other phases (Option B); rather, it acts as a repository and conduit for requirements, ensuring they are captured, stored, and fed into the appropriate phases. Options A and D incorrectly limit it to specific phases.
A. Rationale
B. Name
C. Statement
D. Implications
Explanation: Option D is correct. The text "All business data must be classified according to the enterprise data classification scheme" is an Implication — it describes what must happen for the principle to be upheld; it is a practical consequence of adhering to the principle. It is not the Statement (which would be a broader, aspirational declaration such as "Data is an Asset"). It is not the Rationale (which explains the business reasons). The Name would be a short label.
A. Architecture Vision
B. Transition Architecture
C. Architecture Roadmap
D. Gap Analysis
Explanation: Option B is correct. A Transition Architecture represents a stable, intermediate state between the Baseline and Target when the gap is too large to bridge in one step. Each Transition Architecture is viable and deployable in its own right. An Architecture Roadmap (Option C) shows the sequence of work packages and transition architectures, but it is the Transition Architecture concept that directly addresses the need for intermediate states. The Architecture Vision (A) is about aspirational direction, not intermediate states. A Gap Analysis (D) identifies the differences, not the intermediate states.
A. First generated in Phase D; finalised in Phase E
B. First generated in Phase A; finalised in Phase F
C. First generated in Phase E; finalised in Phase F
D. First generated in Phase F; finalised in Phase G
Explanation: Option C is correct. The Architecture Roadmap is first generated (in draft form) in Phase E — Opportunities and Solutions, when the architect identifies work packages and sequences them into a preliminary roadmap. It is then detailed and finalised in Phase F — Migration Planning, where work packages are prioritised, resource-costed, and scheduled. This distinction between E (generating) and F (finalising) is a high-frequency Part 1 question type.