Study guide
13.1 The TOGAF Content Framework and Enterprise Metamodel
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
13.1 The TOGAF Content Framework and Enterprise Metamodel
Key Takeaways Explain This Topic AI
The Content Framework structures the Architecture Description, while the Enterprise Metamodel defines the entity types appearing in models and the relationships between them.
The TOGAF Enterprise Metamodel is the basis for an organization-specific metamodel developed in the Preliminary Phase; architects may omit irrelevant entities and add new ones.
TOGAF 10 metamodel entities include Actor, Role, Organization Unit, Business Capability, Value Stream, Business Service, Function, Process, Data Entity, Application Service, Technology Service, and logical and physical data, application, and technology components.
An Actor is a person, organization, or system that has a role that initiates or interacts with activities; a Role is the part it plays, and one actor may have several roles.
Logical components are implementation-independent and physical components realize them with particular products, mirroring Architecture versus Solution Building Blocks.
Last updated: October 2026
13.1 The TOGAF Content Framework and Enterprise Metamodel
Architecture Content is one of the six Level 1 areas tested in Part 1 (5 of the 40 questions), and the Level 2 outcomes expect you to understand the Architecture Content Framework. The 10th Edition presents this material as the TOGAF Content Framework and Enterprise Metamodel . Many older study notes still teach the TOGAF 9 "Content Metamodel" with a mandatory core and six optional extension modules. That structure no longer appears in the 10th Edition text, so learn the current model below.
Two Ideas: Content Framework and Enterprise Metamodel
The TOGAF Standard, 10th Edition separates two related concepts:
The Content Framework defines a categorization framework used to structure the Architecture Description : the work product that expresses an architecture and the collection of models that describe it. It explains how deliverables, artifacts, and building blocks relate to the ADM phases (Section 13.2).
The Enterprise Metamodel defines the types of entities that appear in the models describing the enterprise, and the relationships between those entities.
TOGAF gives three reasons an Enterprise Metamodel is valuable. It provides consistency across architecture descriptions. It gives a completeness check for any modeling language or tool metamodel proposed for use in the enterprise: how completely does it handle the entity types, attributes, and relationships the enterprise needs? And it supports the traceability that impact analysis depends on.
An Example
TOGAF's own illustration: one entity type in an Enterprise Metamodel might be Role . The enterprise's Business Architecture models then contain instances of Role such as Teller, Pilot, Manager, Volunteer, Customer, or Firefighter. The metamodel defines the type; the models hold the instances.
Developing the Organization-Specific Metamodel
The TOGAF Library includes a foundation-level TOGAF Enterprise Metamodel capturing the entities and relationships likely to be found in most enterprises. It is meant as the basis for an organization-specific metamodel , developed when the EA Capability is established in the Preliminary Phase :
Architects may leave out entities and relationships that are not relevant.
Architects may add entities and relationships that the enterprise needs.
TOGAF stresses that the entity types and relationships are specific to each enterprise, and that developing a high-quality metamodel is an important part of establishing the EA Capability .
The tailored metamodel is held in the Architecture Metamodel area of the Architecture Repository and is part of the Tailored Architecture Framework. Using the Enterprise Continuum, resources range from the most general (Foundation) to the most specific (Organization-Specific); the TOGAF Enterprise Metamodel is a foundation-level asset that each enterprise specializes.
The Entities of the TOGAF Enterprise Metamodel
TOGAF 10 lists the following metamodel entities. Grouping them by area makes them easier to remember:
Area Entities
Motivation and strategy Driver, Goal, Objective, Measure, Course of Action, Principle, Requirement, Constraint, Assumption
Business Actor, Role, Organization Unit, Business Capability, Capability, Value Stream, Business Service, Function, Process, Event, Control, Product, Business Information, Contract, Service Quality, Location
- Data Data Entity, Logical Data Component, Physical Data Component
- Application Application Service, Logical Application Component, Physical Application Component
- Technology Technology Service, Logical Technology Component, Physical Technology Component
- Implementation and migration Gap, Work Package
- Definitions Worth Memorizing
Actor : a person, organization, or system that has a role that initiates or interacts with activities.
Role : the usual or expected behavior of an actor, or the part somebody or something plays in a particular process or event; an actor may have a number of roles.
Business Capability : a particular ability that a business may possess or exchange to achieve a particular purpose. Capability is the general-purpose term: an ability that an organization, person, or system possesses.
Function : a set of business behaviors based on a chosen set of criteria, usually close-coupled to organizational units.
Process : a sequence of activities that together achieve a specified outcome; it can be decomposed into sub-processes and can show the operation of a capability or service at the next level of detail.
Business Service : supports the business by encapsulating a unique element of business behavior.
Application Service : the automated elements of a business service.
Logical Application Component : an encapsulation of application functionality, definable by the services it offers and the data it maintains, independent of implementation and technology. A Physical Application Component realizes it with functionality that may be hired, procured, or built.
Logical Data Component : a data structure composed of logically related data entities. A Physical Data Component realizes it in the format or schema a particular technology requires.
Logical Technology Component : an implementation-independent encapsulation of technology services. A Physical Technology Component realizes it using a particular technology product.
Technology Service : a technical capability required to provide enabling infrastructure that supports the delivery of applications.
Objective : an organizational aim declared in a SMART way.
Requirement : a quantitative statement of business need that must be met by a particular architecture or work package.
Constraint : an external factor that prevents an organization from pursuing particular approaches to meet its goals.
Gap : a statement of difference between two states, used in gap analysis.
Work Package : a set of actions identified to achieve one or more objectives for the business; it can be part of a project, a complete project, or a program.
Distinctions the Exam Likes
Pair Distinction Example
Actor vs. Role The actor is who or what acts; the role is the part it plays Jane Smith (actor) acts as Chief Underwriter and as Compliance Reviewer (roles)
Function vs. Process A function groups business behavior by chosen criteria, usually aligned to organization units; a process is a sequence of activities achieving an outcome Accounts Payable (function) versus Validate Invoice and Pay Supplier (process)
Business vs. Application Service Business services encapsulate business behavior; application services are their automated elements Currency Exchange (business service) versus FX Rate Lookup (application service)
Logical vs. Physical component Logical is implementation-independent; physical is a realization using particular products or schemas "Customer Relationship Management" (logical application component) versus a specific CRM product deployment (physical)
Requirement vs. Constraint A requirement states a business need to be met; a constraint is an external factor limiting the approaches available "Process 10,000 claims per hour" versus "Customer data cannot leave the EU"
The logical/physical split mirrors Architecture Building Blocks and Solution Building Blocks . Logical components describe what is needed independent of product; physical components describe the chosen realization.
How the Metamodel Supports the ADM
The metamodel gives the ADM a consistent vocabulary. Phase A artifacts relate drivers, goals, and objectives to stakeholders and capabilities. Phases B to D populate business, data, application, and technology entities and the relationships between them. Phases E and F use gaps and work packages to plan transitions. Because the entities are related, an architect can trace a change in a business objective through capabilities and services to the application and technology components affected. This traceability is what makes catalogs, matrices, and diagrams consistent with one another.
Common Exam Traps
Studying TOGAF 9 extension modules. The 10th Edition text describes one TOGAF Enterprise Metamodel to be tailored, not a core plus six optional modules.
Adopting the metamodel unchanged. TOGAF expects an organization-specific metamodel: drop what is irrelevant, add what the enterprise needs.
Confusing Actor and Role , or Function and Process .
Treating logical components as products. Product names belong to physical components and Solution Building Blocks.