-
30. Content Metamodel
30.1 Overview
The TOGAF Architecture Development Method (ADM) provides a process lifecycle to create and manage architectures within an enterprise. At each phase within the ADM, a discussion of inputs, outputs, and steps describes a number of architectural work products or artifacts, such as process and application. The content metamodel provided here defines a formal structure for these terms to ensure consistency within the ADM and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.
30.2 Content Metamodel Vision and Concepts
This section provides an overview of the objectives of the content metamodel, the concepts that support the metamodel, and an overview of the metamodel itself. Subsequent sections then go on to discuss each area of the metamodel in more detail. Contents of this section are as follows:
- Core content metamodel concepts (see 30.2.1 Core Content Metamodel Concepts) identifies the key
concepts within the core content metamodel, including:
- Core and extension content
- Formal and informal modeling
- Core metamodel entities
- Overview of the TOGAF content metamodel (see 30.2.2 Overview of the Content Metamodel) provides a high-level overview of the content of the metamodel
30.2.1 Core Content Metamodel Concepts
A TOGAF architecture is based on defining a number of architectural building blocks within architecture catalogs, specifying the relationships between those building blocks in architecture matrices, and then presenting communication diagrams that show in a precise and concise way what the architecture is.
This section introduces the core concepts that make up the TOGAF content metamodel, through the following subsections:
- Core and Extension Content provides an introduction to the way in which the TOGAF framework employs a basic core metamodel and then applies a number of extension modules to address specific architectural issues in more detail
- Core Metamodel Entities introduces the core TOGAF metamodel entities, showing the purpose of each entity and the key relationships that support architectural traceability
Core and Extension Content
The role of the TOGAF framework is to provide an open standard for architecture that is applicable in many scenarios and situations. In order to meet this vision, it is necessary to provide a fully featured Enterprise Architecture metamodel for content and also to provide the ability to avoid carrying out unnecessary activities by supporting tailoring.
The metamodel must provide a basic model with the minimum feature set and then support the inclusion of optional extensions during engagement tailoring.
The core TOGAF content metamodel and its extensions are illustrated in Figure 30-1 .
Figure 30-1: TOGAF Content Metamodel and its Extensions The core metamodel provides a minimum set of architectural content to support traceability across artifacts. Additional metamodel concepts to support more specific or more in-depth modeling are contained within a group of extensions that logically cluster extension catalogs, matrices, and diagrams, allowing focus in areas of specific interest and focus.
All extension modules are optional and should be selected during the Preliminary Phase of the architecture development to meet the needs of the organization. Additionally, the extension groupings described by the content metamodel are only a suggestion and further tailoring may be carried out to suit the specific needs at the discretion of the architects.
This core and extension concept is intended as a move towards supporting formal method extension approaches within the TOGAF framework, such as the method plug-in concept found within the Software Process Engineering Metamodel (SPEM™) developed by the Object Management Group (OMG).1
Core Metamodel Entities
The content metamodel uses the terminology discussed within the TOGAF ADM as the basis for a formal metamodel. The following core terms are used:
- Actor: a person, organization, or system that is outside the consideration of the architecture model, but interacts with it
- Application Component: an encapsulation of application functionality that is aligned to implementation structure
- Business Capability: a particular ability that a business may possess or exchange to achieve a specific purpose
- Business Service: supports business capabilities through an explicitly defined interface and is explicitly governed by an organization
- Course of Action: direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model
- Data Entity: an encapsulation of data that is recognized by a business domain expert as a discrete concept
Data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
- Function: delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization
- Information System Service: the automated elements of a business service
An information system service may deliver or support part or all of one or more business services.
- Organization Unit: a self-contained unit of resources with goals, objectives, and measures
Organization units may include external parties and business partner organizations.
- Role: an actor assumes a role to perform a task
- Technology Component: an encapsulation of technology infrastructure that represents a class of technology product or specific technology product
- Technology Service: a technical capability required to provide enabling infrastructure that supports the delivery of applications
- Value Stream: a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user
A more in-depth definition of terms used within the content metamodel can be found in Part I, 3. Definitions .
Some of the key relationship concepts related to the core metamodel entities are described below:
- Process should normally be used to describe flow
A process is a flow of interactions between functions and services and cannot be physically deployed. All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports; i.e., an application implements a function that has a process, not an application implements a process.
- Function describes units of business capability at all levels of granularity
The term "function" is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function.
- Business services support organizational objectives and are defined at a level of granularity consistent with the level of
governance needed
A business service operates as a boundary for one or more functions. The granularity of business services is dependent on the focus and emphasis of the business (as reflected by its drivers, goals, and objectives). A service in Service-Oriented Architecture (SOA) terminology (i.e., a deployable unit of application functionality) is actually much closer to an application service, application component, or technology component, which may implement or support a business service.
- Business services are deployed onto application components
Business services may be realized by business activity that does not relate to IT, or may be realized through IT. Business services that are realized through IT are implemented onto application components. Application components can be hierarchically decomposed and may support one or more business services. It is possible for a business service to be supported by multiple application components, but this is problematic from a governance standpoint and is symptomatic of business services that are too coarse-grained, or application components that are too fine-grained.
- Application components are deployed onto technology components
An application component is implemented by a suite of technology components. For example, an application such as "HR System" would typically be implemented on several technology components, including hardware, application server software, and application services.
Figure 30-2 illustrates the core entities and their relationships.
Figure 30-2: Core Entities and their Relationships 30.2.2 Overview of the Content Metamodel
The content metamodel defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability.
At the highest level, the content framework is divided up in line with the TOGAF ADM phases, as shown in Figure 30-3 .
Figure 30-3: Content Framework by ADM Phases - Architecture Principles, Vision, and Requirements entities are intended to capture the surrounding context of formal
architecture models, including general Architecture Principles, strategic context that forms input for architecture modeling, and
requirements generated from the architecture
The architecture context is typically collected in the Preliminary and Architecture Vision phases.
- Business Architecture entities capture architectural models of business operation, looking specifically at factors that motivate the enterprise, how the enterprise is organizationally structured, and also what business capabilities the enterprise has
- Information Systems Architecture entities capture architecture models of IT systems, looking at applications and data in line with the TOGAF ADM phases
- Technology Architecture entities capture procured technology assets that are used to implement and realize information system solutions
- Architecture Realization entities capture change roadmaps showing transition between architecture states and binding statements that are used to steer and govern an implementation of the architecture
A more detailed representation of the content metamodel is shown in Figure 30-4 .
Figure 30-4: Detailed Representation of the Content Metamodel 30.3 Content Metamodel in Detail
This section contains the following subsections:
- Core Content Metamodel (see 30.3.1 Core Content Metamodel) describes the metamodel entities that form the core content metamodel
- Full Content Metamodel (see 30.3.2 Full Content Metamodel) describes the metamodel entities that form extensions to the content metamodel
30.3.1 Core Content Metamodel
Figure 30-5 shows the metamodel entities and relationships that are present within the core content metamodel.
Figure 30-5: Entities and Relationships Present within the Core Content Metamodel 30.3.2 Full Content Metamodel
When all extensions are applied to the core content metamodel, a number of additional metamodel entities are introduced. Figure 30-6 shows which entities are contained in the core content metamodel and which entities are introduced by which extension.
Figure 30-6: Content Metamodel with Extensions The relationships between entities in the full metamodel are shown in Figure 30-7 .
Figure 30-7: Relationships between Entities in the Full Metamodel 30.4 Content Metamodel Extensions
As discussed earlier, the TOGAF content metamodel supports a number of extension modules that allow more in-depth consideration for particular architecture concerns. Figure 30-8 shows the core content metamodel and predefined extension modules.
Figure 30-8: Core Content Metamodel and Predefined Extension Modules During the Architecture Vision phase of a particular engagement, the scope of the engagement will be used to make a determination on appropriate extensions to be employed in order to adequately address the architecture requirements. For example, the scope of an engagement could be defined as core content, plus the governance extensions, as shown in Figure 30-9 .
Figure 30-9: Core Content with Governance Extensions
The following sections provide a more detailed description of the purpose and content of each of the extension modules.
30.4.1 Governance Extensions
Purpose
The governance extension is intended to allow additional structured data to be held against objectives and business services, supporting operational governance of the landscape.
The scope of this extension is as follows:
- The ability to apply measures to objectives and then link those measures to services
- The ability to apply contracts to service communication or service interactions with external users and systems
- The ability to define re-usable service qualities defining a service-level profile that can be used in contracts
- Creation of additional diagrams to show ownership and management of systems
This extension should be used in the following situations:
- When an organization is considering IT change that will result in a significant impact to existing operational governance models
- When an organization has granular requirements for service levels that differ from service to service
- When an organization is looking to transform its operational governance practice
- When an organization has very strong focus on business drivers, goals, and objectives and how these trace to service levels
The benefits of using this extension are as follows:
- Service levels are defined in a more structured way, with:
- More detail
- The ability to re-use service profiles across contracts
- Stronger tracing to business objectives
- Impacts to operations and operational governance models are considered in a more structured way, with:
- Additional diagrams of system and data ownership
- Additional diagrams of system operation and dependencies on operations processes
In addition to the extensions described here, organizations wishing to focus on Architecture Governance should also consult:
- The COBIT framework for IT governance provided by the Information Systems Audit and Control Association (ISACA); refer to www.isaca.org
- The IT Portfolio Management Facility™ (ITPMF™) from the OMG; refer to www.omg.org/spec/ITPMF
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-10 .
Figure 30-10: Governance Extensions: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- Measure is added as an entity that links objective and business service
- Service Quality is added as an entity that provides a generic service profile template to be applied to business services or contracts
- Contract is added as an entity that formalizes the functional and non-functional characteristics of a service interaction with other services, external applications, or users
Changes to the metamodel attributes are as follows:
- Attributes are added for the metamodel entities of Measure, Service Quality, and Service Contract
Additional diagrams to be created are as follows:
- Enterprise Manageability diagram
30.4.2 Services Extensions
Purpose
The services extension is intended to allow more sophisticated modeling of the service portfolio by creating a concept of Information System (IS) services in addition to the core concept of business services. IS services are directly supported by applications and creating the layer of abstraction relaxes the constraints on business services while simultaneously allowing technical stakeholders to put more formality into an IS service catalog.
The scope of this extension is as follows:
- Creation of IS services as an extension of business service
This extension should be used in the following situations:
- When the business has a preset definition of its services that does not align well to technical and architectural needs
- When business and IT use different language to describe similar capabilities
- Where IT service is misaligned with business need, particularly around the areas of quality of service, visibility of performance, and management granularity
- Where IT is taking initial steps to engage business in discussions about IT architecture
The benefits of using this extension are as follows:
- Business services can be defined outside of the constraints that exist in the core metamodel; this allows for a more natural engagement with business stakeholders
- IS services can be defined according to a model that maps closely to implementation, providing a more realistic solution abstraction to support IT decision-making
- Business and IS service relationships show where the business view aligns with the IS view and where there are misalignments
In addition to the extensions described here, organizations wishing to focus on services-centric architectures should also consult:
- The Service Component Architecture (SCA) specification developed by the Open Service Oriented Architecture (OSOA) collaboration; refer to www.oasis-opencsa.org/sca
- The Service Data Objects (SDO) specification developed by the Open Service Oriented Architecture (OSOA) collaboration; refer to www.oasis-opencsa.org/sdo
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-11 .
Figure 30-11: Services Extension: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- IS Service is added as a metamodel entity, extending business service
- IS Service inherits all the relationships of a business service
- A relationship is created linking an IS service to a business service
Changes to the metamodel attributes are as follows:
- IS Service is added as a type of business service
Additional diagrams to be created are as follows:
- Business Use-Case Diagram
- Organization Decomposition Diagram
30.4.3 Process Modeling Extensions
Purpose
The process modeling extension is intended to allow detailed modeling of process flows by adding events, products, and controls to the metamodel. Typically, Enterprise Architecture does not drill into process flow, but in certain process-centric or event-centric organizations it may be necessary to elaborate process in a much more formal manner using this extension module.
The scope of this extension is as follows:
- Creation of events as triggers for processes
- Creation of controls that business logic and governance gates for process execution
- Creation of products to represent the output of a process
- Creation of event diagrams to track triggers and state changes across the organization
This extension should be used in the following situations:
- Where the architecture must pay specific attention to state and events
- Where the architecture is required to explicitly identify and store process control steps; for example, to support regulatory compliance
- Where the architecture features critical or elaborate process flows
The benefits of using this extension are as follows:
- This extension allows detailed process modeling and the cataloging of process artifacts
- May be used to support regulatory compliance activities
- May be used to re-purpose legacy or non-architectural process decomposition analysis
In addition to the extensions described here, organizations wishing to focus on process-centric architectures should also consult:
- The Business Process Modeling Notation (BPMN) specification, provided by the OMG; refer to www.bpmn.org
- The Software Process Engineering Metamodel (SPEM) specification, provided by the OMG; refer to www.omg.org/spec/SPEM
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-12 .
Figure 30-12: Process Modeling Extensions: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- Event is added as a metamodel entity, sitting between Actor, Process, and Service
- Control is added as a metamodel entity, relating to a Process
- Product is added as a metamodel entity, linking Organization and Processes
Changes to the metamodel attributes are as follows:
- Attributes are added for the metamodel entities of Event, Control, and Product
Additional diagrams to be created are as follows:
- Process Flow diagrams, showing the way in which business functions, events, controls, and products are linked to support a particular business scenario
- Event diagrams, showing events, were they are received from, and what processes they trigger
30.4.4 Data Extensions
Purpose
The data extension is intended to allow more sophisticated modeling and the encapsulation of data. The core model provides a data entity concept which supports the creation of data models, which is then extended by this extension to include the concept of a data component. Data components form a logical or physical encapsulation of abstract data entities into units that can be governed and deployed into applications.
The scope of this extension is as follows:
- Creation of logical data components that group data entities into encapsulated modules for governance, security, and deployment purposes
- Creation of physical data components that implement logical data components and are analogous to databases, registries, repositories, schemas, and other techniques of segmenting data
- Creation of data lifecycle, data security, and data migration diagrams of the architecture to show data concerns in more detail
This extension should be used in the following situations:
- Where the architecture features significant complexity and risk around the location, encapsulation, and management of or access to data
The benefits of using this extension are as follows:
- The structure of data is modeled independently from its location, allowing data models to be developed that span multiple systems without being tied to physical concerns
- Logical groupings of data can be used to set governance, security, or deployment boundaries around data, providing a much more holistic appreciation of data issues surrounding the architecture
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-13 .
Figure 30-13: Data Extensions: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- Logical Data Component is added as a metamodel entity, encapsulating data entities
- Physical Data Component is added as a metamodel entity, extending Logical Data Component
- A relationship is created between Physical Data Component and Application Component; if the infrastructure consolidation extension is applied, this should be to Physical Application Component
Changes to the metamodel attributes are as follows:
- Attributes are added for the metamodel entities of Logical Data Component and Physical Data Component
Additional diagrams to be created are as follows:
- Data Security diagram
- Data Migration diagram
- Data Lifecycle diagram
30.4.5 Infrastructure Consolidation Extensions
Purpose
The infrastructure consolidation extension is intended to be used in landscapes where the application and technology portfolios have become fragmented and the architecture seeks to consolidate the business as usual capability into a smaller number of locations, applications, or technology components.
The scope of this extension is as follows:
- Creation of logical and physical application components to abstract the capability of an application away from the actual applications in existence
- Creation of logical and physical technology components to abstract product type from the actual technology products in existence
- Creation of additional diagrams focusing on the location of assets, compliance with standards, structure of applications, application migration, and infrastructure configuration
This extension should be used in the following situations:
- Where many technology products are in place with duplicate or overlapping capability
- Where many applications are in place with duplicate or overlapping functionality
- Where applications are geographically dispersed and the decision logic for determining the location of an application is not well understood
- When applications are going to be migrated into a consolidated platform
- When application features are going to be migrated into a consolidated application
The benefits of using this extension are as follows:
- Allows visibility and analysis of redundant duplication of capability in the application and technology domains
- Supports analysis of standards compliance
- Supports analysis of migration impact of application or technology consolidation
- Supports detailed architectural definition of application structure
In addition to the extensions described here, organizations wishing to focus on infrastructure consolidation should also consult:
- The Unified Modeling Language (UML), provided by the OMG; refer to www.uml.org
- The Systems Modeling Language&tradel (SysML®) - www.sysml.org - which reduces the complexity and software engineering focus of UML for the purposes of systems modeling
- The IT Portfolio Management Facility (ITPMF) from the OMG; refer to www.omg.org/spec/ITPMF
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-14 .
Figure 30-14: Infrastructure Consolidation Extensions: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- Application Components are extended to include Logical Application Components (a class of application) and Physical Application Components (an actual application)
- Technology Components are extended to include Logical Technology Components (a class of technology product) and Physical Technology Components (an actual technology product)
Changes to the metamodel attributes are as follows:
- Creation of attributes for the Metamodel entities of Logical Application Component, Physical Application Component, Logical Technology Component, Physical Technology Component, and Location
Additional diagrams to be created are as follows:
- Process/Application Realization diagram
- Software Engineering diagram
- Application Migration diagram
- Software Distribution diagram
- Processing diagram
- Networked Computing/Hardware diagram
- Network and Communications diagram
30.4.6 Motivation Extensions
Purpose
The motivation extension is intended to allow additional structured modeling of the drivers, goals, and objectives that influence an organization to provide business services to its customers. This in turn allows more effective definition of service contracts and better measurement of business performance.
The scope of this extension is as follows:
- Creation of a metamodel entity for Driver that shows factors generally motivating or constraining an organization
- Creation of a metamodel entity for Goal that shows the strategic purpose and mission of an organization
- Creation of a metamodel entity for Objective that shows near to mid-term achievements that an organization would like to attain
- Creation of a Goal/Objective/Service diagram showing the traceability from drivers, goals, and objectives through to services
This extension should be used in the following situations:
- When the architecture needs to understand the motivation of organizations in more detail than the standard business or engagement principles and objectives that are informally modeled within the core content metamodel
- When organizations have conflicting drivers and objectives and that conflict needs to be understood and addressed in a structured form
- When service levels are unknown or unclear
The benefits of using this extension are as follows:
- Highlights misalignment of priorities across the enterprise and how these intersect with shared services (e.g., some organizations may be attempting to reduce costs, while others are attempting to increase capability)
- Shows competing demands for business services in a more structured fashion, allowing compromise service levels to be defined
In addition to the extensions described here, organizations wishing to focus on architecture modeling of business motivation should also consult:
- The Business Motivation Model™ (BMM™) specification, provided by the OMG; refer to www.omg.org/spec/BMM/About-BMM
Required Extensions to the Core Metamodel
Extensions to the core metamodel entities and relationships are shown in Figure 30-15 .
Figure 30-15: Motivation Extensions: Extensions to Core Metamodel Changes to the metamodel entities and relationships are as follows:
- Driver, Goal, and Objective are added as entities that link Organization Unit to Business Service
Changes to the metamodel attributes are as follows:
- Attributes are added for the metamodel entities of Driver, Goal, and Objective
Additional diagrams to be created are as follows:
- Goal/Objective/Service diagram
30.5 Content Metamodel Entities
The following table lists and describes the entities within the content metamodel.
Metamodel Entity
Description
Actor
A person, organization, or system that has a role that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization. In the automotive industry, an original equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply chain activities.
Application Component
An encapsulation of application functionality aligned to implementation structure. For example, a purchase request processing application.
See also Logical Application Component and Physical Application Component.
Assumption
A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated.
Business Capability
A particular ability that a business may possess or exchange to achieve a particular purpose.
Business Service
Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
Capability
A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value.
Constraint
An external factor that prevents an organization from pursuing particular approaches to meet its goals. For example, customer data is not harmonized within the organization, regionally or nationally, constraining the organization's ability to offer effective customer service.
Contract
An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction.
Control
A decision-making step with accompanying decision logic used to determine execution approach for a process or to ensure that a process complies with governance criteria. For example, a sign-off control on the purchase request processing process that checks whether the total value of the request is within the sign-off limits of the requester, or whether it needs escalating to higher authority.
Course of Action
Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model.
Data Entity
An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations.
Driver
An external or internal condition that motivates the organization to define its goals. An example of an external driver is a change in regulation or compliance rules which, for example, require changes to the way an organization operates; i.e., Sarbanes-Oxley in the US.
Event
An organizational state change that triggers processing events; may originate from inside or outside the organization and may be resolved inside or outside the organization.
Function
Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as "business function".
Gap
A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.
- Note:
- Gap analysis is described in Part III, 23. Gap Analysis .
Goal
A high-level statement of intent or direction for an organization. Typically used to measure success of an organization.
Information System
ServiceThe automated elements of a business service. An information system service may deliver or support part or all of one or more business services.
Location
A place where business activity takes place and can be hierarchically decomposed.
Logical Application
ComponentAn encapsulation of application functionality that is independent of a particular implementation. For example, the classification of all purchase request processing applications implemented in an enterprise.
Logical Data
ComponentA boundary zone that encapsulates related data entities to form a logical location to be held; for example, external procurement information.
Logical Technology
ComponentAn encapsulation of technology infrastructure that is independent of a particular product. A class of technology product; for example, supply chain management software as part of an Enterprise Resource Planning (ERP) suite, or a Commercial Off-The-Shelf (COTS) purchase request processing enterprise service.
Measure
An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment with objectives and goals.
Objective
A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example, "Increase capacity utilization by 30% by the end of 2019 to support the planned increase in market share".
Organization Unit
A self-contained unit of resources with goals, objectives, and measures. Organization units may include external parties and business partner organizations.
Physical Application
ComponentAn application, application module, application service, or other deployable component of functionality. For example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP) supply chain management application.
Physical Data
ComponentA boundary zone that encapsulates related data entities to form a physical location to be held. For example, a purchase order business object, comprising purchase order header and item business object nodes.
Physical Technology
ComponentA specific technology infrastructure product or technology infrastructure product instance. For example, a particular product version of a Commercial Off-The-Shelf (COTS) solution, or a specific brand and version of server.
Principle
A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
- Note:
- A sample set of Architecture Principles is defined in Part III, 20. Architecture Principles .
Process
A process represents flow of control between or within functions and/or services (depends on the granularity of definition).
Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes.
Product
Output generated by the business. The business product of the execution of a process.
Requirement
A quantitative statement of business need that must be met by a particular architecture or work package.
Role
The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles.
See also Actor.
Service
An element of behavior that provides specific functionality in response to requests from actors or other services. A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems, and platforms.
Service Quality
A preset configuration of non-functional attributes that may be assigned to a service or service contract.
Technology Component
An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.
Technology Service
A technical capability required to provide enabling infrastructure that supports the delivery of applications.
Value Stream
A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user.
Work Package
A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.
30.6 Content Metamodel Attributes
The following table shows typical attributes for each of the metamodel entities described previously.
Metamodel
Entity Attribute
Description
All Metamodel Entities
ID
Unique identifier for the architecture entity.
Name
Brief name of the architecture entity.
Description
Textual description of the architecture entity.
Category
User-definable categorization taxonomy for each metamodel entity.
Source
Location from where the information was collected.
Owner
Owner of the architecture entity.
Capability
Business value
Describes how this capability provides value to the enterprise.
Increments
Lists possible maturity/quality levels for the capability.
Constraint
No additional attributes
This metamodel entity has only basic attributes.
Gap
No additional attributes
This metamodel entity has only basic attributes.
Location
Category
The following categories of Location apply: Region (applies to a grouping of countries or territory; e.g., South East Asia, UK, and Ireland), Country (applies to a single country; e.g., US), Building (applies to a site of operation; where several offices are collected in a single city, this category may represent a city), and Specific Location (applies to any specific location within a building, such as a server room). The nature of the business may introduce other Locations: Ship or Port for a ferry company, Mine for a gold company, Car for a police force, Hotel for any firm's traveling workers, and so on.
Principle
Category
The following categories of principle apply: Guiding Principle, Business Principle, Data Principle, Application Principle, Integration Principle, Technology Principle.
Priority
Priority of this principle relative to other principles.
Statement of principle
Statement of what the principle is.
Rationale
Statement of why the principle is required and the outcome to be reached.
Implication
Statement of what the principle means in practical terms.
Metric
Identifies mechanisms that will be used to measure whether the principle has been met or not.
Requirement
Statement of requirement
Statement of what the requirement is, including a definition of whether the requirement shall be met, should be met, or may be met.
Rationale
Statement of why the requirement exists.
Acceptance criteria
Statement of what tests will be carried out to ensure that the requirement will be met.
Actor
# FTEs
Estimated number of FTEs that operate as this Actor.
Actor goal
Objectives that this actor has, in general terms.
Actor tasks
Tasks that this actor performs, in general terms.
Business Service
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Contract
Behavior characteristics
Functional behavior to be supported within the scope of the contract.
Service name "caller"
Consuming service.
Service name "called"
Providing service.
Service quality characteristics
Non-functional behavior to be supported within the scope of the contract.
Availability characteristics
Degree to which something is available for use.
Service times
Hours during which the service must be available.
Manageability characteristics
Ability to gather information about the state of something and control it.
Serviceability characteristics
Ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system.
Performance characteristics
Ability of a component to perform its tasks in an appropriate time.
Response requirements
Response times that the service provider must meet for particular operations.
Reliability characteristics
Resistance to failure.
Quality of information required
Contracted requirements on accuracy and completeness of information.
Contract control requirements
Level of governance and enforcement applied to the contractual parameters for overall service.
Result control requirements
Measures in place to ensure that each service request meets contracted criteria.
Recoverability characteristics
Ability to restore a system to a working state after an interruption.
Locatability characteristics
Ability of a system to be found when needed.
Security characteristics
Ability of a system to prevent unauthorized access to functions and data.
Privacy characteristics
Protection of data from unauthorized access.
Integrity characteristics
Ability of a system to ensure that data has not been corrupted.
Credibility characteristics
Ability of a system to ensure that the service request originates from an authorized source.
Localization characteristics
Ability of a service to support localized variants for different consumer groups.
Internationalization characteristics
Ability of a service to support international variations in business logic and data representation (such as character set).
Interoperability characteristics
Ability of the service to interoperate with different technical environments, inside and outside of the organization.
Scalability characteristics
Ability of the service to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates.
Portability characteristics
Of data, people, applications, and components.
Extensibility characteristics
Ability to accept new functionality.
Capacity characteristics
Contracted capacity of the service provider to meet requests.
Throughput
Required throughput capacity.
Throughput period
Time period needed to deliver throughput capacity.
Growth
Expected future growth rate of service request.
Growth period
Time period needed to reach the expected growth rate.
Peak profile short term
Short-term profile of peak service traffic.
Peak profile long term
Long-term profile of peak service traffic.
Control
No additional attributes
This metamodel entity has only basic attributes.
Driver
No additional attributes
This metamodel entity has only basic attributes.
Event
No additional attributes
This metamodel entity has only basic attributes.
Function
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Goal
No additional attributes
This metamodel entity has only basic attributes.
Measure
No additional attributes
This metamodel entity has only basic attributes.
Objective
No additional attributes
This metamodel entity has only basic attributes.
Organization Unit
Headcount
Number of FTEs working within the organization.
Process
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Process criticality
Criticality of this process to business operations.
Manual or automated
Whether this process is supported by IT or is a manual process.
Process volumetrics
Data on frequency of process execution.
Product
No additional attributes
This metamodel entity has only basic attributes.
Role
Estimated number of FTEs that operate in this Role
This metamodel entity has only basic attributes.
Service Quality
No additional attributes
This metamodel entity has only basic attributes.
Service
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Application Component
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Information System
ServiceStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Logical Application
ComponentStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Physical Application
ComponentLifecycle status
Proposed, In Development, Live, Phasing Out, Retired.
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Initial live date
Date when the first release of the application was/will be released into production.
Date of last release
Date when the last release of the application was released into production.
Date of next release
Date when the next release of the application will be released into production.
Retirement date
Date when the application was/will be retired.
Availability characteristics
Degree to which something is available for use.
Service times
Hours during which the application must be available.
Manageability characteristics
Ability to gather information about the state of something and control it.
Serviceability characteristics
Ability to identify problems and take corrective action, such as to repair or upgrade a component in a running system.
Performance characteristics
Ability of a component to perform its tasks in an appropriate time.
Reliability characteristics
Resistance to failure.
Recoverability characteristics
Ability to restore a system to a working state after an interruption.
Locatability characteristics
Ability of a system to be found when needed.
Security characteristics
Ability of a system to prevent unauthorized access to functions and data.
Privacy characteristics
Protection of data from unauthorized access.
Integrity characteristics
Ability of a system to ensure that data has not been corrupted.
Credibility characteristics
Ability of a system to ensure that the service request originates from an authorized source.
Localization characteristics
Ability of a service to support localized variants for different consumer groups.
Internationalization characteristics
Ability of a service to support international variations in business logic and data representation (such as character set).
Interoperability characteristics
Ability of the service to interoperate with different technical environments, inside and outside of the organization.
Scalability characteristics
Ability of the service to grow or shrink its performance or capacity appropriately to the demands of the environment in which it operates.
Portability characteristics
Of data, people, applications, and components.
Extensibility characteristics
Ability to accept new functionality.
Capacity characteristics
Contracted capacity of the service provider to meet requests.
Throughput
Required throughput capacity.
Throughput period
Time period needed to deliver throughput capacity.
Growth
Expected future growth rate of service request.
Growth period
Time period needed to reach the expected growth rate.
Peak profile short term
Short-term profile of peak service traffic.
Peak profile long term
Long-term profile of peak service traffic.
Data Entity
Category
The following categories of data entity apply: Message, Internally Stored Entity.
Privacy classification
Level of restriction placed on access to the data.
Retention classification
Level of retention to be placed on the data.
Logical Data
ComponentStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Physical Data
ComponentStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Logical Technology
ComponentStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Category
Logical Technology Components are categorized according to the defined taxonomy (such as the TOGAF TRM), adapted to meet the needs of an individual organization.
Physical Technology
ComponentStandards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Standard creation date
If the product is a standard, when the standard was created.
Last standard review date
Last date that the standard was reviewed.
Next standard review date
Next date for the standard to be reviewed.
Retire date
Date when the standard was/will be retired.
Category
Physical Technology Components are categorized according to the defined taxonomy (such as the TOGAF TRM), adapted to meet the needs of an individual organization.
Product name
Name of the product making up the technology component.
Module name
Module, or other sub-product, name making up the technology component.
Vendor
Vendor providing the technology component.
Version
Version of the product making up the technology component.
Technology Service
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Category
Technology Services are categorized according to the defined taxonomy (such as the TOGAF TRM), adapted to meet the needs of an individual organization.
Business Capability
No additional attributes
This metamodel entity has only basic attributes.
Technology Component
Standards class
Non-Standard, Proposed Standard, Provisional Standard, Standard, Phasing-Out Standard, Retired Standard.
Course of Action
No additional attributes
This metamodel entity has only basic attributes.
Value Stream
No additional attributes
This metamodel entity has only basic attributes.
Work Package
Category
The following categories of work package apply: Work Package, Work Stream, Project, Program, Portfolio.
Capability delivered
Describes the contribution this work package makes to capability delivery.
30.7 Metamodel Relationships
Source Entity
Target Entity
Name
Extension Module
Actor
Event
Generates
Process
Actor
Event
Resolves
Process
Actor
Function
Interacts with
Core
Actor
Function
Performs
Core
Actor
Value Stream
Participates in
Core
Actor
Value Stream
Triggers
Core
Actor
Organization Unit
Belongs to
Core
Actor
Role
Performs task in
Core
Actor
Service
Consumes
Core
Actor
Actor
Decomposes
Core
Actor
Data Entity
Supplies/Consumes
Core
Business Capability
Course of Action
Is influenced by
Core
Business Capability
Function
Is delivered by
Core
Business Capability
Organizational Unit
Is used by
Core
Business Capability
Process
Is operationalized by
Core
Business Capability
Value Stream
Enables
Core
Capability
Work Package
Is delivered by
Core
Contract
Service
Governs and Measures
Governance
Contract
Service Quality
Meets
Governance
Control
Process
Ensures correct operation of
Process
Course of Action
Business Capability
Influences
Core
Course of Action
Goal
Realizes
Motivation
Course of Action
Function
Influences
Core
Course of Action
Value Stream
Influences
Core
Data Entity
Logical Data
ComponentResides within
Data
Data Entity
Service
Is accessed and updated through
Core
Data Entity
Information System
ServiceUses
Services
Data Entity
Data Entity
Decomposes
Core
Data Entity
Data Entity
Relates to
Core
Driver
Goal
Creates
Motivation
Driver
Organization Unit
Motivates
Motivation
Driver
Driver
Decomposes
Motivation
Event
Actor
Is resolved by
Process
Event
Actor
Is generated by
Process
Event
Process
Is resolved by
Process
Event
Process
Is generated by
Process
Event
Service
Is resolved by
Process
Function
Actor
Supports
Core
Function
Actor
Is performed by
Core
Function
Business Capability
Delivers
Core
Function
Organization Unit
Is owned by
Core
Function
Process
Supports
Core
Function
Process
Is realized by
Core
Function
Service
Is bounded by
Core
Function
Function
Decomposes
Core
Function
Function
Communicates with
Core
Goal
Course of Action
Is realized by
Motivation
Goal
Driver
Addresses
Motivation
Goal
Objective
Is realized through
Motivation
Goal
Goal
Decomposes
Motivation
Information System
ServiceData Entity
Used by
Services
Information System
ServiceService
Realizes
Services
Information System
ServiceTechnology Service
Is served by
Services
Information System
ServiceLogical Application
ComponentIs realized through
Services
Logical Application
ComponentPhysical Application
ComponentIs realized by
Infrastructure
ConsolidationLogical Application
ComponentService
Implements
Core
Logical Application
ComponentLogical Application
ComponentDecomposes
Core
Logical Application
ComponentLogical Application
ComponentCommunicates with
Core
Logical Application
ComponentLogical Data
ComponentUsed by
Data
Logical Application
ComponentLogical Technology
ComponentIs served by
Infrastructure
ConsolidationLogical Application
ComponentInformation System
ServiceImplements
Services
Logical Data
ComponentLogical Application
ComponentUses
Data
Logical Data
ComponentData Entity
Encapsulates
Data
Logical Data
ComponentPhysical Data Component
Is realized by
Data
Logical Technology
ComponentLogical Application
ComponentServes
Infrastructure
ConsolidationLogical Technology
ComponentPhysical Technology
ComponentIs realized by
Infrastructure
ConsolidationLogical Technology
ComponentTechnology Service
Supplies
Core
Logical Technology
ComponentService
Provides platform for
Core
Logical Technology
ComponentLogical Technology
ComponentDecomposes
Core
Logical Technology
ComponentLogical Technology
ComponentIs dependent on
Core
Logical Technology
ComponentLogical Application
ComponentServes
Infrastructure
ConsolidationMeasure
Objective
Sets performance criteria for
Governance
Measure
Service
Sets performance criteria for
Governance
Measure
Measure
Decomposes
Governance
Objective
Goal
Realizes
Motivation
Objective
Measure
Is tracked against
Governance
Objective
Objective
Decomposes
Motivation
Organization Unit
Actor
Contains
Core
Organization Unit
Business Capability
Uses
Core
Organization Unit
Driver
Is motivated by
Motivation
Organization Unit
Function
Owns
Core
Organization Unit
Product
Produces
Process
Organization Unit
Process
Involves
Core
Organization Unit
Service
Owns and Governs
Core
Organization Unit
Organization Unit
Decomposes
Core
Physical Application
ComponentLogical Application
ComponentRealizes
Infrastructure
ConsolidationPhysical Application
ComponentPhysical Data
ComponentUsed by
Data
Physical Application
ComponentPhysical Technology
ComponentIs served by
Core
Physical Application
ComponentPhysical Application
ComponentDecomposes
Core
Physical Application
ComponentPhysical Application
ComponentCommunicates with
Core
Physical Data
ComponentLogical Data
ComponentRealizes
Data
Physical Data
ComponentPhysical Data
ComponentDecomposes
Core
Physical Data
ComponentPhysical Application
ComponentUses
Data
Physical Technology
ComponentPhysical Application
ComponentServes
Core
Physical Technology
ComponentLogical Technology
ComponentRealizes
Infrastructure
ConsolidationPhysical Technology
ComponentPhysical Technology
ComponentDecomposes
Core
Physical Technology
ComponentPhysical Technology
ComponentIs dependent on
Core
Process
Control
Is guided by
Process
Process
Event
Generates
Process
Process
Event
Resolves
Process
Process
Function
Orchestrates
Core
Process
Function
Decomposes
Core
Process
Organization Unit
Involves
Core
Process
Product
Produces
Process
Process
Role
Involves
Core
Process
Role
Is performed by
Core
Process
Service
Orchestrates
Core
Process
Service
Decomposes
Core
Process
Process
Decomposes
Core
Process
Process
Precedes/Follows
Core
Product
Organization Unit
Is produced by
Process
Product
Process
Is produced by
Process
Role
Actor
Is performed by
Core
Role
Process
Participates in
Core
Role
Process
Performs
Core
Role
Role
Decomposes
Core
Service
Actor
Is provided to
Core
Service
Contract
Is governed and measured by
Governance
Service
Data Entity
Provides
Core
Service
Data Entity
Consumes
Core
Service
Event
Resolves
Process
Service
Function
Provides governed interface to access
Core
Service
Information System
ServiceIs realized through
Services
Service
Logical Application
ComponentIs realized through
Core
Service
Logical Technology
ComponentIs implemented on
Core
Service
Measure
Is tracked against
Governance
Service
Organization Unit
Is owned and governed by
Core
Service
Process
Supports
Core
Service
Process
Is realized by
Core
Service
Service Quality
Meets
Governance
Service
Service
Consumes
Core
Service
Service
Decomposes
Core
Service Quality
Contract
Applies to
Governance
Service Quality
Service
Applies to
Governance
Technology Service
Logical Technology
ComponentIs supplied by
Core
Technology Service
Information System
ServiceServes
Services
Value Stream
Actor
Involves
Core
Value Stream
Actor
Is triggered by
Core
Value Stream
Business Capability
Is enabled by
Core
Value Stream
Course of Action
Is influenced by
Core
Work Package
Capability
Delivers
Core
Footnotes
- 1.
- Refer to www.omg.org/spec/SPEM.
- Core content metamodel concepts (see 30.2.1 Core Content Metamodel Concepts) identifies the key
concepts within the core content metamodel, including: