8.3 The Enterprise Metamodel: Core Concepts, Entities & Attributes

The Enterprise Metamodel: Core Concepts, Entities & Attributes

To ensure enterprise architecture models are precise, structured, and interoperable across different modeling tools and organizations, the TOGAF Standard defines a formal metamodel. In the 10th Edition this is the TOGAF Enterprise Metamodel, defined in the Architecture Content document under the heading "TOGAF Content Framework and Enterprise Metamodel". It provides a standardized schema of entities, attributes, and cross-domain relationships that determines how architectural information is structured in the Architecture Repository.

Terminology and exam warning. TOGAF 9.2 called this the Content Metamodel and split it into a core metamodel plus optional extension modules (Governance, Services, Process Modeling, Data, Infrastructure Consolidation, Motivation). The 10th Edition renamed it the Enterprise Metamodel and removed the core/extension distinction entirely — there is now one metamodel, expressed as entities, attributes, and relationships. Entities were also renamed and added: Information System Service became Application Service, and Business Information was introduced. Older courseware, blog posts, and question banks still teach the 9.2 core-and-extension structure; on a 10th Edition exam, answers that depend on "extension modules" are stale.

Without a metamodel, architects use terms like "Application", "System", "Service", or "Component" ambiguously. The Enterprise Metamodel provides unambiguous definitions for each architectural entity and formalizes how entities in one domain (e.g., Business Architecture) connect to entities in another (e.g., Application or Technology Architecture).

---

Structure of the Enterprise Metamodel

The Enterprise Metamodel is expressed through three things and nothing else:

                        +--------------------------------+
                        |    TOGAF ENTERPRISE METAMODEL  |
                        +----------------+---------------+
                                         |
        +--------------------------------+--------------------------------+
        |                                |                                |
+-------+--------+              +--------+--------+             +---------+---------+
|    ENTITIES    |              |   ATTRIBUTES    |             |   RELATIONSHIPS   |
| The types of   |              | The properties  |             | How entities are  |
| thing modelled |              | each entity     |             | connected across  |
| (Actor, Role,  |              | carries (ID,    |             | and within the    |
| Data Entity,   |              | Name, Category, |             | BDAT domains      |
| Application    |              | Standards class,|             | ("is realized     |
| Component ...) |              | Owner ...)      |             | by", "supports")  |
+----------------+              +-----------------+             +-------------------+

1. Entities — the types of thing that may appear in a model, organized by architecture domain. The tailored subset an organization actually uses is chosen in the Preliminary Phase (see Section 2.3).
2. Attributes — the properties each entity carries. Every entity has the basic set (ID, Name, Description, Category, Source, Owner); some carry extras, such as the Standards class attribute on Technology Component and Technology Service (Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard).
3. Relationships — the permitted connections between entities, which is what makes end-to-end traceability and impact analysis possible.

Tailoring still happens: an organization adds, modifies, or suppresses entities, attributes, and relationships to suit its priorities. What changed in the 10th Edition is that this tailoring is no longer packaged as a fixed catalogue of named "extension modules".

---

Metamodel Entities by Domain

The Enterprise Metamodel establishes explicit entity types for each architecture domain:

1. Business Architecture Domain Entities

• Organization Unit: An internal or external department, division, or legal entity (e.g., Global Supply Chain Division).
• Actor: An individual, group, or external entity that interacts with the enterprise (e.g., John Doe, Tier-1 Customer).
• Role: A defined set of responsibilities, functions, and permissions assigned to an actor (e.g., Inventory Manager, Security Administrator). Note: Actors fill Roles; an Actor is an entity, while a Role is a specification.
• Business Function: A major continuous capability or operational area of the business (e.g., Financial Management, Payroll Processing).
• Business Service: A discrete business capability delivered to internal or external customers (e.g., Account Origination Service).
• Business Process: A sequenced flow of activities producing a specific business outcome (e.g., Order-to-Cash Process).
• Business Capability: An ability that an organization possesses to achieve a business outcome (e.g., Real-Time Fraud Detection).

2. Data Architecture Domain Entities

• Data Entity: An encapsulation of logical business data structure (e.g., Customer Master Record, Purchase Order).
• Logical Data Component: A logical grouping of related data entities (e.g., Customer Profile Data Store).
• Physical Data Component: A concrete database table, schema, object store, or file deployment (e.g., Oracle tbl_customer_master).

3. Application Architecture Domain Entities

• Application Service: An automated service delivered by an application to support business processes or services (e.g., Credit Check API Service).
• Logical Application Component (LAC): An abstract, vendor-agnostic application component defining functionality (e.g., Customer Portal LAC, Payment Gateway LAC).
• Physical Application Component (PAC): A concrete software application, executable binary, container, or COTS product instance (e.g., React SPA v18.2, Stripe Payments SDK).

4. Technology Architecture Domain Entities

• Technology Service: An infrastructure service provided by technology components to applications (e.g., Encrypted Object Storage Service, Database Hosting Service).
• Logical Technology Component (LTC): An abstract specification of technology infrastructure (e.g., Relational Database Engine LTC, Container Orchestrator LTC).
• Physical Technology Component (PTC): A physical or virtual hardware device, operating system, or software platform instance (e.g., AWS Aurora PostgreSQL v15, Kubernetes v1.28 Cluster).

---

Logical vs Physical Entity Distinctions

A critical concept in the Enterprise Metamodel is the explicit distinction between Logical and Physical entities:

+---------------------------------------+---------------------------------------+
|            LOGICAL ENTITY             |            PHYSICAL ENTITY            |
|   (Conceptual boundary, vendor-free)  |  (Implementation asset, product version) |
+---------------------------------------+---------------------------------------+
| Logical Application Component (LAC):  | Physical Application Component (PAC): |
|  'Order Processing System'            |  'SAP S/4HANA Order Module v2022'     |
+---------------------------------------+---------------------------------------+
| Logical Technology Component (LTC):   | Physical Technology Component (PTC):  |
|  'Container Orchestrator Engine'      |  'Amazon EKS v1.27 Production Cluster'|
+---------------------------------------+---------------------------------------+

• Logical Entities define functional boundaries and capabilities independent of vendor products or implementation tech. They allow architects to model target architectures without becoming constrained by current software versions.
• Physical Entities capture the concrete software binaries, commercial products, hardware servers, and deployment configurations operating in the enterprise.

---

Entity Attributes & Cross-Domain Traceability

Every entity in the Enterprise Metamodel possesses standard attributes (such as ID, Name, Description, Owner, Category, and Lifecycle Status).

Furthermore, the metamodel enforces strict cross-domain relationship mapping, enabling complete end-to-end traceability from high-level business strategy down to physical infrastructure:

[ Strategic Driver ] ---> [ Business Goal ] ---> [ Business Capability ] 
                                                        |
                                                        v
[ Physical Tech Component ] <--- [ Logical App Component ] <--- [ Business Process ]

• Driver drives Goal
• Goal requires Business Capability
• Business Capability is realized by Business Process
• Business Process is supported by Application Service
• Application Service is provided by Logical Application Component
• Logical Application Component is realized by Physical Application Component
• Physical Application Component executes on Physical Technology Component

This cross-domain traceability enables architects to perform instant impact analysis: if a Physical Technology Component (e.g., a legacy database server) is retired, architects can trace directly upward to identify which Logical Applications, Business Processes, and Business Goals will be impacted.