TOGAF Content Metamodel: Mapping Architecture Entities

← Back to TOGAF Hub

The TOGAF Content Metamodel defines the entities architects work with — business services, data objects, application components, and technology services — and the relationships between them. Without it, different architects in the same organisation would model the same things differently, producing inconsistent, incompatible architectures.

What is the TOGAF Content Metamodel?

The TOGAF Content Metamodel is the formal framework that defines the types of architecture entities an enterprise architecture can contain and how those entities relate to one another. It provides a common vocabulary that makes architectures consistent, searchable, and reusable across teams, projects, and ADM cycles. Every artifact produced during the ADM — from a business process model to a technology standards catalogue — refers back to the metamodel for its structure.

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. The full specification is maintained by The Open Group.

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).

Practical Benefits of a Well-Implemented Metamodel

Organizations that invest in defining their Content Metamodel properly before populating their Architecture Repository gain measurable advantages:

Impact analysis becomes fast: Because entities and relationships are formally defined, querying "what will be affected if we retire Application X?" returns accurate, complete answers in minutes rather than days of manual investigation
Onboarding new architects is easier: A new team member can explore the metamodel and immediately understand how the organization's architecture is structured without reading hundreds of documents
Governance becomes enforceable: The Architecture Board can define compliance checks based on metamodel rules — for example, "every Application Component must be linked to at least one Business Service" — and automatically flag architectures that do not meet this standard
Tooling becomes more effective: EA tools like Sparx Enterprise Architect and Bizzdesign Horizons store models against a defined metamodel, enabling automated reporting and cross-domain impact analysis

How the Content Metamodel Supports Certification

For TOGAF certification candidates, the Content Metamodel appears most directly in the Architecture Content Framework questions on the Foundation exam and the scenario-based questions on the Practitioner exam.

You should be able to:

Distinguish the core metamodel entities from the extension entities
Explain the relationships between entities across the four domains
Identify which ADM phase populates which part of the metamodel
Describe the difference between a metamodel and a model instance

These topics are tested directly and appear in scenario questions disguised as real-world architecture problems. Connecting the theory to practical examples — as covered in the sections above — is the most effective preparation.

Explore related topics in our series: The TOGAF Architecture Repository explains where metamodel instances are stored, and TOGAF Artifacts and Deliverables covers the formal outputs that reference the metamodel.

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.

The core metamodel covers the essential entities every architecture requires. Extensions add governance, motivation, infrastructure, and data detail for organizations that need them. Every output of the ADM phases B through D populates this metamodel, making it the connective tissue of the entire framework.

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. Also see our deep-dive on the TOGAF Four Architecture Domains for the business context that drives every metamodel entity.

Common Mistakes with the TOGAF Content Metamodel

1. Treating the Content Metamodel as optional Some architects view the Content Metamodel as abstract theory with no practical relevance. In reality, it is the specification that defines what every catalog, matrix, and diagram should contain. Without it, each architect produces artefacts in their own style, making cross-programme consistency impossible and governance reviews ad hoc. The metamodel is the shared vocabulary of the architecture practice.

2. Confusing the Content Metamodel with an information model The TOGAF Content Metamodel is not a data model for an enterprise application — it is a classification system for architecture artefacts. Its entities (Application Component, Data Entity, Business Service, etc.) are architecture concepts, not database tables. The confusion arises because many enterprise architecture tools represent the metamodel in a database-style interface, but the artefacts it organises are architectural descriptions, not operational data.

3. Not extending the metamodel for the organisation's context TOGAF's Content Metamodel is designed to be extended. An organisation in financial services needs concepts like Regulatory Obligation and Control Object that the generic metamodel does not include. The Preliminary Phase should tailor the metamodel to add domain-specific entities and relationships. Applying the metamodel verbatim without customisation often leaves important architecture concerns without a home.

4. Missing relationship types between entities The metamodel defines not just entities (what things exist) but relationships between them (how they connect). An Application Component that has no documented relationship to the Business Services it supports, or to the Technology Components it runs on, provides an incomplete architectural picture. Always document both entities and their relationships — the matrices produced in each ADM phase make these relationships explicit.

5. Applying full metamodel depth to every engagement The full metamodel has dozens of entity types. Small-scope architecture engagements do not need all of them. The Preliminary Phase should agree on the subset of entities relevant to the engagement — a focused application rationalisation needs Application Component, Data Entity, and Technology Component; it does not need Business Process or Actor unless business impact analysis is in scope.

Frequently Asked Questions

What is the TOGAF Architecture Content Framework? The Architecture Content Framework is TOGAF's structured classification of everything an enterprise architecture practice produces. It has three main components: (1) the Content Metamodel — definitions of architecture concepts and their relationships; (2) Architectural Artifacts — the catalogs, matrices, and diagrams that instantiate the metamodel for a specific architecture; (3) Architecture Deliverables — the formally reviewed and approved documents that package artifacts for governance review. The TOGAF standard Part IV defines the full Content Framework.

What is the difference between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs)? Architecture Building Blocks (ABBs) are vendor-neutral, technology-agnostic architectural components that define a capability (e.g., "Identity Provider," "Message Broker"). They exist in the Architecture Continuum. Solution Building Blocks (SBBs) are concrete implementations of ABBs — specific products, software packages, or systems that deliver the capability (e.g., "Microsoft Entra ID," "Apache Kafka"). SBBs exist in the Solutions Continuum. The mapping from ABBs to SBBs is the bridge between architecture and solution selection.

How does the TOGAF Content Metamodel relate to ArchiMate? The TOGAF Content Metamodel defines what architecture concepts exist and how they relate. ArchiMate provides the visual notation and formal language to represent those concepts in diagrams. ArchiMate's element types (Business Process, Application Component, Node, etc.) correspond closely to TOGAF Content Metamodel entity types, which is why the two standards are used together. The ArchiMate 3.1 specification includes a TOGAF mapping appendix.