Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Van Haren Publishing
- Kategorie: Bildung
- Sprache: Englisch
Summary This document is a compilation of three 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 three documents in this set are:
• The TOGAF Standard — Architecture Development Method
This document describes the TOGAF Architecture Development Method (ADM) — an iterative approach to developing an Enterprise Architecture.
• The TOGAF Standard — ADM Techniques
This document contains a collection of techniques available for use in applying the TOGAF approach and the TOGAF ADM.
• The TOGAF Standard — Applying the ADM
This document contains guidelines for adapting the TOGAF ADM to address the specific style of architecture required in a practical context.
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: 334
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 EditionArchitecture Development Method
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 — Architecture Development Method
Series:
TOGAF Series
A Publication of:
The Open Group
Publisher:
Van Haren Publishing, ’s-Hertogenbosch - NL, www.vanharen.net
ISBN Hardcopy:
978 94 018 0862 0
ISBN eBook:
978 94 018 0863 7
ISBN ePUB:
978 94 018 0864 4
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 — Architecture Development Method
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 Development Method
Chapter 1 Introduction
1.1 ADM Overview
1.1.1 The ADM, Enterprise Continuum, and Architecture Repository
1.1.2 The ADM and the Foundation Architecture
1.1.3 ADM and Supporting Guidelines and Techniques
1.2 Architecture Development Cycle
1.2.1 Key Points
1.2.2 Basic Structure
1.3 Adapting the ADM
1.4 Architecture Governance
1.5 Scoping the Architecture
1.5.1 Breadth
1.5.2 Depth
1.5.3 Time Period
1.5.4 Architecture Domains
1.6 Architecture Alternatives
1.6.1 Method
1.7 Architecture Integration
1.8 Summary
Chapter 2 Preliminary Phase
2.1 Objectives
2.2 Inputs
2.2.1 Reference Materials External to the Enterprise
2.2.2 Non-Architectural Inputs
2.2.3 Architectural Inputs
2.3 Steps
2.3.1 Scope the Enterprise Organizations Impacted
2.3.2 Confirm Governance and Support Frameworks
2.3.3 Define and Establish Enterprise Architecture Team and Organization
2.3.4 Identify and Establish Architecture Principles
2.3.5 Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)
2.3.6 Develop a Strategy and Implementation Plan for Tools and Techniques
2.4 Outputs
2.5 Approach
2.5.1 Enterprise
2.5.2 Organizational Context
2.5.3 Requirements for Architecture Work
2.5.4 Principles
2.5.5 Management Frameworks
2.5.6 Relating the Management Frameworks
2.5.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation
Chapter 3 Phase A: Architecture Vision
3.1 Objectives
3.2 Inputs
3.2.1 Reference Materials External to the Enterprise
3.2.2 Non-Architectural Inputs
3.2.3 Architectural Inputs
3.3 Steps
3.3.1 Establish the Architecture Project
3.3.2 Identify Stakeholders, Concerns, and Business Requirements
3.3.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
3.3.4 Evaluate Capabilities
3.3.5 Assess Readiness for Business Transformation
3.3.6 Define Scope
3.3.7 Confirm and Elaborate Architecture Principles, including Business Principles
3.3.8 Develop Architecture Vision
3.3.9 Define the Target Architecture Value Propositions and KPIs
3.3.10 Identify the Business Transformation Risks and Mitigation Activities
3.3.11 Develop Statement of Architecture Work; Secure Approval
3.4 Outputs
3.5 Approach
3.5.1 General
3.5.2 Creating the Architecture Vision
Chapter 4 Phase B: Business Architecture
4.1 Objectives
4.2 Inputs
4.2.1 Reference Materials External to the Enterprise
4.2.2 Non-Architectural Inputs
4.2.3 Architectural Inputs
4.3 Steps
4.3.1 Select Reference Models, Viewpoints, and Tools
4.3.2 Develop Baseline Business Architecture Description
4.3.3 Develop Target Business Architecture Description
4.3.4 Perform Gap Analysis
4.3.5 Define Candidate Roadmap Components
4.3.6 Resolve Impacts Across the Architecture Landscape
4.3.7 Conduct Formal Stakeholder Review
4.3.8 Finalize the Business Architecture
4.3.9 Create/Update the Architecture Definition Document
4.4 Outputs
4.5 Approach
4.5.1 General
4.5.2 Developing the Baseline Description
4.5.3 Applying Business Capabilities
4.5.4 Applying Value Streams
4.5.5 Applying the Organization Map
4.5.6 Applying Information Maps
4.5.7 Applying Modeling Techniques
4.5.8 Architecture Repository
Chapter 5 Phase C: Information Systems Architectures
5.1 Objectives
5.2 Approach
Chapter 6 Phase C: Information Systems Architectures — Data Architecture
6.1 Objectives
6.2 Inputs
6.2.1 Reference Materials External to the Enterprise
6.2.2 Non-Architectural Inputs
6.2.3 Architectural Inputs
6.3 Steps
6.3.1 Select Reference Models, Viewpoints, and Tools
6.3.2 Develop Baseline Data Architecture Description
6.3.3 Develop Target Data Architecture Description
6.3.4 Perform Gap Analysis
6.3.5 Define Candidate Roadmap Components
6.3.6 Resolve Impacts Across the Architecture Landscape
6.3.7 Conduct Formal Stakeholder Review
6.3.8 Finalize the Data Architecture
6.3.9 Create/Update the Architecture Definition Document
6.4 Outputs
6.5 Approach
6.5.1 Data Structure
6.5.2 Key Considerations for Data Architecture
6.5.3 Architecture Repository
Chapter 7 Phase C: Information Systems Architectures — Application Architecture
7.1 Objectives
7.2 Inputs
7.2.1 Reference Materials External to the Enterprise
7.2.2 Non-Architectural Inputs
7.2.3 Architectural Inputs
7.3 Steps
7.3.1 Select Reference Models, Viewpoints, and Tools
7.3.2 Develop Baseline Application Architecture Description
7.3.3 Develop Target Application Architecture Description
7.3.4 Perform Gap Analysis
7.3.5 Define Candidate Roadmap Components
7.3.6 Resolve Impacts Across the Architecture Landscape
7.3.7 Conduct Formal Stakeholder Review
7.3.8 Finalize the Application Architecture
7.3.9 Create/Update the Architecture Definition Document
7.4 Outputs
7.5 Approach
7.5.1 Architecture Repository
Chapter 8 Phase D: Technology Architecture
8.1 Objectives
8.2 Inputs
8.2.1 Reference Materials External to the Enterprise
8.2.2 Non-Architectural Inputs
8.2.3 Architectural Inputs
8.3 Steps
8.3.1 Select Reference Models, Viewpoints, and Tools
8.3.2 Develop Baseline Technology Architecture Description
8.3.3 Develop Target Technology Architecture Description
8.3.4 Perform Gap Analysis
8.3.5 Define Candidate Roadmap Components
8.3.6 Resolve Impacts Across the Architecture Landscape
8.3.7 Conduct Formal Stakeholder Review
8.3.8 Finalize the Technology Architecture
8.3.9 Create/Update the Architecture Definition Document
8.4 Outputs
8.5 Approach
8.5.1 Emerging Technologies
8.5.2 Architecture Repository
Chapter 9 Phase E: Opportunities & Solutions
9.1 Objectives
9.2 Inputs
9.2.1 Reference Materials External to the Enterprise
9.2.2 Non-Architectural Inputs
9.2.3 Architectural Inputs
9.3 Steps
9.3.1 Determine/Confirm Key Corporate Change Attributes
9.3.2 Determine Business Constraints for Implementation
9.3.3 Review and Consolidate Gap Analysis Results from Phases B to D
9.3.4 Review Consolidated Requirements Across Related Business Functions
9.3.5 Consolidate and Reconcile Interoperability Requirements
9.3.6 Refine and Validate Dependencies
9.3.7 Confirm Readiness and Risk for Business Transformation
9.3.8 Formulate Implementation and Migration Strategy
9.3.9 Identify and Group Major Work Packages
9.3.10 Identify Transition Architectures
9.3.11 Create the Architecture Roadmap & Implementation and Migration Plan
9.4 Outputs
9.5 Approach
Chapter 10 Phase F: Migration Planning
10.1 Objectives
10.2 Inputs
10.2.1 Reference Materials External to the Enterprise
10.2.2 Non-Architectural Inputs
10.2.3 Architectural Inputs
10.3 Steps
10.3.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
10.3.2 Assign a Business Value to Each Work Package
10.3.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
10.3.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
10.3.5 Confirm Architecture Roadmap and Update Architecture Definition Document
10.3.6 Complete the Implementation and Migration Plan
10.3.7 Complete the Architecture Development Cycle and Document Lessons Learned
10.4 Outputs
10.5 Approach
Chapter 11 Phase G: Implementation Governance
11.1 Objectives
11.2 Inputs
11.2.1 Reference Materials External to the Enterprise
11.2.2 Non-Architectural Inputs
11.2.3 Architectural Inputs
11.3 Steps
11.3.1 Confirm Scope and Priorities for Deployment with Development Management
11.3.2 Identify Deployment Resources and Skills
11.3.3 Guide Development of Solutions Deployment
11.3.4 Perform Enterprise Architecture Compliance Reviews
11.3.5 Implement Business and IT Operations
11.3.6 Perform Post-Implementation Review and Close the Implementation
11.4 Outputs
11.5 Approach
Chapter 12 Phase H: Architecture Change Management
12.1 Objectives
12.2 Inputs
12.2.1 Reference Materials External to the Enterprise
12.2.2 Non-Architectural Inputs
12.2.3 Architectural Inputs
12.3 Steps
12.3.1 Establish Value Realization Process
12.3.2 Deploy Monitoring Tools
12.3.3 Manage Risks
12.3.4 Provide Analysis for Architecture Change Management
12.3.5 Develop Change Requirements to Meet Performance Targets
12.3.6 Manage Governance Process
12.3.7 Activate the Process to Implement Change
12.4 Outputs
12.5 Approach
12.5.1 Drivers for Change
12.5.2 Enterprise Architecture Change Management Process
12.5.3 Guidelines for Maintenance versus Architecture Redesign
Chapter 13 ADM Architecture Requirements Management
13.1 Objectives
13.2 Inputs
13.3 Steps
13.4 Outputs
13.5 Approach
13.5.1 General
13.5.2 Requirements Development
13.5.3 Resources
Volume ADM Techniques
Chapter 1 Introduction
Chapter 2 Architecture Principles
2.1 Introduction
2.2 Characteristics of Architecture Principles
2.3 Components of Architecture Principles
2.4 Developing Architecture Principles
2.4.1 Qualities of Principles
2.5 Applying Architecture Principles
2.6 Example Set of Architecture Principles
2.6.1 Business Principles
2.6.2 Data Principles
2.6.3 Application Principles
2.6.4 Technology Principles
Chapter 3 Stakeholder Management
3.1 Introduction
3.2 Approach to Stakeholder Management
3.3 Steps in the Stakeholder Management Process
3.3.1 Identify Stakeholders
3.3.2 Classify Stakeholder Positions
3.3.3 Determine Stakeholder Management Approach
3.3.4 Tailor Engagement Deliverables
3.4 Template Stakeholder Map
Chapter 4 Architecture Patterns
4.1 Introduction
4.1.1 Background
4.1.2 Content of a Pattern
4.1.3 Terminology
4.2 Some Pattern Resources
Chapter 5 Gap Analysis
5.1 Introduction
5.2 Suggested Steps
5.3 Example
Chapter 6 Migration Planning Techniques
6.1 Implementation Factor Catalog
6.2 Consolidated Gaps, Solutions, & Dependencies Matrix
6.3 Architecture Definition Increments Table
6.4 Transition Architecture State Evolution Table
6.5 Business Value Assessment Technique
Chapter 7 Interoperability Requirements
7.1 Overview
7.2 Defining Interoperability
7.3 Enterprise Operating Model
7.4 Refining Interoperability
7.5 Determining Interoperability Requirements
7.6 Reconciling Interoperability Requirements with Potential Solutions
Chapter 8 Business Transformation Readiness Assessment
8.1 Introduction
8.1.1 Business Transformation Enablement Program (BTEP)
8.2 Determine Readiness Factors
8.3 Present Readiness Factors
8.4 Assess Readiness Factors
8.4.1 Readiness Factor Vision
8.4.2 Readiness Factor Rating
8.4.3 Readiness Factor Risks & Actions
8.5 Readiness and Migration Planning
8.6 Marketing the Implementation Plan
8.7 Conclusion
Chapter 9 Risk Management
9.1 Introduction
9.2 Risk Classification
9.3 Risk Identification
9.4 Initial Risk Assessment
9.5 Risk Mitigation and Residual Risk Assessment
9.6 Conduct Residual Risk Assessment
9.7 Risk Monitoring and Governance (Phase G)
9.8 Summary
Chapter 10 Architecture Alternatives and Trade-Offs
10.1 Concept
10.2 Method
10.2.1 Criteria
10.2.2 Identify Alternatives
10.2.3 Choose from Alternatives and Define in Detail
Volume Applying the ADM
Chapter 1 Introduction
1.1 Using the TOGAF Framework with Different Architecture Styles
Chapter 2 Applying Iteration to the ADM
2.1 Overview
2.2 Iteration Cycles
2.3 Classes of Architecture Engagement
2.4 Approaches to Architecture Development
2.5 Iteration Considerations
2.5.1 Iteration between ADM Cycles
2.5.2 Iteration within an ADM Cycle
2.6 Conclusions
Chapter 3 Applying the ADM Across the Architecture Landscape
3.1 Overview
3.2 Architecture Landscape
3.3 Developing Architectures at Different Levels
3.4 Organizing the Architecture Landscape to Understand the State of the Enterprise
Chapter 4 Architecture Partitioning
4.1 Overview
4.2 Applying Classification to Create Partitioned Architectures
4.2.1 Activities within the Preliminary Phase
4.3 Integration
Index
List of Figures
1-1 Architecture Development Cycle
1-2 Architecture Alternatives Method
1-3 Integration of Architecture Artifacts
2-1 Preliminary Phase
2-2 Management Frameworks to Co-ordinate with the TOGAF Framework
2-3 Interoperability and Relationships between Management Frameworks
3-1 Phase A: Architecture Vision
4-1 Phase B: Business Architecture
4-2 UML Business Class Diagram
5-1 Phase C: Information Systems Architectures
8-1 Phase D: Technology Architecture
9-1 Phase E: Opportunities & Solutions
10-1 Phase F: Migration Planning
11-1 Phase G: Implementation Governance
12-1 Phase H: Architecture Change Management
13-1 ADM Architecture Requirements Management
3-1 Sample Stakeholders and Categories
3-2 Stakeholder Power Grid
5-1 Gap Analysis Example
6-1 Implementation Factor Catalog
6-2 Consolidated Gaps, Solutions, and Dependencies Matrix
6-3 Architecture Definition Increments Table
6-4 Transition Architecture State Evolution Table
6-5 Sample Project Assessment with Respect to Business Value and Risk
7-1 Business Information Interoperability Matrix
7-2 Information Systems Interoperability Matrix
8-1 Business Transformation Readiness Assessment — Maturity Model
8-2 Summary Table of Business Transformation Readiness Assessment
9-1 Risk Classification Scheme
9-2 Sample Risk Identification and Mitigation Assessment Worksheet
10-1 Architecture Trade-Off Method
2-1 Iteration Cycles
2-2 Classes of Enterprise Architecture Engagement
2-3 A Hierarchy of ADM Processes Example
2-4 Activity by Iteration for Baseline First Architecture Definition
2-5 Activity by Iteration for Target First Architecture Definition
3-1 Summary Classification Model for Architecture Landscapes
3-2 Summary of Architecture Continuum
4-1 Allocation of Teams to Architecture Scope
4-2 Architecture Content Aggregation
List of Tables
2-1 Recommended Format for Defining Principles
3-1 Example Stakeholder Analysis
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 three documents within the TOGAF® Standard:
■ The TOGAF Standard — Architecture Development Method
This document describes the TOGAF Architecture Development Method (ADM) — an iterative approach to developing an Enterprise Architecture.
■ The TOGAF Standard — ADM Techniques
This document contains a collection of techniques available for use in applying the TOGAF approach and the TOGAF ADM.
■ The TOGAF Standard — Applying the ADM
This document contains guidelines for adapting the TOGAF ADM to address the specific style of architecture required in a practical context.
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.
_______
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.
COBIT is a registered trademark of the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute.
FICO is a registered trademark of Fair Isaac Corporation in the United States and other countries.
ITIL and PRINCE2 are registered trademarks of AXELOS Limited.
Java is a registered trademark of Oracle and/or its affiliates.
MDA, Model-Driven Architecture, 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 Development Method
The Open Group
Chapter 1: Introduction
This chapter introduces the Architecture Development Method (ADM) cycle, adapting the ADM, architecture scope, and architecture integration.
1.1 ADM Overview
The TOGAF ADM describes a method for developing and managing the lifecycle of an Enterprise Architecture, and forms the core of the TOGAF Standard.
It integrates elements of the TOGAF Standard, as well as other available architectural assets, to meet the business needs of an organization.
1.1.1 The ADM, Enterprise Continuum, and Architecture Repository
The Enterprise Continuum provides a framework and context to support the leverage of relevant architecture assets in executing the ADM. These assets may include Architecture Descriptions, models, and patterns taken from a variety of sources, as explained in the TOGAF Standard — Architecture Content.
The Enterprise Continuum categorizes architectural source material — both the contents of the organization’s own enterprise repositories and the set of relevant, available reference models and standards in the industry.
The practical implementation of the Enterprise Continuum will typically take the form of an Architecture Repository (see the TOGAF Standard — Architecture Content) that includes reference architectures, models, and patterns that have been accepted for use within the enterprise, and actual architectural work done previously within the enterprise. The architect would seek to re-use as much as possible from the Architecture Repository that was relevant to the project in hand. (In addition to the collection of architecture source material, the repository would also contain architecture development work-in-progress.)
At relevant places throughout the ADM there are reminders to consider which, if any, architecture assets from the Architecture Repository the architect should use. In some cases — for example, in the development of a Technology Architecture — this may be the TOGAF Foundation Architecture. In other cases — for example, in the development of a Business Architecture — it may be a reference model for e-Commerce taken from the industry at large.
The criteria for including source materials in an organization’s Architecture Repository will typically form part of the Enterprise Architecture Governance process. These governance processes should consider available resources both within and outside the enterprise in order to determine when general resources can be adapted for specific enterprise needs and also to determine where specific solutions can be generalized to support wider re-use.
While using the ADM, the architect is developing a snapshot of the enterprise’s decisions and their implications at particular points in time. Each iteration of the ADM will populate an organization-specific landscape with all the architecture assets identified and leveraged through the process, including the final organization-specific architecture delivered.
Architecture development is a continuous, cyclical process, and in executing the ADM repeatedly over time, the architect gradually adds more and more content to the organization’s Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise’s own Architecture Repository with relevant re-usable building blocks taken from the "left", more generic side of the Enterprise Continuum.
In fact, the first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources such as the TOGAF Standard, as well as the IT industry at large, that could be leveraged in support of the effort.
Subsequent executions will be easier as more and more architecture assets become identified, are used to populate the organization’s Architecture Repository, and are thus available for future re-use.
1.1.2 The ADM and the Foundation Architecture
The ADM is also useful to populate the Foundation Architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture. This could be a set of re-usable common models, policy and governance definitions, or even as specific as overriding technology selections (e.g., if mandated by law). Population of the Foundation Architecture follows similar principles as for an Enterprise Architecture, with the difference that requirements for a whole enterprise are restricted to the overall concerns and thus less complete than for a specific enterprise.
It is important to recognize that existing models from these various sources, when integrated, may not necessarily result in a coherent Enterprise Architecture. "Integratability" of Architecture Descriptions is considered in Section 1.7.
1.1.3 ADM and Supporting Guidelines and Techniques
The application of the TOGAF ADM is supported by an extended set of resources — guidelines, templates, checklists, and other detailed materials. These are included in:
■ The TOGAF Standard — ADM Techniques
■ TOGAF Series Guides — the Guidance part of the Standard (guidance material on how to use and adapt the TOGAF Standard for specific needs)
■ White Papers and Guides published by The Open Group, classified and referenced in the TOGAF Library (see www.opengroup.org/togaf-library)
The individual guidelines and techniques are described separately so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text clutter the description of the ADM itself.
1.2Architecture Development Cycle
1.2.1 Key Points
The following are the key points about the ADM:
■ The ADM is iterative, over the whole process, between phases, and within phases (see the TOGAF Standard — ADM Techniques)
For each iteration of the ADM, a fresh decision must be taken as to:
— The breadth of coverage of the enterprise to be defined
— The level of detail to be defined
— The extent of the time period aimed at, including the number and extent of any intermediate time periods
— The architectural assets to be leveraged, including:
— Assets created in previous iterations of the ADM cycle within the enterprise
— Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)
■ These decisions should be based on a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work
■ As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types
As such, it may be, but does not necessarily have to be, tailored to specific needs. For example, it may be used in conjunction with the set of deliverables of another framework, where these have been deemed to be more appropriate for a specific organization. (For example, many US Federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs.)
These issues are considered in detail in Section 1.3.
1.2.2 Basic Structure
The basic structure of the ADM is shown in Figure 1-1.
Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.
Figure 1-1 Architecture Development Cycle
The phases of the ADM cycle are further divided into steps, which are defined in the detailed description of each phase.
The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases. An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.
The phases of the cycle are described in detail in the following chapters.
Note that output is generated throughout the process, and that the output from an early phase may be modified in a later phase. In the ADM, the status of outputs at each stage is defined. The lifecycle of outputs must be managed through a version numbering policy, adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.
In the ADM, documents which are under development and have not undergone any formal review and approval process are designated "draft". Documents which have been reviewed and approved are designated "approved" in accordance with the organization’s governance practices. Approved does not necessarily mean finalized. Documents may evolve during subsequent phases but may only be changed through an appropriate change control and governance process. This is used in particular within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions.
1.3 Adapting the ADM
The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an "enterprise-specific" ADM.
One reason for wanting to adapt the ADM, which it is important to stress, is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise. For example, if the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work. In other cases a slightly different order may be preferred; for example, a detailed inventory of the baseline environment may be done before undertaking the Business Architecture.
The order of phases may also be defined by the Architecture Principles and business principles of an enterprise. For example, the business principles may dictate that the enterprise be prepared to adjust its business processes to meet the needs of a packaged solution, so that it can be implemented quickly to enable a fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow completion of the Information Systems Architecture or the Technology Architecture.
Another reason for wanting to adapt the ADM is if the TOGAF framework is to be integrated with another enterprise framework (as explained in the TOGAF Standard — Introduction and Core Concepts). For example, an enterprise may wish to use the TOGAF framework and its generic ADM in conjunction with the Zachman® Framework, or another Enterprise Architecture framework that has a defined set of deliverables specific to a particular vertical sector: Government, Defense, e-Business, Telecommunications, etc. The ADM has been specifically designed with this potential integration in mind.
Other possible reasons for wanting to adapt the ADM include:
■ The ADM is one of the many corporate processes that make up the corporate governance model
It is complementary to, and supportive of, other standard program management processes, such as those for authorization, risk management, business planning and budgeting, development planning, systems development, and procurement.
■The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation, and needs to be tailored to achieve a suitable compromise between the contractor’s existing practices and the contracting enterprise’s requirements
■ The enterprise is a small-to-medium enterprise, and wishes to use a "cut-down" method more attuned to the reduced level of resources and system complexity typical of such an environment
■ The enterprise is very large and complex, comprising many separate but interlinked "enterprises" within an overall collaborative business framework, and the architecture method needs to be adapted to recognize this
Different approaches to planning and integration may be used in such cases, including the following (possibly in combination):
— Top-down planning and development — designing the whole interconnected meta-enterprise as a single entity (an exercise that typically stretches the limits of practicality)
— Development of a "generic" or "reference" architecture, typical of the enterprises within the organization, but not representing any specific enterprise, which individual enterprises are then expected to adapt in order to produce an architecture "instance" suited to the particular enterprise concerned
— Replication — developing a specific architecture for one enterprise, implementing it as a proof-of-concept, and then taking that as a "reference architecture" to be cloned in other enterprises
■ In a vendor or production environment, a generic architecture for a family of related products is often referred to as a "Product Line Architecture", and the analogous process to that outlined above is termed "(Architecture-based) Product Line Engineering". The ADM is targeted primarily at architects in IT user enterprises, but a vendor organization whose products are IT-based might well wish to adapt it as a generic method for a Product Line Architecture development.
The descriptions of the phases of the ADM contain lists of deliverables and artifacts that could be applicable to any enterprise. It is important to adapt deliverables and artifacts to reflect the specific needs of the enterprise for the required architecture.
Adapting the Content Framework and Enterprise Metamodel, which defines the organization-specific deliverables and artifacts, together with detailed descriptions of the specific deliverables and artifacts referenced in the ADM phase descriptions may be found in the TOGAF Standard — Architecture Content.
The ADM can also be adapted to support an Agile Enterprise Architecture delivery style as well as to enable enterprise agility. Detailed guidance on how to adapt the ADM may be found in the following documents:
■ TOGAF® Series Guide: Enabling Enterprise Agility
■ TOGAF® Series Guide: Applying the ADM Using Agile Sprints
Additional guidance on adapting the ADM process may be found in the TOGAF Standard — Applying the ADM, and also in the TOGAF® Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM.
1.4Architecture Governance
The ADM, whether adapted by the organization or used as documented here, is a key process to be managed in the same manner as other architecture artifacts classified through the Enterprise Continuum and held in the Architecture Repository. The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.
The management of all architectural artifacts, governance, and related processes should be supported by a controlled environment. Typically, this would be based on one or more repositories supporting versioned objects, process control, and status.
The major information areas managed by a governance repository should contain the following types of information:
■Reference Data (collateral from the organization’s own repositories/Enterprise Continuum, including external data; e.g., COBIT®, the IT4IT Reference Architecture): used for guidance and instruction during project implementation
This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves.
■Process Status: all information regarding the state of any governance processes will be managed
Examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations.
■Audit Information: this will record all completed governance process actions and will be used to support:
— Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process
— A reference for future architectural and supporting process developments, guidance, and precedence
The governance artifacts and process are themselves part of the contents of the Architecture Repository.
Architecture Governance is addressed in detail in the TOGAF Standard — Enterprise Architecture Capability and Governance.
1.5 Scoping the Architecture
There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:
■ The organizational authority of the team producing the architecture
■ The objectives and stakeholder concerns to be addressed within the architecture
■ The availability of people, finance, and other resources
The scope chosen for the architecture activity should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned "architecture partitions" that ensure architects are not working on duplicate or conflicting activities. It also requires the definition of re-use and compliance relationships between architecture partitions.
The division of the enterprise and its architecture-related activity is discussed in more detail in the TOGAF Standard — Applying the ADM.
Four dimensions are typically used in order to define and limit the scope of an architecture:
■Breadth: what is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?
— Many enterprises are very large, effectively comprising a federation of organizational units that could validly be considered enterprises in their own right
— The modern enterprise increasingly extends beyond its traditional boundaries, to embrace a fuzzy combination of traditional business enterprise combined with suppliers, customers, and partners
■Depth: to what level of detail should the architecting effort go?
How much architecture is "enough"? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)?
■Time Period: what is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed Architecture Description?
If not, how many Transition Architectures are to be defined, and what are their time periods?
■Architecture Domains: a complete Enterprise Architecture Description should contain all four architecture domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise
Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed. Techniques for using the ADM to develop a number of related architectures are discussed in the TOGAF Standard — Applying the ADM.
The four dimensions of architecture scope are explored in detail below. In each case, particularly in large-scale environments where architectures are necessarily developed in a federated manner, there is a danger of architects optimizing within their own scope of activity, instead of at the level of the overall enterprise. It is often necessary to sub-optimize in a particular area, in order to optimize at the enterprise level. The aim should always be to seek the highest level of commonality and focus on scalable and re-usable modules in order to maximize re-use at the enterprise level.
1.5.1Breadth
One of the key decisions is the focus of the architecture effort, in terms of the breadth of overall enterprise activity to be covered (which specific business sectors, functions, organizations, geographical areas, etc.).
It is often necessary to have a number of different architectures existing across an enterprise, focused on particular timeframes, business functions, or business requirements.
For large complex enterprises, federated architectures — independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework — are typical. Such a framework specifies the principles for interoperability, migration, and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects. More details and guidance on specifying the interoperability requirements for different solutions can be found in the TOGAF Standard — ADM Techniques.
The feasibility of a single enterprise-wide architecture for every business function or purpose may be rejected as too complex and unwieldy. In these circumstances it is suggested that a number of different Enterprise Architectures exist across an enterprise. These Enterprise Architectures focus on particular timeframes, business segments or functions, and specific organizational requirements. In such a case we need to create the overarching Enterprise Architecture as a "federation" of these Enterprise Architectures. An effective way of managing and exploiting these Enterprise Architectures is to adopt a publish-and-subscribe model that allows architecture to be brought under a governance framework. In such a model, architecture developers and architecture consumers in projects (the supply and demand sides of architecture work) sign up to a mutually beneficial framework of governance that ensures that:
■ Architectural material is of good quality, up-to-date, fit-for-purpose, and published (reviewed and agreed to be made public)
■ Usage of architecture material can be monitored, and compliance with standards, models, and principles can be exhibited, via:
— A Compliance Assessment process that describes what the user is subscribing to, and assesses their level of compliance
— A dispensation process that may grant dispensations from adherence to architecture standards and guidelines in specific cases (usually with a strong business imperative)
Publish and subscribe techniques are being developed as part of general IT governance and specifically for the Defense sphere.
1.5.2 Depth
Care should be taken to judge the appropriate level of detail to be captured, based on the intended use of the Enterprise Architecture and the decisions to be made based on it. It is important that a consistent and equal level of depth be completed in each architecture domain (Business, Data, Application, Technology) included in the architecture effort. If pertinent detail is omitted, the architecture may not be useful. If unnecessary detail is included, the architecture effort may exceed the time and resources available, and/or the resultant architecture may be confusing or cluttered. Developing architectures at different levels of detail within an enterprise is discussed in more detail in the TOGAF Standard — Applying the ADM.
It is also important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or reuse. The depth and detail of the Enterprise Architecture needs to be sufficient for its purpose, and no more.
Iterations of the ADM will build on the artifacts and the capabilities created during previous iterations.
There is a need to document all the models in an enterprise, to the level of detail appropriate to the need of the current ADM cycle. The key is to understand the status of the enterprise’s architecture work, and what can realistically be achieved with the resources and competencies available, and then focus on identifying and delivering the value that is achievable. Stakeholder value is a key focus: too broad a scope may deter some stakeholders (no return on investment).
1.5.3 Time Period
The ADM is described in terms of a single cycle of Architecture Vision, and a set of Target Architectures (Business, Data, Application, Technology) that enable the implementation of the vision.
