TL;DR
The Enterprise Metamodel defines the types of things architects investigate and the relationships between them. It gives consistent language and structure for architecture artifacts, and should be tailored to the enterprise during the Preliminary Phase.
What it is
The Enterprise Metamodel is like a starter pack for architects.
It defines the types of entities that architecture work may need to investigate and model.
It also defines the relationships between those entities.
Examples of entities include:
- business capability
- value stream
- actor
- process
- data entity
- application service
- technology component
Examples of relationships include:
- a business capability enables a value stream
- a process operationalizes a value stream
- an application service supports a business process
- a technology component realizes an application component
Relationship to the content framework
The Architecture Content Framework describes which work products, artifacts, and models should be developed to describe an architecture.
To make those work products consistent, they should use uniform wording and uniform entity types.
The Enterprise Metamodel provides that structure.
It gives context for the artifacts suggested by the ADM and defines the entities used inside those artifacts.
Why it matters
The Enterprise Metamodel improves:
- consistency
- completeness
- traceability
- architecture information quality
- reuse across models and artifacts
- stakeholder communication
It can also be used as a completeness check for architecture modeling languages and metamodels.
In simple terms, it structures architecture information in an orderly way so that it can be processed to meet stakeholder needs.
Enterprise-specific nature
The Enterprise Metamodel is enterprise-specific.
The entity types and relationships should fit the individual enterprise.
Another organization is unlikely to be able to reuse the same metamodel without adaptation.
This is because different enterprises have different:
- business models
- architecture concerns
- stakeholder questions
- governance needs
- terminology
- architecture capabilities
Preliminary Phase
Developing a high-quality metamodel is an important part of establishing the enterprise architecture capability.
The enterprise architecture capability is created and tailored in the Preliminary Phase.
Therefore, the Enterprise Metamodel should be customized for the enterprise during the Preliminary Phase.
The TOGAF library provides a foundation-level core Enterprise Metamodel that can be used as a starting point.
Notation flexibility
The Enterprise Metamodel does not force one modeling notation.
TOGAF can be used with many modeling languages and notation styles, including:
- ArchiMate
- Business Process Model and Notation
- Unified Modeling Language
- entity relationship diagrams
- flowcharts
- other notations that can express the needed ideas
The metamodel defines the concepts and relationships. The notation is how those concepts are represented.
Development approaches
There are two common approaches for developing an Enterprise Metamodel.
Viewpoint-driven approach
One approach is to develop the metamodel from viewpoints that address stakeholder concerns.
Start with the questions the architecture capability is expected to answer.
Then identify:
- stakeholder concerns
- viewpoints that address those concerns
- information needed by those viewpoints
- entities and relationships needed to support that information
The resulting viewpoint library defines the metamodel.
This approach keeps the information demand smaller and focuses the architecture capability on expected value.
Anything beyond what the viewpoints need can become noise and create unnecessary future maintenance.
Starting from an existing metamodel
Another approach is to start from an available or established metamodel.
For example, the foundation-level core Enterprise Metamodel from the TOGAF library can be used as a starting point.
The enterprise then adapts it to fit its own architecture concerns, terminology, and capability.
Keep it minimal
Every entity added to the Enterprise Metamodel creates maintenance work.
Each entity usually has:
- relationships to maintain
- attributes to track
- consistency rules to govern
- impacts across models and views
The number of interim architecture states and options can multiply the amount of information that must be maintained.
To succeed, define the absolute minimum information needed to deliver the stated purpose of the architecture capability.
Exam note
- The Enterprise Metamodel defines architecture entity types and relationships.
- It provides context for artifacts suggested by ADM.
- It improves consistency, completeness, and traceability.
- It helps structure architecture information so it can meet stakeholder needs.
- It is enterprise-specific and should be tailored to the organization.
- It is customized during the Preliminary Phase as part of establishing the architecture capability.
- TOGAF does not constrain the enterprise to one modeling notation.
- Two development approaches are viewpoint-driven design and starting from an existing metamodel.
- Every entity adds relationships and attributes that must be maintained.
- Keep the metamodel to the minimum information needed to deliver the architecture capability’s purpose.