Skip to content
Software Architecture Guide

Enterprise Architecture Meta Model

Explanation

Section titled “Explanation”

A meta model says what kinds of things you can describe and how they connect. It does not describe your organization itself. It defines the building blocks, such as “data entity” or “logical data component”, and the allowed links between them.

The TOGAF core

The TOGAF content metamodel has a core. The core holds the minimum entities and relationships needed for traceability across all architecture domains. It is meant to stay stable. For traceability, see the article on Traceability.

Extensions

Extensions add deeper modeling on top of the core. They cover:

  • governance
  • services
  • process modeling
  • data
  • infrastructure consolidation
  • motivation

Logical and physical

In the information systems layer, the metamodel separates logical from physical. This lets a team define the target architecture without choosing technology first.

For data, this gives a chain:

  1. A data entity is the thing the business describes.
  2. A logical data component is a logical definition of the data held in a data store.
  3. A physical data component realizes a logical one in a vendor- or technology-specific form.

Data entities are mapped to the data components that hold them. See the articles on Conceptual, Logical and Physical Data Model and on Data Entity/Data Component Catalog.

Using the meta model in practice

  • Tool configuration: In an EA tool such as Ardoq, each metamodel entity becomes a component type. Each relationship becomes a typed reference.
  • Repositories: A TOGAF content metamodel ontology (version 2), built on TOGAF 9.2, shows the metamodel used in a repository. It uses “Business Service”. It adds decomposition of Business Capability. It keeps process sequencing as a single property.

Example

Section titled “Example”

A bank sets up an EA tool. It creates one component type for “Data Entity”, one for “Logical Data Component” and one for “Physical Data Component”. It also creates typed references between them. The team records “Customer” as a data entity. It maps Customer to a logical component for customer data. That component links to the physical component of one specific database product. Later, the team can replace the database. The logical definition stays the same.

Trade-offs

Section titled “Trade-offs”

The stable core keeps traceability simple, but it holds only the minimum. Teams that need more depth must add extensions. That makes the model larger. Separating logical from physical frees the target design from technology choices. It also means you maintain two levels of description.

Data realization chain: from data entity to logical to physical data component.

Diagram source 
flowchart LR
  A[Data entity] -->|held by| B[Logical data component]
  B -->|realized by| C[Physical data component]

Checks

Section titled “Checks”
  • Logical and physical data components are kept separate, so the target architecture does not depend on a specific technology.
  • Each data entity is mapped to the data components that hold it.
  • The EA tool configuration maps each metamodel entity to a component type and each relationship to a typed reference.
Section titled “Related”

Sources

Section titled “Sources”