TOGAF Enterprise Metamodel Entities Knowledge-Based Study

Study notes

1. Understanding the Metamodel

   The TOGAF Content Metamodel provides a structured definition of the architectural work products and concepts used within an Enterprise Architecture (EA). It defines the formal model that establishes the entities, their attributes, and relationships across an enterprise.

   The primary objectives of the Content Metamodel are:

   • To provide a consistent vocabulary for describing architecture across multiple domains.
   • To ensure that architectures created across different phases of the Architecture Development Method (ADM) are coherent, traceable, and queryable.
   • To facilitate the integration and exchange of architecture models across different modeling tools and repositories.

   By standardizing metamodel entities, organizations avoid ambiguity when defining business, application, data, and technology elements.

   Key Entities by Architecture Domain

   The Content Metamodel classifies architecture artifacts into four foundational domains. Each domain contains distinct entities with clearly defined semantics:

   Business Architecture Entities

   • Actor: An internal or external person, organization, or system that participates in an enterprise role or performs activities.
   • Role: An actor's specific responsibility or position within the organization.
   • Business Service: An explicitly defined, externally visible capability offered to consumers by business processes or functions.
   • Business Process: A structured, bounded set of activities that deliver an output to a customer or stakeholder.
   • Function: A logical grouping of business activities based on specific capabilities or expertise, independent of organizational structure.

   Data Architecture Entities

   • Data Entity: An encapsulation of data that is recognized by a business domain expert as distinct and relevant to the enterprise (e.g., Customer, Order).
   • Logical Data Component: A boundary grouping related data entities to support application and operational requirements.
   • Physical Data Component: A concrete implementation of data storage, such as a database table, file system, or data warehouse.

   Application Architecture Entities

   • Logical Application Component: An encapsulation of application functionality independent of implementation technology (e.g., Customer Relationship Management Engine).
   • Physical Application Component: A specific software product, package, or custom deployment unit executing application functionality.
   • Application Service: An automated boundary delivering functionality defined by an application component to consumers.

   Technology Architecture Entities

   • Node: A hardware or execution environment capable of hosting physical application or data components.
   • Technology Service: An infrastructure capability exposed to support application functionality (e.g., Storage Service, Message Bus).

   Strategy and Motivation Concepts

   In the TOGAF Standard, 10th Edition, architecture aligns technology with high-level direction through motivational and strategic entities:

   • Driver: An external or internal condition that motivates an organization to define its goals and initiate change (e.g., regulatory shifts, market competition).
   • Goal: A high-level statement of intent or direction that an enterprise seeks to achieve.
   • Objective: A specific, measurable, time-bound target designed to achieve a parent goal.
   • Capability: An ability that an organization, person, or system possesses to execute a particular course of action. Capabilities are stable and define what an enterprise can do.
   • Value Stream: An end-to-end representation of the value-creating flow of activities that delivers an outcome to a customer, partner, or stakeholder.
   • Course of Action: An approach or plan configured to achieve goals and objectives, often realized by allocating capabilities and resources.

   Governance and Delivery Metamodel Entities

   Transitioning from the Baseline Architecture to the Target Architecture relies on implementation and governance concepts:

   • Work Package: A set of actions identified to achieve one or more objectives, typically managed as a project, program, or release.
   • Deliverable: An agreed, measurable work product that must be produced and verified to satisfy project requirements or architecture contracts.
   • Architecture Contract: A formal agreement between sponsors and delivery teams specifying the deliverables, quality parameters, and governance conformance.
   • Requirement: A quantitative or qualitative statement of need that must be fulfilled by the proposed solution.
   • Constraint: A restriction or limitation imposed on architectural choices (e.g., budget limits, mandatory legacy standards, statutory compliance).

   These entities allow enterprise architects to maintain governance across Phase E (Opportunities & Solutions), Phase F (Migration Planning), and Phase G (Implementation Governance).