Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Van Haren Publishing
- Kategorie: Bildung
- Sprache: Englisch
This document is a compilation of two documents within the TOGAF® Standard. It has been developed and approved by The Open Group, and is part of the TOGAF Standard, 10th Edition.
The two documents in this set are:
1. TOGAF Standard — Architecture Content
This document describes the TOGAF Content Framework and a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.
2. TOGAF Standard — Enterprise Architecture Capability and Governance
This document discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise, and describes an Enterprise Architecture governance framework.
The TOGAF Standard is intended for Enterprise Architects, Business Architects, IT Architects, Data Architects, Systems Architects, Solution Architects, and anyone responsible for the architecture function within an organization.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 224
Veröffentlichungsjahr: 2022
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
The TOGAF® Standard, 10th Edition Content, Capability, and Governance
The Open Group Publications available from Van Haren Publishing
The TOGAF® Standard, 10th Edition:
Introduction and Core Concepts
Architecture Development Method
Content, Capability, and Governance
Leader’s Guide
ADM Practitioners’ Guide
Business Architecture
Enterprise Agility and Digital Transformation
A Pocket Guide
The TOGAF Series:
The TOGAF® Standard, Version 9.2
The TOGAF® Standard, Version 9.2 – A Pocket Guide
TOGAF® 9 Foundation Study Guide, 4th Edition
TOGAF® 9 Certified Study Guide, 4th Edition
TOGAF® Business Architecture Level 1 Study Guide
The Open Group Series:
The IT4IT™ Reference Architecture, Version 2.1
IT4IT™ for Managing the Business of IT – A Management Guide
IT4IT™ Foundation Study Guide, 2nd Edition
The IT4IT™ Reference Architecture, Version 2.1 – A Pocket Guide
Cloud Computing for Business – The Open Group Guide
ArchiMate® 3.1 Specification – A Pocket Guide
ArchiMate® 3.1 Specification
The Digital Practitioner Pocket Guide
The Digital Practitioner Foundation Study Guide
Open Agile Architecture™ – A Standard of The Open Group
The Open Group Press:
The Turning Point: A Novel about Agile Architects Building a Digital Foundation
Managing Digital
The Open Group Security Series:
O-TTPS – A Management Guide
Open Information Security Management Maturity Model (O-ISM3)
Open Enterprise Security Architecture (O-ESA)
Risk Management – The Open Group Guide
The Open FAIR™ Body of Knowledge – A Pocket Guide
All titles are available to purchase from:
www.opengroup.org
www.vanharen.net
and also many international and online distributors.
Title:
The TOGAF® Standard, 10th Edition — Content, Capability, and Governance
Series:
TOGAF Series
A Publication of:
The Open Group
Publisher:
Van Haren Publishing, ’s-Hertogenbosch - NL, www.vanharen.net
ISBN Hardcopy:
978 94 018 0865 1
ISBN eBook:
978 94 018 0866 8
ISBN ePub:
978 94 018 0867 5
Edition:
First edition, first impression, April 2022
Layout and Cover Design:
The Open Group
Copyright:
© 2022 The Open Group. All rights reserved
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Any use of this publication for commercial purposes is subject to the terms of the Annual Commercial License relating to it. For further information, see www.opengroup.org/legal/licensing.
The TOGAF® Standard, 10th Edition — Content, Capability, and Governance
Document number: C220
Published by The Open Group, April 2022.
Comments relating to the material contained in this document may be submitted to:
The Open Group
Apex Plaza
Reading
Berkshire, RG1 1AX
United Kingdom
or by electronic mail to: [email protected]
Contents
Volume Architecture Content
Chapter 1 Introduction
1.1 Overview
1.2 TOGAF Content Framework and Enterprise Metamodel
1.2.1 Overview
1.2.2 Content Framework
1.2.3 Enterprise Metamodel
1.2.4 The TOGAF Content Framework
1.3 Content Framework and the TOGAF ADM
1.4 The Enterprise Continuum
1.5 The Architecture Repository
Chapter 2 TOGAF Content Framework and Enterprise Metamodel
2.1 Overview
2.2 TOGAF Enterprise Metamodel Vision
2.2.1 Overview of the TOGAF Enterprise Metamodel
2.3 TOGAF Enterprise Metamodel in Detail
2.4 TOGAF Enterprise Metamodel Entities
2.5 TOGAF Enterprise Metamodel Attributes
2.6 TOGAF Enterprise Metamodel Relationships
Chapter 3 Architectural Artifacts
3.1 Basic Concepts
3.1.1 Simple Example of an Architecture Viewpoint and Architecture View
3.2 Developing Architecture Views in the ADM
3.2.1 General Guidelines
3.2.2 Architecture View Creation Process
3.3 Views, Tools, and Languages
3.3.1 Overview
3.4 Architecture Views and Architecture Viewpoints
3.4.1 Example of Architecture Views and Architecture Viewpoints
3.4.2 Architecture Views and Architecture Viewpoints in Enterprise Architecture
3.4.3 Need for a Common Language and Interoperable Tools for Architecture Description
3.5 Conclusions
3.6 Architectural Artifacts by ADM Phase
3.6.1 Preliminary Phase
3.6.2 Phase A: Architecture Vision
3.6.3 Phase B: Business Architecture
3.6.4 Phase C: Data Architecture
3.6.5 Phase C: Application Architecture
3.6.6 Phase D: Technology Architecture
3.6.7 Phase E: Opportunities and Solutions
3.6.8 Requirements Management
Chapter 4 Architecture Deliverables
4.1 Introduction
4.2 Deliverable Descriptions
4.2.1 Architecture Building Blocks
4.2.2 Architecture Contract
4.2.3 Architecture Definition Document
4.2.4 Architecture Principles
4.2.5 Architecture Repository
4.2.6 Architecture Requirements Specification
4.2.7 Architecture Roadmap
4.2.8 Architecture Vision
4.2.9 Business Principles, Business Goals, and Business Drivers
4.2.10 Capability Assessment
4.2.11 Change Request
4.2.12 Communications Plan
4.2.13 Compliance Assessment
4.2.14 Implementation and Migration Plan
4.2.15 Implementation Governance Model
4.2.16 Organizational Model for Enterprise Architecture
4.2.17 Request for Architecture Work
4.2.18 Requirements Impact Assessment
4.2.19 Solution Building Blocks
4.2.20 Statement of Architecture Work
4.2.21 Tailored Architecture Framework
Chapter 5 Building Blocks
5.1 Overview
5.2 Introduction to Building Blocks
5.2.1 Overview
5.2.2 Generic Characteristics
5.2.3 Architecture Building Blocks
5.2.4 Solution Building Blocks
5.3 Building Blocks and the ADM
5.3.1 Basic Principles
5.3.2 Building Block Specification Process in the ADM
Chapter 6 Enterprise Continuum
6.1 Overview
6.2 Enterprise Continuum and Architecture Re-Use
6.3 Constituents of the Enterprise Continuum
6.4 Enterprise Continuum in Detail
6.4.1 Architecture Continuum
6.4.2 Solutions Continuum
6.5 The Enterprise Continuum and the ADM
6.6 The Enterprise Continuum and Your Organization
6.6.1 Relationships
6.6.2 Your Enterprise
Chapter 7 Architecture Repository
7.1 Overview
7.2 Architecture Landscape
7.3 Reference Library
7.3.1 Overview
7.4 Standards Library
7.4.1 Overview
7.4.2 Types of Standard
7.4.3 Standards Lifecycle
7.4.4 Standards Classification within the Standards Library
7.5 Governance Repository
7.5.1 Overview
7.5.2 Contents of the Governance Repository
7.6 The Architecture Requirements Repository
7.6.1 Overview
7.6.2 Contents of the Architecture Requirements Repository
7.7 Solutions Landscape
7.8 The Enterprise Repository
7.9 External Repositories
7.9.1 External Reference Models
7.9.2 External Standards
7.9.3 Architecture Board Approvals
Volume Enterprise Architecture Capability and Governance
Chapter 1 Introduction
Chapter 2 Establishing an Architecture Capability
2.1 Overview
2.2 Phase A: Architecture Vision
2.3 Phase B: Business Architecture
2.4 Phase C: Data Architecture
2.5 Phase C: Application Architecture
2.6 Phase D: Technology Architecture
2.7 Phase E: Opportunities & Solutions
2.8 Phase F: Migration Planning
2.9 Phase G: Implementation Governance
2.10 Phase H: Architecture Change Management
2.11 Requirements Management
Chapter 3 Architecture Governance
3.1 Introduction
3.1.1 Levels of Governance within the Enterprise
3.1.2 Nature of Governance
3.1.3 Technology Governance
3.1.4 IT Governance
3.1.5 Architecture Governance: Overview
3.2 Architecture Governance Framework
3.2.1 Architecture Governance Framework — Conceptual Structure
3.2.2 Architecture Governance Framework — Organizational Structure
3.3 Architecture Governance in Practice
3.3.1 Architecture Governance — Key Success Factors
3.3.2 Elements of an Effective Architecture Governance Strategy
Chapter 4 Architecture Board
4.1 Role
4.2 Responsibilities
4.3 Setting Up the Architecture Board
4.3.1 Triggers
4.3.2 Size of the Board
4.3.3 Board Structure
4.4 Operation of the Architecture Board
4.4.1 General
4.4.2 Preparation
4.4.3 Agenda
Chapter 5 Architecture Contracts
5.1 Role
5.2 Contents
5.2.1 Statement of Architecture Work
5.2.2 Contract between Architecture Design and Development Partners
5.2.3 Contract between Architecting Function and Business Stakeholders
5.3 Relationship to Architecture Governance
Chapter 6 Architecture Compliance
6.1 Introduction
6.2 Terminology: The Meaning of Architecture Compliance
6.3 Architecture Compliance Reviews
6.3.1 Purpose
6.3.2 Timing
6.3.3 Governance and Personnel Scenarios
6.4 Architecture Compliance Review Process
6.4.1 Overview
6.4.2 Roles
6.4.3 Steps
6.5 Architecture Compliance Review Checklists
6.5.1 Hardware and Operating System Checklist
6.5.2 Software Services and Middleware Checklist
6.5.3 Applications Checklists
6.5.4 Information Management Checklists
6.5.5 Security Checklist
6.5.6 System Management Checklist
6.5.7 System Engineering/Overall Architecture Checklists
6.5.8 System Engineering/Methods & Tools Checklist
6.6 Architecture Compliance Review Guidelines
6.6.1 Tailoring the Checklists
6.6.2 Conducting Architecture Compliance Reviews
Index
List of Figures
1-1
Relationships between Deliverables, Artifacts, and Building Blocks
1-2
Example — Architecture Definition Document
1-3
Content Framework by ADM Phase
1-4
Content Framework Overview
2-1
Using the Content Framework to Structure the TOGAF Enterprise Metamodel
2-2
Relationships between Entities in the TOGAF Enterprise Metamodel
3-1
Basic Architectural Concepts
3-2
Example Architecture View — The Open Group Business Domains
3-3
Interactions between Metamodel, Building Blocks, Diagrams, and Stakeholders
3-4
Artifacts Associated with the Enterprise Metamodel
5-1
Key ADM Phases/Steps at which Building Blocks are Evolved/Specified
6-1
Enterprise Continuum
6-2
Architecture Continuum
6-3
Solutions Continuum
6-4
Relationships between Architecture and Solutions Continua
7-1
Overview of Architecture Repository
7-2
Architecture Continuum
3-1
Architecture Governance Framework — Conceptual Structure
3-2
Architecture Governance Framework — Organizational Structure
6-1
Levels of Architecture Conformance
6-2
Architecture Compliance Review Process
Preface
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 870 member organizations, we have a diverse membership that spans all sectors of the technology community — customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.
The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:
■ Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices
■ Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies
■ Offering a comprehensive set of services to enhance the operational efficiency of consortia
■ Developing and operating the industry’s premier certification service and encouraging procurement of certified products
Further information on The Open Group is available at www.opengroup.org.
The Open Group publishes a wide range of technical documentation, most of which is focused on development of Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.
This Document
This document is a compilation of two documents within the TOGAF® Standard:
■ TOGAF Standard — Architecture Content
This document describes the TOGAF Content Framework and a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.
■ TOGAF Standard — Enterprise Architecture Capability and Governance
This document discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise and describes an Enterprise Architecture governance framework.
The TOGAF Standard
The TOGAF Standard is an open, industry consensus framework for Enterprise Architecture.
It is a foundational framework, which means that it is applicable to the development of any kind of architecture in any context. This foundational framework is supplemented by The Open Group TOGAF Library,1 an extensive and growing portfolio of guidance material, providing practical guidance in the application of the TOGAF framework in specific contexts.
The TOGAF Documentation
The TOGAF documentation consists of a set of documents:
■ The TOGAF Standard, which describes the generally applicable approach to Enterprise and IT Architecture
■ The TOGAF Library, a portfolio of additional guidance material, which supports the practical application of the TOGAF approach
Intended Audience
The TOGAF Standard is intended for Enterprise Architects, Business Architects, IT Architects, Data Architects, Systems Architects, Solution Architects, and anyone responsible for the architecture function within an organization.
Acknowledgements
The Open Group is grateful for the contribution of many individuals and organizations in the development of the TOGAF Standard. See the TOGAF Standard — Introduction and Core Concepts for details.
Figure 3-1 is reprinted and adapted from Figure 2 of ISO/IEC/IEEE 42010: 2011, Systems and Software Engineering — Architecture Description, with permission from IEEE®. Copyright© 2011, by IEEE. The IEEE disclaims any responsibility or liability resulting from the placement and use in the described manner.
_____________
1. The TOGAF Library (see www.opengroup.org/togaf-library) is a structured library of resources that support the TOGAF Standard.
Trademarks
ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.
CMMI is a registered trademark of CMMI Institute.
COBIT is a registered trademark of the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute.
Energistics is a registered trademark of Energistics in the United States.
IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc.
ITIL, MSP, and PRINCE2 are registered trademarks of AXELOS Limited.
Object Management Group, OMG, and UML are registered trademarks and BPMN, Business Process Modeling Notation, and Unified Modeling Language are trademarks of the Object Management Group.
PMBOK is a registered trademark of the Project Management Institute, Inc. which is registered in the United States and other nations.
Zachman is a registered trademark of Zachman International, Inc.
The Open Group acknowledges that there may be other company names and products that might be covered by trademark protection and advises the reader to verify them independently.
Referenced Documents
Please refer to the TOGAF Standard — Introduction and Core Concepts: Appendix A for documents referenced in the TOGAF Standard.
The TOGAF Standard
The TOGAF® Standard, 10th Edition — Architecture Content
The Open Group
Chapter 1: Introduction
This chapter provides an introduction to the guidance provided in the TOGAF Standard — Architecture Content (this document).
1.1 Overview
Architects executing the Architecture Development Method (ADM) will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, or project compliance assessments. The Content Framework provides a structural model for architectural content that allows the major work products that an architect creates to be consistently defined, structured, and presented.
The Content Framework provided here is intended to allow the TOGAF framework to be used as a stand-alone framework for architecture within an enterprise. However, other Content Frameworks exist (such as the Zachman® Framework) and it is anticipated that some enterprises may opt to use an external framework in conjunction with the TOGAF framework. In these cases, the TOGAF Content Framework provides a useful reference and starting point for TOGAF content to be mapped to other Content Frameworks.
The Architecture Content Framework uses the following three categories to describe the type of architectural work product within the context of use:
■ A deliverable is a work product that is contractually specified and in turn formally reviewed, approved, and signed off by the stakeholders
Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
■ An artifact is an architectural work product that describes an aspect of the architecture
Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, application interaction matrix, and a value chain diagram. An architectural deliverable may contain many artifacts and artifacts will form the content of the Architecture Repository.
■ A building block represents a potentially re-usable component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions
Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions".
—Architecture Building Blocks (ABBs) typically describe what is required of SBBs at a more logical or supplier-independent level; those requirements may include services to be performed, data resources, and capabilities needed. ABBs include logical business, application, and technology components
—Solution Building Blocks (SBBs) represent physical or supplier-specific components that have the capability to realize part or all of a more logical ABB. There are business, application, and technology SBBs.
The relationships between deliverables, artifacts, and building blocks are shown in Figure 1-1.
Figure 1-1 Relationships between Deliverables, Artifacts, and Building Blocks
For example, an Architecture Definition Document is a deliverable that documents an Architecture Description. This document will contain a number of complementary artifacts that are architecture views of the building blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to describe the target call handling process (a building block). This artifact may also describe other building blocks, such as the actors involved in the process (e.g., a Customer Services Representative). An example of the relationships between deliverables, artifacts, and building blocks is illustrated in Figure 1-2.
Figure 1-2 Example — Architecture Definition Document
1.2 TOGAF Content Framework and Enterprise Metamodel
1.2.1 Overview
The TOGAF ADM provides lifecycle management 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 architecture work products.
An essential task when establishing the enterprise-specific Enterprise Architecture Capability in the Preliminary Phase of the ADM is to define:
■ A categorization framework to be used to structure the Architecture Descriptions, the work products used to express an architecture, and the collection of models that describe the architecture; this is referred to as the Content Framework
■ An understanding of the types of entities within the enterprise and the relationships between them that need to be captured, stored, and analyzed in order to create the Architecture Description; this Enterprise Metamodel depicts this information in the form of a formal model
■ The specific artifacts to be developed (see Chapter 4)
The Content Framework chosen is likely to be influenced by:
■ The Architecture Framework selected as the basis for the Enterprise Architecture Capability
■ The chosen software tool used to support the Enterprise Architecture Capability
1.2.2 Content Framework
The Content Framework defines a categorization framework to be used to structure the Architecture Description, the work product used to express an architecture, and the collection of models that describe the architecture.
The Architecture Repository, which is explained in Section 4.2.5, is structured to store the artifacts and work products identified in the Content Framework. The Content Framework is one element of the Enterprise-Specific Architecture Framework.
1.2.3 Enterprise Metamodel
The TOGAF Standard encourages development of an Enterprise Metamodel, which defines the types of entity to appear in the models that describe the enterprise, together with the relationships between these entities.
An Enterprise Metamodel provides value in several ways:
■ It gives architects a starter set of the types of thing to investigate and to cover in their models
■ It provides a form of completeness-check for any architecture modeling language, or architecture metamodel, that is proposed for use in an enterprise
Namely, how completely does it handle the types of entity in the Enterprise Metamodel, and manage required facts about them such as their attributes and relationships?
■ It can help ensure:
— Consistency
— Completeness
— Traceability
Note that the TOGAF Standard does not aim to constrain an enterprise’s:
■ Selection of artifacts
■ Modeling notation
The TOGAF Standard may use the ArchiMate® modeling language, Business Process Modeling Notation™ (BPMN™), Unified Modeling Language™ (UML®), entity relationship diagramming, flowcharting, or any other notation that can express some TOGAF ideas.
The types of entity within an enterprise and the relationships between them are specific to the individual enterprise. Developing a high-quality metamodel is an important aspect of establishing the Enterprise Architecture Capability.
1.2.4 The TOGAF Content Framework
The TOGAF Content Framework defines a categorization framework to be used to structure the Architecture Description, the work products used to express an architecture, and the collection of models that describe the architecture.
There are many alternative Content Frameworks (e.g., the TOGAF Content Framework, the Zachman Framework, DoDAF, NAF, etc.). Selecting a Content Framework is essential even though the choice of Content Framework is less important. The final Content Framework is usually adapted to fit specific organization needs.
The TOGAF Content Framework is intended to:
■ Provide a detailed model of architectural work products
■ Drive consistency in the outputs created when following the ADM
■ Provide a comprehensive checklist of architecture output that could be created
■ Reduce the risk of gaps within the final architecture deliverable set
■ Help an enterprise mandate standard architecture concepts, terms, and deliverables
At the highest level, the TOGAF Content Framework (see Figure 1-3) is structured in line with the phases of the ADM.
Figure 1-3 Content Framework by ADM Phase
■Architecture Principles, Vision, Motivation, and Requirements models 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 relevant aspects of the business context that have given rise to the Request for Architecture work are typically investigated, refined, validated, and recorded in the Preliminary and Architecture Vision phases.
■Business Architecture captures architecture models of the business, looking specifically at factors that motivate the enterprise, its structure, and its capabilities
■Information Systems Architecture models capture architecture models of IT systems, looking at applications and data in line with the TOGAF ADM phases
■Technology Architecture models capture technology assets that are used to implement and realize information system solutions
■Architecture Realization/Transformation models capture change roadmaps showing transition between architecture states and binding statements that are used to steer and govern an implementation of the architecture
■Architecture Change Management models capture value realization management events, internal and external, that impact the Enterprise Architecture and the generation of requirements for action
Figure 1-4 Content Framework Overview
1.3 Content Framework and the TOGAF ADM
The TOGAF ADM describes the process of moving from a baseline state of the enterprise to a target state of the enterprise. The ADM will address a business need through a process of visioning, architecture definition, transformation planning, and Architecture Governance. At each stage in this process, the ADM requires information as inputs and will create outputs as a result of executing a number of steps. The Content Framework provides an underlying structure for the ADM that defines inputs and outputs in more detail and puts each deliverable into the context of the holistic architecture view of the enterprise.
The Content Framework should therefore be used as a companion to the ADM. The ADM describes what needs to be done to create an architecture and the Content Framework describes what the architecture should look like once it is done.
1.4 The Enterprise Continuum
It is usually impossible to create a single unified architecture that meets all the requirements of all stakeholders for all time. Therefore, the Enterprise Architect will need to deal not just with a single Enterprise Architecture, but with many related Enterprise Architectures.
Each architecture may have a different purpose and architectures may relate to one another. Effectively bounding the scope of an architecture is therefore a Critical Success Factor (CSF) in allowing architects to break down a complex problem space into manageable components that can be individually addressed.
The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.
Chapter 6 discusses the Enterprise Continuum; including the Architecture Continuum and the Solutions Continuum.
1.5 The Architecture Repository
Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these architectural work products require a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.
Chapter 7 provides a structural framework for an Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization.
Chapter 2: TOGAF Content Framework and Enterprise Metamodel
2.1 Overview
The TOGAF 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 Framework and Enterprise Metamodel provided here define 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.
The Content Framework defines a categorization framework to be used to structure the Architecture Description, the work product used to express an architecture, and the collection of models that describe the architecture.
The Enterprise Metamodel defines the types of entities to appear in the models that describe the enterprise, together with the relationships between these entities.
2.2 TOGAF Enterprise Metamodel Vision
The TOGAF Standard includes the TOGAF Enterprise Metamodel which captures the entities and relationships that are likely to be encountered in the majority of enterprises. This may be used as the basis for developing an Organization-Specific Metamodel when establishing the Enterprise Architecture Capability in the Preliminary Phase and also provides the context for the specific artifacts referenced in the descriptions of the ADM phases and described in detail in Chapter 3.
When developing an Organization-Specific Metamodel, architects may choose not to include entities and relationships from the TOGAF Enterprise Metamodel which are not relevant and/or add additional entities and relationships.
This section provides an overview of the TOGAF Enterprise Metamodel. Subsequent sections discuss each area of the metamodel in more detail.
2.2.1 Overview of the TOGAF Enterprise Metamodel
The TOGAF Enterprise Metamodel includes a set of entities, defined in Section 2.4, that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability.
The categorization mechanism of the Content Framework may be used to structure a representation of the TOGAF Enterprise Metamodel, as shown in Figure 2-1.
Figure 2-1 Using the Content Framework to Structure the TOGAF Enterprise Metamodel
2.3 TOGAF Enterprise Metamodel in Detail
The relationships between entities in the TOGAF Enterprise Metamodel are shown in Figure 2-2.
Figure 2-2 Relationships between Entities in the TOGAF Enterprise Metamodel
2.4 TOGAF Enterprise Metamodel Entities
The following table lists and describes the entities within the Enterprise 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 Service
The automated elements of a business service. An application service may deliver or support part or all of one or more business services.
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 Information
Represents a concept and its semantics used within the business.
Business Service
Supports the business by encapsulating a unique element of business behavior; a service offered external to the enterprise may be supported by business services.
Capability
An ability that an organization, person, or system possesses.
Note: This a general-purpose definition. See Business Capability for how this concept is refined for usage in Business Architecture.
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 consumer and a provider that establishes functional and non-functional parameters for interaction. This applies to all types of service interactions within the metamodel.
Control
