The TOGAF Content Metamodel: Mapping Architecture Entities
Introduction to the TOGAF Content Metamodel.
What is the Content Metamodel?
The TOGAF Content Metamodel is the formal blueprint that defines how an architecture is structured. If you think of an architecture as a map of an organization, the Content Metamodel defines what the "symbols" on that map are — such as Business Services, Data Objects, Application Components, and Technology Services — and, more importantly, how they relate to each other.
Without a standardized metamodel, different architects in the same organization might name things differently or fail to see how a change in a business process might break an underlying database. The Content Metamodel provides the common language that ensures consistency across the entire Enterprise Architecture (EA).
Core vs. Extensions: A Modular Approach
The Content Metamodel is designed to be flexible. It consists of a Core Metamodel and a set of Extensions.
The Core Metamodel
The core contains the essential entities that every architecture must have. This includes the fundamental elements of the four architectural domains: Business, Data, Application, and Technology.
Metamodel Extensions
Extensions are optional sets of attributes and relationships that organizations can add based on their specific needs. Common extensions include:
- Governance Extension: Adds attributes for tracking ownership and compliance.
- Motivation Extension: Captures the why behind the architecture, such as goals, drivers, and objectives.
- Infrastructure Consolidation Extension: Focused on hardware and physical assets.
- Data Extension: For deeper data modeling beyond simple entities.
Key Entities and Relationships
To understand the metamodel, you must understand the key entities within each domain and how they connect.
1. Business Architecture Entities
The most common entities here are Business Services, Processes, and Functions. A Business Service is what the organization provides to its customers. A Process is the sequence of steps taken to deliver that service.
2. Information Systems Architecture Entities
This covers Data and Application domains.
- Application Component: A discrete piece of software.
- Data Object: A representation of business information.
A crucial relationship in the metamodel is that Application Components process Data Objects to support Business Services.
3. Technology Architecture Entities
These are the hardware and platform services. Technology Services (like "Database Service") are provided by Technology Components (like "Oracle Database v19c").
Why the Metamodel Matters for Your Career
Understanding the metamodel is not just for the exam; it is what separates a designer from an architect. An architect looks at the relationships. When a business stakeholder says "we need to replace our CRM," the architect uses the metamodel to trace that CRM (Application Component) to the customer data it stores (Data Object) and the sales processes it enables (Business Process).
By mapping these connections, you can accurately predict the impact of changes, calculate risks, and justify architecture investments to executive leadership.
The Metamodel and the ADM
The Content Metamodel provides the structure for the outputs of each ADM phase.
- Phase B (Business): Populates the business entities.
- Phase C (Data/App): Populates the information systems entities.
- Phase D (Technology): Populates the technology entities.
As you move through the ADM cycle, you are essentially "filling in the blanks" of your metamodel for the specific project or enterprise scope you are working on.
Metamodel vs. Model
A common point of confusion: The *metamodel* is the definition of what can exist (the types of things). A *model* is the actual instance of those things for your organization (the specific things).
Summary
The TOGAF Content Metamodel is the skeleton of your architecture. It defines the categories of information you need to collect and how they relate across the four domains. By starting with a clear metamodel, you ensure that your architecture is robust, searchable, and capable of supporting complex decision-making.
In our next post, we will look at where all this modeled data is stored: The TOGAF Architecture Repository.
This post is part of the TOGAF 9.2 Masterclass series. Check out our previous post on ADM Iteration and Scoping to see how to apply the framework at different scales.