Study guide
1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
Key Takeaways Explain This Topic AI
The TOGAF Practitioner material states that the purpose of Enterprise Architecture is to guide effective change.
The Practitioners' Approach Series Guide describes developing architecture to support Strategy, Portfolio, Project, and Solution Delivery, each needing a different breadth and depth.
An Enterprise Architecture is a landscape of related architecture descriptions organized by levels, partitions, and states (candidate, current, transition, and target).
Enterprise Security Architecture is a cross-cutting concern that is addressed in every ADM phase rather than deferred to Phase D.
The DPBoK Standard's four contexts are Individual/Founder, Team, Team of Teams, and Enduring Enterprise.
Last updated: October 2026
1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
"The Context for Enterprise Architecture" is the first Level 2 topic area for Part 2 of OGEA-103, and it frames how almost every scenario should be read. The Level 2 learning outcomes expect you to explain why Enterprise Architecture (EA) exists, what an EA actually looks like, what an Architecture Capability is, why several architecture states must be managed at once, why security is a cross-cutting concern, and how the Enterprise Architect's role changes in a digital enterprise. The main sources are the TOGAF Fundamental Content and two Series Guides in the Practitioner Body of Knowledge: A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM and Using the TOGAF Standard in the Digital Enterprise .
Why Enterprise Architecture Exists: Guiding Effective Change
The Practitioner material puts it plainly: the purpose of Enterprise Architecture is to guide effective change . The Introduction and Core Concepts document adds that EA optimizes a fragmented legacy of manual and automated processes into an integrated environment that responds to change and supports the business strategy.
That framing matters in Part 2. An answer that produces impressive models but does not help a decision-maker choose, sequence, or govern change is weaker than one that delivers just enough architecture to support the decision at hand.
Four Purposes an Architecture Can Serve
The Practitioners' Approach guide describes developing architecture to support Strategy, Portfolio, Project, and Solution Delivery . Each purpose changes the breadth, depth, and timing of the work:
Purpose Typical question it answers Character of the architecture
Support to Strategy Where should the enterprise go, and what must change? Broad and shallow; long-range; identifies change initiatives
Support to Portfolio Which programs and projects deliver the strategy, in what order? Cross-functional; frames multiple projects and their dependencies
Support to Project What must this project deliver and within which constraints? Narrower scope; enough detail to guide a single project
Support to Solution Delivery How should this solution be built to fit the architecture? Most detailed; guides and governs implementation choices
When a scenario tells you why the architecture is being developed, choose the answer whose depth matches that purpose. Detailed solution design in a strategy engagement is as wrong as a vague vision for a solution delivery team.
What an Enterprise Architecture Looks Like
An Enterprise Architecture is not one document. It is a landscape of related architecture descriptions , held in the Architecture Repository and organized by:
Levels : Strategic, Segment, and Capability Architectures, each giving direction to the more detailed ones beneath it.
Partitions : separately owned slices of the landscape, such as a business unit or a shared platform.
States : the same scope described at different points in time.
Managing Multiple Architecture States
Practitioners must manage several states at once: candidate architectures still under discussion, the current (baseline) state, one or more transition states, and the target state. A Part 2 scenario might show a project designing against an out-of-date baseline, or two teams working from different targets. The better answers bring the states back under governance, by updating the Architecture Landscape and resolving which target is authoritative, before more design work proceeds.
The ADM Is Iterative
The ADM graphic reads like a waterfall, but the Practitioners' Approach guide uses a Gantt-chart example to show that ADM phases overlap, that many steps run at the same time, and that phases are revisited as information emerges. Expect scenario answers that "finish Phase B completely before starting anything else" to rank below answers that iterate sensibly.
The Architecture Capability and the Enterprise Architect
The Architecture Capability is the enterprise's ability to perform EA work: the organization, people, processes, governance, tools, and repository that the Preliminary Phase establishes. The TOGAF Standard's structure deliberately mirrors this capability, and the TOGAF Leader's Guide gives a path for establishing and evolving it.
The Introduction and Core Concepts document lists the kinds of EA services a capability can provide:
- Enterprise support services
- Design support services
- Development support services
- Requirements elicitation and understanding services
- Architecture planning services
- EA practice development support services
Architecture Governance keeps this capability effective: it ensures that architectures are developed, approved, and used to steer change. The Enterprise Architect leads and facilitates that work. The architect's job is to make sure decisions are informed by the architecture and governed against it, not to make every decision personally.
Security as a Cross-Cutting Concern
The Series Guide Integrating Risk and Security within a TOGAF Enterprise Architecture treats Enterprise Security Architecture as a concern that runs through every phase rather than a separate domain bolted on in Phase D. In practice:
Security and risk appetite are considered when the Architecture Capability and principles are set in the Preliminary Phase.
Phase A determines whether a security-specific architecture design is needed and how much is sufficient.
Phases B to D address security in business processes, information classification, applications, and technology.
Phases E to G carry security risks into migration planning and implementation governance.
A related Level 2 outcome is creating an environment in which the uncertainty of a change's success can be managed , to maximize business benefit and minimize business loss. That is the role of risk management, transition architectures that deliver value in steps, and governance checkpoints.
Enterprise Architecture in the Digital Enterprise
Using the TOGAF Standard in the Digital Enterprise draws on The Open Group's Digital Practitioner Body of Knowledge (DPBoK) Standard, which describes four contexts through which an organization evolves:
Individual/Founder : one person or a very small group delivering digital value.
Team : a single product team with shared practices.
Team of Teams : several teams whose work must be coordinated, partitioned, and kept coherent.
Enduring Enterprise : a large, long-lived organization that must steer, manage risk, and assure performance at scale.
The Enterprise Architect's role grows with each context. Formal EA adds little for a founder or a single team. It becomes essential once coordination across teams is needed, and in the Enduring Enterprise it underpins governance, portfolio decisions, and long-term coherence.
Architecture and Agile Delivery
The same guidance shows how architecture keeps agile work aligned with organizational objectives. The architecture supplies the context: the target, principles, constraints, and dependencies. Agile teams then make detailed decisions within that context and feed back what they learn. The strongest Part 2 answers rarely tell agile teams to stop and wait for a full architecture. They also rarely abandon architecture to let each team decide independently.
Applying the Context in Part 2
Identify the purpose (strategy, portfolio, project, or solution delivery) and the level of the architecture before judging any answer.
Prefer answers that keep candidate, baseline, transition, and target states governed and consistent .
Treat security and risk as part of every phase, not as a final technical review.
Match the amount of architecture to the enterprise's context, as the DPBoK contexts illustrate.