Why Use TOGAF Content Metamodel in Ardoq?
Using the TOGAF Content Metamodel in Ardoq provides organizations with a standardized vocabulary and structure for Enterprise Architecture, enabling consistent documentation across business, application, data, and technology domains. It establishes formal relationships between architectural elements—from strategic drivers through business capabilities to technology infrastructure—enabling traceability, impact analysis, and gap identification. The metamodel helps architects create architectures that are comparable across projects, understandable to stakeholders, and aligned with industry best practices. This article provides a high-level overview of how the TOGAF Architecture Content Metamodel is adapted for use within the Ardoq platform via the Frameworks and Resources importer. It explains how TOGAF concepts are translated into Ardoq's core entities: Folders, Workspaces, Component Types, and Reference Types, making the framework instantly actionable.
How Ardoq Adopts TOGAF Content Metamodel
The TOGAF Content Metamodel is implemented in Ardoq as a practical adaptation of the official framework, organized across architecture domains: Architecture Principles & Vision, Business Architecture, Information Systems Architecture (Data and Application), Technology Architecture, and Architecture Realization. This implementation provides a starting foundation that organizations can extend and customize to meet their specific architecture modeling needs. While not a literal 1:1 mapping of every entity and extension in the official TOGAF specification, this structure captures the core metamodel concepts and essential relationships in a format optimized for enterprise architecture tooling. Organizations can use these pre-configured component types and reference types as-is, or adapt them by adding custom entities, specialized relationships, or metamodel extensions relevant to their architecture practice maturity and organizational context.
Content Metamodel Overview
Core Metamodel vs. Extensions
The TOGAF metamodel is organized into Core Content and Extensions:
Core Content Metamodel
Provides the minimum set of entities and relationships needed for traceability across all architecture domains
Designed to remain stable and should not be altered
Supports the essential flow from business strategy through implementation
Metamodel Extensions
Allow for more specific or in-depth modeling based on organizational needs
Include: Governance, Services, Process Modeling, Data, Infrastructure Consolidation, and Motivation extensions
Can be adopted selectively based on architecture complexity and requirements
Using the TOGAF Metamodel in Ardoq
Translation to Ardoq Platform
The TOGAF metamodel concepts map to Ardoq entities as follows:
TOGAF Entities → Ardoq Component Types: Each metamodel entity becomes a distinct component type
TOGAF Relationships → Ardoq Reference Types: Metamodel relationships become typed references connecting components
TOGAF Domains → Ardoq Organizational Structure: Architecture domains are organized using folders and workspaces
Architecture Domains in TOGAF
The Content Metamodel organizes architecture content across several domains that align with the ADM:
1. Architecture Principles, Vision, and Requirements
Captures the strategic direction, constraints, and governance that guide architecture development.
Key Entities:
Principles - Fundamental rules governing architecture decisions
Stakeholders - Individuals or groups with interests in the architecture
Vision - High-level aspirational view of the future state
Requirements - Specific needs the architecture must address
Constraints - Limitations on architecture solutions
Typical Usage: Preliminary Phase and Phase A (Architecture Vision)
2. Business Architecture
Defines the business strategy, governance, organization, and key business processes.
Motivation Layer Captures why the organization exists and what it aims to achieve.
Drivers - External or internal factors creating need for change
Goals - High-level statements of business intent
Objectives - Time-bound, measurable targets
Measures - Metrics for tracking progress
Organization Layer Defines the structural aspects of the business.
Organization Units - Departments, divisions, teams
Actors - People or systems that perform work
Roles - Defined responsibilities
Functions - Organizational capabilities
Locations - Physical or logical places where work occurs
Behavior Layer Describes what the business does and the value it delivers.
Business Capabilities - Fundamental abilities the organization possesses
Business Services - Explicitly defined functions with governed interfaces
Value Streams - End-to-end flows of value delivery
Processes - Structured activities that transform inputs to outputs
Events - Triggers that initiate processes
Products - Outputs delivered to customers
Service Qualities - Non-functional characteristics (SLAs, performance criteria)
Typical Usage: Phase B (Business Architecture)
3. Information Systems Architecture
Defines the application and data landscape that supports business operations.
Data Architecture
Data Entities - Logical business data objects
Logical Data Components - Logical groupings of data
Physical Data Components - Actual databases, repositories, files
Application Architecture
Information System Services - Automated capabilities exposed by applications
Logical Application Components - Logical application building blocks
Physical Application Components - Actual application instances
Key Concept: The logical/physical separation enables Target Architecture definition independent of specific technology choices, supporting gap analysis between current and future states.
Typical Usage: Phase C (Information Systems Architecture)
4. Technology Architecture
Defines the infrastructure and technology services that provide the foundation for applications and data.
Key Entities:
Technology Services - Infrastructure capabilities (compute, storage, network)
Logical Technology Components - Technology-independent infrastructure patterns
Physical Technology Components - Actual technology products and infrastructure
Integration Note: The TOGAF Technical Reference Model (TRM) provides a detailed taxonomy of platform services that can be used to populate technology architecture content.
Typical Usage: Phase D (Technology Architecture)
5. Architecture Realization
Bridges architecture design to implementation through planning and governance.
Implementation Planning
Work Packages - Groups of projects delivering architecture change
Opportunities and Solutions - Strategic approaches to implementation
Governance
Standards - Mandatory technical or business rules
Guidelines - Recommended approaches
Specifications - Detailed technical requirements
Architecture Contracts - Formal agreements governing implementation
Typical Usage: Phases E-G (Opportunities & Solutions, Migration Planning, Implementation Governance)
Core Relationships
The TOGAF metamodel defines standardized relationships that create end-to-end traceability across architecture domains. These relationships connect strategic intent (drivers, goals, objectives) through business operations (capabilities, services, processes) down to technical implementation (applications, data, infrastructure). This enables architects to perform impact analysis, trace requirements to solutions, identify gaps between baseline and target states, and understand dependencies across organizational boundaries.
Related Resources
TOGAF Technical Reference Model (TRM) - available via Frameworks and Resources
TOGAF Government Reference Model (GRM) - available via Frameworks and Resources
Importing TOGAF TRM into Ardoq
Access the TOGAF TRM through Ardoq's Frameworks & Resources Importer. For step-by-step instructions, see How to use the Frameworks & Resources Importer.
Unlocking the TOGAF Framework
To access TOGAF content in Ardoq, you must provide proof of a valid TOGAF license as described by The Open Group. Contact your Ardoq representative to unlock this framework for your organization.