TOGAF Enterprise Metamodel in Detail Knowledge-Based Study
Foundation topic explanations on TOGAF Enterprise Metamodel in Detail.
Study notes
Purpose and Role in Architecture Development
The TOGAF Enterprise Metamodel provides a structured definition of architectural concepts, their properties, and their relationships. Within the TOGAF Standard, 10th Edition, the metamodel serves as the foundational ontology for the TOGAF Content Framework, enabling organizations to consistently capture, structure, and govern architecture artifacts.
Key roles of the Enterprise Metamodel include:
- Consistency: Establishing unambiguous definitions for architectural building blocks across multiple architecture initiatives.
- Traceability: Ensuring formal connections between business drivers, capabilities, processes, applications, data, and technology infrastructure.
- Interoperability: Facilitating the exchange of architecture models between diverse tools, repositories, and modeling environments.
The metamodel defines Entities (the architectural concepts), Attributes (the characteristics describing entities), and Relationships (the semantic links connecting entities).
Architectural Domains within the Metamodel
The TOGAF Enterprise Metamodel structures enterprise architecture information into core architectural domains, each containing specific core entities:
1. Business Architecture Domain
- Capability: An ability that an organization, person, or system possesses to achieve a specific outcome.
- Organization Unit: A formal group of people with designated responsibilities.
- Actor and Role: An Actor is an internal or external person, organization, or system, whereas a Role defines the expected behavior and duties performed by an actor.
- Business Service: An explicitly defined, externally visible value delivered by an organization.
- Function: An ongoing activity that an organization executes as part of its operation.
- Process: A sequence of activities that transforms inputs into outputs to deliver a product or service.
2. Data Architecture Domain
- Data Entity: A conceptual or logical representation of business data (e.g., Customer, Order).
- Logical Data Component: A boundary grouping related data entities.
- Physical Data Component: A concrete implementation of data storage, such as a relational database table or schema.
3. Application Architecture Domain
- Application Component: An encapsulation of application functionality (logical or physical).
- Application Service: A distinct piece of functionality provided by an application component to external consumers.
4. Technology Architecture Domain
- Technology Service: An infrastructure capability delivered to support application services (e.g., storage or authentication services).
- Technology Component: An element of software or hardware infrastructure (e.g., operating system, server hardware, virtualization platform).
Navigating Metamodel Relationships
A primary strength of the TOGAF Enterprise Metamodel is the formal mapping between domains. This traceability enables end-to-end impact analysis:
- Strategy to Execution: Capabilities are realized through Business Functions, Processes, and Roles.
- Business to Information Systems: Business Processes consume and produce Data Entities, and are automated or supported by Application Services.
- Application to Technology: Application Components consume Technology Services, which are realized through physical Technology Components and Nodes.
Core vs. Metamodel Extensions
The TOGAF Standard defines a flexible core-plus-extension approach:
- Core Metamodel: Contains the minimum set of entities and relationships required to support standard architecture definitions across all ADM phases.
- Metamodel Extensions: Optional modules that introduce specialized entities without altering the underlying core. Examples include extensions for data modeling, services, governance, motivation, and infrastructure consolidation.
Avoiding Common Classification Errors
When modeling architectures using the TOGAF Enterprise Metamodel, architects must maintain clear conceptual distinctions:
- Capability vs. Function: A Capability represents what an enterprise can do to deliver business value, remaining stable across structural reorganizations. A Function describes how operational activities are currently managed and grouped.
- Actor vs. Role: An Actor refers to the concrete entity (such as a specific employee, customer, or automated system), whereas a Role defines the abstract responsibilities assigned to one or more actors.
- Application Component vs. Application Service: An Application Component is the structural implementation (the "provider"), while an Application Service represents the externally exposed contractual behavior (the "what").
- Logical vs. Physical Components: Logical components provide an implementation-independent view of modular boundaries; physical components specify the actual vendor-specific software, hardware, or deployed assets.

