The TOGAF® Standard, Version 9.2 E-Book

The Open Group

• Herausgeber: Van Haren Publishing
• Kategorie: Bildung
• Sprache: Englisch

Seitenzahl: 683

Veröffentlichungsjahr: 2018

Beschreibung

The TOGAF standard is a framework - a detailed method and a set of supporting tools - for developing an Enterprise Architecture, developed by members of The Open Group Architecture Forum. The TOGAF Standard, Version 9.2 is an update providing additional guidance, correcting errors, introducing structural changes to support the TOGAF Library (an extensive collection of reference material), and removing obsolete content. It may be used freely by any organization wishing to develop an Enterprise Architecture for use within that organization (subject to the Conditions of Use). This Book is divided into six parts: • Part I - Introduction This part provides a high-level introduction to the key concepts of Enterprise Architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout the standard. • Part II - Architecture Development Method This is the core of the TOGAF framework. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an Enterprise Architecture. • Part III - ADM Guidelines & Techniques This part contains a collection of guidelines and techniques available for use in applying the TOGAF framework and the TOGAF ADM. Additional guidelines and techniques are also in the TOGAF Library (available online from The Open Group). • Part IV - Architecture Content Framework This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables. • Part V - Enterprise Continuum & Tools This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise. • Part VI Architecture Capability Framework This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.

Leseprobe

The Open Group Standard

The TOGAF® Standard, Version 9.2

The Open Group

Copyright © 2005-2018, 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 owners.

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 Open Group Standard

The TOGAF® Standard, Version 9.2

ISBN: 1-947754-11-9Document Number: C182

Published in the U.S. by The Open Group, 2005-2018.

Any comments relating to the material contained in this document may be submitted by email to: [email protected]

Contents

Part

I

Introduction

Chapter

1

Introduction

1.1

Structure of this Document

1.2

Structure of the TOGAF Library

1.3

Executive Overview

1.4

Information on Using the TOGAF Standard

1.4.1

Conditions of Use

1.4.2

How Much Does the TOGAF Standard Cost?

1.4.3

Downloads

1.5

Why Join The Open Group?

Chapter

2

Core Concepts

2.1

What is the TOGAF Standard?

2.2

What is Architecture in the Context of the TOGAF Standard?

2.3

What Kind of Architecture Does the TOGAF Standard Deal With?

2.4

Architecture Development Method

2.5

Deliverables, Artifacts, and Building Blocks

2.6

Enterprise Continuum

2.7

Architecture Repository

2.8

Establishing and Maintaining an Enterprise Architecture Capability

2.9

Establishing the Architecture Capability as an Operational Entity

2.10

Using the TOGAF Standard with Other Frameworks

Chapter

3

Definitions

Part

II

Architecture Development Method (ADM)

Chapter

4

Introduction to Part II

4.1

ADM Overview

4.1.1

The ADM, Enterprise Continuum, and Architecture Repository

4.1.2

The ADM and the Foundation Architecture

4.1.3

ADM and Supporting Guidelines and Techniques

4.2

Architecture Development Cycle

4.2.1

Key Points

4.2.2

Basic Structure

4.3

Adapting the ADM

4.4

Architecture Governance

4.5

Scoping the Architecture

4.5.1

Breadth

4.5.2

Depth

4.5.3

Time Period

4.5.4

Architecture Domains

4.6

Architecture Integration

4.7

Summary

Chapter

5

Preliminary Phase

5.1

Objectives

5.2

Inputs

5.2.1

Reference Materials External to the Enterprise

5.2.2

Non-Architectural Inputs

5.2.3

Architectural Inputs

5.3

Steps

5.3.1

Scope the Enterprise Organizations Impacted

5.3.2

Confirm Governance and Support Frameworks

5.3.3

Define and Establish Enterprise Architecture Team and Organization

5.3.4

Identify and Establish Architecture Principles

5.3.5

Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)

5.3.6

Develop a Strategy and Implementation Plan for Tools and Techniques

5.4

Outputs

5.5

Approach

5.5.1

Enterprise

5.5.2

Organizational Context

5.5.3

Requirements for Architecture Work

5.5.4

Principles

5.5.5

Management Frameworks

5.5.6

Relating the Management Frameworks

5.5.7

Planning for Enterprise Architecture/Business Change Maturity Evaluation

Chapter

6

Phase A: Architecture Vision

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

Establish the Architecture Project

6.3.2

Identify Stakeholders, Concerns, and Business Requirements

6.3.3

Confirm and Elaborate Business Goals, Business Drivers, and Constraints

6.3.4

Evaluate Capabilities

6.3.5

Assess Readiness for Business Transformation

6.3.6

Define Scope

6.3.7

Confirm and Elaborate Architecture Principles, including Business Principles

6.3.8

Develop Architecture Vision

6.3.9

Define the Target Architecture Value Propositions and KPIs

6.3.10

Identify the Business Transformation Risks and Mitigation Activities

6.3.11

Develop Statement of Architecture Work; Secure Approval

6.4

Outputs

6.5

Approach

6.5.1

General

6.5.2

Creating the Architecture Vision

Chapter

7

Phase B: Business 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 Business Architecture Description

7.3.3

Develop Target Business 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 Business Architecture

7.3.9

Create the Architecture Definition Document

7.4

Outputs

7.5

Approach

7.5.1

General

7.5.2

Developing the Baseline Description

7.5.3

Applying Business Capabilities

7.5.4

Applying Value Streams

7.5.5

Applying the Organization Map

7.5.6

Applying Modeling Techniques

7.5.7

Architecture Repository

Chapter

8

Phase C: Information Systems Architectures

8.1

Objectives

8.2

Approach

Chapter

9

Phase C: Information Systems Architectures — Data Architecture

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

Select Reference Models, Viewpoints, and Tools

9.3.2

Develop Baseline Data Architecture Description

9.3.3

Develop Target Data Architecture Description

9.3.4

Perform Gap Analysis

9.3.5

Define Candidate Roadmap Components

9.3.6

Resolve Impacts Across the Architecture Landscape

9.3.7

Conduct Formal Stakeholder Review

9.3.8

Finalize the Data Architecture

9.3.9

Create the Architecture Definition Document

9.4

Outputs

9.5

Approach

9.5.1

Key Considerations for Data Architecture

9.5.2

Architecture Repository

Chapter

10

Phase C: Information Systems Architectures — Application Architecture

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

Select Reference Models, Viewpoints, and Tools

10.3.2

Develop Baseline Application Architecture Description

10.3.3

Develop Target Application Architecture Description

10.3.4

Perform Gap Analysis

10.3.5

Define Candidate Roadmap Components

10.3.6

Resolve Impacts Across the Architecture Landscape

10.3.7

Conduct Formal Stakeholder Review

10.3.8

Finalize the Application Architecture

10.3.9

Create the Architecture Definition Document

10.4

Outputs

10.5

Approach

10.5.1

Architecture Repository

Chapter

11

Phase D: Technology Architecture

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

Select Reference Models, Viewpoints, and Tools

11.3.2

Develop Baseline Technology Architecture Description

11.3.3

Develop Target Technology Architecture Description

11.3.4

Perform Gap Analysis

11.3.5

Define Candidate Roadmap Components

11.3.6

Resolve Impacts Across the Architecture Landscape

11.3.7

Conduct Formal Stakeholder Review

11.3.8

Finalize the Technology Architecture

11.3.9

Create the Architecture Definition Document

11.4

Outputs

11.5

Approach

11.5.1

Emerging Technologies

11.5.2

Architecture Repository

Chapter

12

Phase E: Opportunities & Solutions

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

Determine/Confirm Key Corporate Change Attributes

12.3.2

Determine Business Constraints for Implementation

12.3.3

Review and Consolidate Gap Analysis Results from Phases B to D

12.3.4

Review Consolidated Requirements Across Related Business Functions

12.3.5

Consolidate and Reconcile Interoperability Requirements

12.3.6

Refine and Validate Dependencies

12.3.7

Confirm Readiness and Risk for Business Transformation

12.3.8

Formulate Implementation and Migration Strategy

12.3.9

Identify and Group Major Work Packages

12.3.10

Identify Transition Architectures

12.3.11

Create the Architecture Roadmap & Implementation and Migration Plan

12.4

Outputs

12.5

Approach

Chapter

13

Phase F: Migration Planning

13.1

Objectives

13.2

Inputs

13.2.1

Reference Materials External to the Enterprise

13.2.2

Non-Architectural Inputs

13.2.3

Architectural Inputs

13.3

Steps

13.3.1

Confirm Management Framework Interactions for the Implementation and Migration Plan

13.3.2

Assign a Business Value to Each Work Package

13.3.3

Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle

13.3.4

Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

13.3.5

Confirm Architecture Roadmap and Update Architecture Definition Document

13.3.6

Complete the Implementation and Migration Plan

13.3.7

Complete the Architecture Development Cycle and Document Lessons Learned

13.4

Outputs

13.5

Approach

Chapter

14

Phase G: Implementation Governance

14.1

Objectives

14.2

Inputs

14.2.1

Reference Materials External to the Enterprise

14.2.2

Non-Architectural Inputs

14.2.3

Architectural Inputs

14.3

Steps

14.3.1

Confirm Scope and Priorities for Deployment with Development Management

14.3.2

Identify Deployment Resources and Skills

14.3.3

Guide Development of Solutions Deployment

14.3.4

Perform Enterprise Architecture Compliance Reviews

14.3.5

Implement Business and IT Operations

14.3.6

Perform Post-Implementation Review and Close the Implementation

14.4

Outputs

14.5

Approach

Chapter

15

Phase H: Architecture Change Management

15.1

Objectives

15.2

Inputs

15.2.1

Reference Materials External to the Enterprise

15.2.2

Non-Architectural Inputs

15.2.3

Architectural Inputs

15.3

Steps

15.3.1

Establish Value Realization Process

15.3.2

Deploy Monitoring Tools

15.3.3

Manage Risks

15.3.4

Provide Analysis for Architecture Change Management

15.3.5

Develop Change Requirements to Meet Performance Targets

15.3.6

Manage Governance Process

15.3.7

Activate the Process to Implement Change

15.4

Outputs

15.5

Approach

15.5.1

Drivers for Change

15.5.2

Enterprise Architecture Change Management Process

15.5.3

Guidelines for Maintenance versus Architecture Redesign

Chapter

16

ADM Architecture Requirements Management

16.1

Objectives

16.2

Inputs

16.3

Steps

16.4

Outputs

16.5

Approach

16.5.1

General

16.5.2

Requirements Development

16.5.3

Resources

Part

III

ADM Guidelines and Techniques

Chapter

17

Introduction to Part III

17.1

Guidelines for Adapting the ADM Process

17.2

Techniques for Architecture Development

17.3

Using the TOGAF Framework with Different Architectural Styles

Chapter

18

Applying Iteration to the ADM

18.1

Overview

18.2

Iteration Cycles

18.3

Classes of Architecture Engagement

18.4

Approaches to Architecture Development

18.5

Iteration Considerations

18.5.1

Iteration between ADM Cycles

18.5.2

Iteration within an ADM Cycle

18.6

Conclusions

Chapter

19

Applying the ADM Across the Architecture Landscape

19.1

Overview

19.2

Architecture Landscape

19.3

Organizing the Architecture Landscape to Understand the State of the Enterprise

19.4

Developing Architectures at Different Levels

Chapter

20

Architecture Principles

20.1

Introduction

20.2

Characteristics of Architecture Principles

20.3

Components of Architecture Principles

20.4

Developing Architecture Principles

20.4.1

Qualities of Principles

20.5

Applying Architecture Principles

20.6

Example Set of Architecture Principles

20.6.1

Business Principles

20.6.2

Data Principles

20.6.3

Application Principles

20.6.4

Technology Principles

Chapter

21

Stakeholder Management

21.1

Introduction

21.2

Approach to Stakeholder Management

21.3

Steps in the Stakeholder Management Process

21.3.1

Identify Stakeholders

21.3.2

Classify Stakeholder Positions

21.3.3

Determine Stakeholder Management Approach

21.3.4

Tailor Engagement Deliverables

21.4

Template Stakeholder Map

Chapter

22

Architecture Patterns

22.1

Introduction

22.1.1

Background

22.1.2

Content of a Pattern

22.1.3

Terminology

22.2

Some Pattern Resources

Chapter

23

Gap Analysis

23.1

Introduction

23.2

Suggested Steps

23.3

Example

Chapter

24

Migration Planning Techniques

24.1

Implementation Factor Assessment & Deduction Matrix

24.2

Consolidated Gaps, Solutions, & Dependencies Matrix

24.3

Architecture Definition Increments Table

24.4

Transition Architecture State Evolution Table

24.5

Business Value Assessment Technique

Chapter

25

Interoperability Requirements

25.1

Overview

25.2

Defining Interoperability

25.3

Enterprise Operating Model

25.4

Refining Interoperability

25.5

Determining Interoperability Requirements

25.6

Reconciling Interoperability Requirements with Potential Solutions

Chapter

26

Business Transformation Readiness Assessment

26.1

Introduction

26.1.1

Business Transformation Enablement Program (BTEP)

26.2

Determine Readiness Factors

26.3

Present Readiness Factors

26.4

Assess Readiness Factors

26.4.1

Readiness Factor Vision

26.4.2

Readiness Factor Rating

26.4.3

Readiness Factor Risks & Actions

26.5

Readiness and Migration Planning

26.6

Marketing the Implementation Plan

26.7

Conclusion

Chapter

27

Risk Management

27.1

Introduction

27.2

Risk Classification

27.3

Risk Identification

27.4

Initial Risk Assessment

27.5

Risk Mitigation and Residual Risk Assessment

27.6

Conduct Residual Risk Assessment

27.7

Risk Monitoring and Governance (Phase G)

27.8

Summary

Chapter

28

Capability-Based Planning

28.1

Overview

28.2

Capability-Based Planning Paradigm

28.3

Concept of Capability-Based Planning

28.3.1

Capability Dimensions

28.3.2

Capability Increments

28.4

Capabilities in an Enterprise Architecture Context

28.5

Summary

Part

IV

Architecture Content Framework

Chapter

29

Introduction to Part IV

29.1

Overview

29.2

Content Metamodel

29.3

Content Framework and the TOGAF ADM

29.4

Structure of Part IV

Chapter

30

Content Metamodel

30.1

Overview

30.2

Content Metamodel Vision and Concepts

30.2.1

Core Content Metamodel Concepts

30.2.2

Overview of the Content Metamodel

30.3

Content Metamodel in Detail

30.3.1

Core Content Metamodel

30.3.2

Full Content Metamodel

30.4

Content Metamodel Extensions

30.4.1

Governance Extensions

30.4.2

Services Extensions

30.4.3

Process Modeling Extensions

30.4.4

Data Extensions

30.4.5

Infrastructure Consolidation Extensions

30.4.6

Motivation Extensions

30.5

Content Metamodel Entities

30.6

Content Metamodel Attributes

30.7

Metamodel Relationships

Chapter

31

Architectural Artifacts

31.1

Basic Concepts

31.1.1

Simple Example of an Architecture Viewpoint and Architecture View

31.2

Developing Architecture Views in the ADM

31.2.1

General Guidelines

31.2.2

Architecture View Creation Process

31.3

Views, Tools, and Languages

31.3.1

Overview

31.4

Architecture Views and Architecture Viewpoints

31.4.1

Example of Architecture Views and Architecture Viewpoints

31.4.2

Architecture Views and Architecture Viewpoints in Enterprise Architecture

31.4.3

Need for a Common Language and Interoperable Tools for Architecture Description

31.5

Conclusions

31.6

Architectural Artifacts by ADM Phase

31.6.1

Preliminary Phase

31.6.2

Phase A: Architecture Vision

31.6.3

Phase B: Business Architecture

31.6.4

Phase C: Data Architecture

31.6.5

Phase C: Application Architecture

31.6.6

Phase D: Technology Architecture

31.6.7

Phase E: Opportunities and Solutions

31.6.8

Requirements Management

Chapter

32

Architecture Deliverables

32.1

Introduction

32.2

Deliverable Descriptions

32.2.1

Architecture Building Blocks

32.2.2

Architecture Contract

32.2.3

Architecture Definition Document

32.2.4

Architecture Principles

32.2.5

Architecture Repository

32.2.6

Architecture Requirements Specification

32.2.7

Architecture Roadmap

32.2.8

Architecture Vision

32.2.9

Business Principles, Business Goals, and Business Drivers

32.2.10

Capability Assessment

32.2.11

Change Request

32.2.12

Communications Plan

32.2.13

Compliance Assessment

32.2.14

Implementation and Migration Plan

32.2.15

Implementation Governance Model

32.2.16

Organizational Model for Enterprise Architecture

32.2.17

Request for Architecture Work

32.2.18

Requirements Impact Assessment

32.2.19

Solution Building Blocks

32.2.20

Statement of Architecture Work

32.2.21

Tailored Architecture Framework

Chapter

33

Building Blocks

33.1

Overview

33.2

Introduction to Building Blocks

33.2.1

Overview

33.2.2

Generic Characteristics

33.2.3

Architecture Building Blocks

33.2.4

Solution Building Blocks

33.3

Building Blocks and the ADM

33.3.1

Basic Principles

33.3.2

Building Block Specification Process in the ADM

Part

V

Enterprise Continuum and Tools

Chapter

34

Introduction to Part V

34.1

Introduction

34.2

Structure of Part V

Chapter

35

Enterprise Continuum

35.1

Overview

35.2

Enterprise Continuum and Architecture Re-Use

35.3

Constituents of the Enterprise Continuum

35.4

Enterprise Continuum in Detail

35.4.1

Architecture Continuum

35.4.2

Solutions Continuum

35.5

The Enterprise Continuum and the ADM

35.6

The Enterprise Continuum and Your Organization

35.6.1

Relationships

35.6.2

Your Enterprise

Chapter

36

Architecture Partitioning

36.1

Overview

36.2

Applying Classification to Create Partitioned Architectures

36.2.1

Activities within the Preliminary Phase

36.3

Integration

Chapter

37

Architecture Repository

37.1

Overview

37.2

Architecture Landscape

37.3

Reference Library

37.3.1

Overview

37.4

Standards Information Base

37.4.1

Overview

37.4.2

Types of Standard

37.4.3

Standards Lifecycle

37.4.4

Standards Classification within the Standards Information Base

37.5

Governance Log

37.5.1

Overview

37.5.2

Contents of the Governance Log

37.6

The Architecture Requirements Repository

37.6.1

Overview

37.6.2

Contents of the Architecture Requirements Repository

37.7

Solutions Landscape

37.8

The Enterprise Repository

37.9

External Repositories

37.9.1

External Reference Models

37.9.2

External Standards

37.9.3

Architecture Board Approvals

Chapter

38

Tools for Architecture Development

38.1

Overview

38.2

Issues in Tool Standardization

Part

VI

Architecture Capability Framework

Chapter

39

Introduction to Part VI

39.1

Overview

39.2

Structure of Part VI

Chapter

40

Establishing an Architecture Capability

40.1

Overview

40.2

Phase A: Architecture Vision

40.3

Phase B: Business Architecture

40.4

Phase C: Data Architecture

40.5

Phase C: Application Architecture

40.6

Phase D: Technology Architecture

40.7

Phase E: Opportunities & Solutions

40.8

Phase F: Migration Planning

40.9

Phase G: Implementation Governance

40.10

Phase H: Architecture Change Management

40.11

Requirements Management

Chapter

41

Architecture Board

41.1

Role

41.2

Responsibilities

41.3

Setting Up the Architecture Board

41.3.1

Triggers

41.3.2

Size of the Board

41.3.3

Board Structure

41.4

Operation of the Architecture Board

41.4.1

General

41.4.2

Preparation

41.4.3

Agenda

Chapter

42

Architecture Compliance

42.1

Introduction

42.2

Terminology: The Meaning of Architecture Compliance

42.3

Architecture Compliance Reviews

42.3.1

Purpose

42.3.2

Timing

42.3.3

Governance and Personnel Scenarios

42.4

Architecture Compliance Review Process

42.4.1

Overview

42.4.2

Roles

42.4.3

Steps

42.5

Architecture Compliance Review Checklists

42.5.1

Hardware and Operating System Checklist

42.5.2

Software Services and Middleware Checklist

42.5.3

Applications Checklists

42.5.4

Information Management Checklists

42.5.5

Security Checklist

42.5.6

System Management Checklist

42.5.7

System Engineering/Overall Architecture Checklists

42.5.8

System Engineering/Methods & Tools Checklist

42.6

Architecture Compliance Review Guidelines

42.6.1

Tailoring the Checklists

42.6.2

Conducting Architecture Compliance Reviews

Chapter

43

Architecture Contracts

43.1

Role

43.2

Contents

43.2.1

Statement of Architecture Work

43.2.2

Contract between Architecture Design and Development Partners

43.2.3

Contract between Architecting Function and Business Users

43.3

Relationship to Architecture Governance

Chapter

44

Architecture Governance

44.1

Introduction

44.1.1

Levels of Governance within the Enterprise

44.1.2

Nature of Governance

44.1.3

Technology Governance

44.1.4

IT Governance

44.1.5

Architecture Governance: Overview

44.2

Architecture Governance Framework

44.2.1

Architecture Governance Framework — Conceptual Structure

44.2.2

Architecture Governance Framework — Organizational Structure

44.3

Architecture Governance in Practice

44.3.1

Architecture Governance — Key Success Factors

44.3.2

Elements of an Effective Architecture Governance Strategy

Chapter

45

Architecture Maturity Models

45.1

Overview

45.2

Background

45.3

US DoC ACMM Framework

45.3.1

Overview

45.3.2

Elements of the ACMM

45.3.3

Example: Enterprise Architecture Process Maturity Levels

45.4

Capability Maturity Models Integration (CMMI)

45.4.1

Introduction

45.4.2

SCAMPI Method

45.5

Conclusions

Chapter

46

Architecture Skills Framework

46.1

Introduction

46.2

Need for an Enterprise Architecture Skills Framework

46.2.1

Definitional Rigor

46.2.2

Basis of an Internal Architecture Practice

46.3

Goals/Rationale

46.3.1

Certification of Enterprise Architects

46.3.2

Specific Benefits

46.4

Enterprise Architecture Role and Skill Categories

46.4.1

Overview

46.4.2

TOGAF Roles

46.4.3

Categories of Skills

46.4.4

Proficiency Levels

46.5

Enterprise Architecture Role and Skill Definitions

46.5.1

Generic Skills

46.5.2

Business Skills & Methods

46.5.3

Enterprise Architecture Skills

46.5.4

Program or Project Management Skills

46.5.5

IT General Knowledge Skills

46.5.6

Technical IT Skills

46.5.7

Legal Environment

46.6

Generic Role and Skills of the Enterprise Architect

46.6.1

Generic Role

46.6.2

Characterization in Terms of the Enterprise Continuum

46.6.3

Key Characteristics of an Enterprise Architect

46.7

Conclusions

Part

VII

Appendices

Appendix

A

Glossary of Supplementary Definitions

Appendix

B

Abbreviations

Index

List of Figures

1-1

Structure of the TOGAF Standard

2-1

Relationships between Deliverables, Artifacts, and Building Blocks

2-2

Example — Architecture Definition Document

2-3

Enterprise Continuum

2-4

TOGAF Architecture Repository Structure

2-5

TOGAF Architecture Capability Overview

4-1

Architecture Development Cycle

4-2

Integration of Architecture Artifacts

5-1

Preliminary Phase

5-2

Management Frameworks to Co-ordinate with the TOGAF Framework

5-3

Interoperability and Relationships between Management Frameworks

6-1

Phase A: Architecture Vision

7-1

Phase B: Business Architecture

7-2

UML Business Class Diagram

8-1

Phase C: Information Systems Architectures

11-1

Phase D: Technology Architecture

12-1

Phase E: Opportunities & Solutions

13-1

Phase F: Migration Planning

14-1

Phase G: Implementation Governance

15-1

Phase H: Architecture Change Management

16-1

ADM Architecture Requirements Management

18-1

Iteration Cycles

18-2

Classes of Enterprise Architecture Engagement

18-3

A Hierarchy of ADM Processes Example

18-4

Activity by Iteration for Baseline First Architecture Definition

18-5

Activity by Iteration for Target First Architecture Definition

19-1

Summary Classification Model for Architecture Landscapes

19-2

Summary of Architecture Continuum

21-1

Sample Stakeholders and Categories

21-2

Stakeholder Power Grid

23-1

Gap Analysis Example

24-1

Implementation Factor Assessment and Deduction Matrix

24-2

Consolidated Gaps, Solutions, and Dependencies Matrix

24-3

Architecture Definition Increments Table

24-4

Transition Architecture State Evolution Table

24-5

Sample Project Assessment with Respect to Business Value and Risk

25-1

Business Information Interoperability Matrix

25-2

Information Systems Interoperability Matrix

26-1

Business Transformation Readiness Assessment — Maturity Model

26-2

Summary Table of Business Transformation Readiness Assessment

27-1

Risk Classification Scheme

27-2

Sample Risk Identification and Mitigation Assessment Worksheet

28-1

Capability-Based Planning Concept

28-2

Capability Increments and Dimensions

28-3

Capability Increment Radar

28-4

Relationship Between Capabilities, Enterprise Architecture, and Projects

29-1

Relationships between Deliverables, Artifacts, and Building Blocks

29-2

Example — Architecture Definition Document

29-3

Content Metamodel Overview

30-1

TOGAF Content Metamodel and its Extensions

30-2

Core Entities and their Relationships

30-3

Content Framework by ADM Phases

30-4

Detailed Representation of the Content Metamodel

30-5

Entities and Relationships Present within the Core Content Metamodel

30-6

Content Metamodel with Extensions

30-7

Relationships between Entities in the Full Metamodel

30-8

Core Content Metamodel and Predefined Extension Modules

30-9

Core Content with Governance Extensions

30-10

Governance Extensions: Extensions to Core Metamodel

30-11

Services Extension: Extensions to Core Metamodel

30-12

Process Modeling Extensions: Extensions to Core Metamodel

30-13

Data Extensions: Extensions to Core Metamodel

30-14

Infrastructure Consolidation Extensions: Extensions to Core Metamodel

30-15

Motivation Extensions: Extensions to Core Metamodel

31-1

Basic Architectural Concepts

31-2

Example Architecture View — The Open Group Business Domains

31-3

Interactions between Metamodel, Building Blocks, Diagrams, and Stakeholders

31-4

Artifacts Associated with the Core Content Metamodel and Extensions

33-1

Key ADM Phases/Steps at which Building Blocks are Evolved/Specified

35-1

Enterprise Continuum

35-2

Architecture Continuum

35-3

Solutions Continuum

35-4

Relationships between Architecture and Solutions Continua

36-1

Allocation of Teams to Architecture Scope

36-2

Architecture Content Aggregation

37-1

Overview of Architecture Repository

37-2

Architecture Continuum

39-1

Mature Architecture Capability

42-1

Levels of Architecture Conformance

42-2

Architecture Compliance Review Process

44-1

Architecture Governance Framework — Conceptual Structure

44-2

Architecture Governance Framework — Organizational Structure

List of Tables

4-1

ADM Version Numbering Convention

20-1

Recommended Format for Defining Principles

21-1

Example Stakeholder Analysis

Preface

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 Standard, Version 9.2 is an update to the TOGAF 9.1 standard to provide additional guidance, correct errors, address some structural challenges, and remove obsolete content. All of these changes will make the TOGAF framework easier to use and maintain.2

The TOGAF Documentation

The TOGAF documentation consists of a set of documents:

■ The TOGAF standard (this document) which describes the generally applicable approach to Enterprise and IT Architecture

■ The TOGAF Library, a portfolio of guidance material to support the practical application of the TOGAF approach

This Document

There are six parts to this document:

PART I

(Introduction) This part provides a high-level introduction to the key concepts of Enterprise Architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout the TOGAF documentation.

PART II

(Architecture Development Method) This part is the core of the TOGAF framework. It describes the TOGAF Architecture Development Method (ADM) — a step-by-step approach to developing an Enterprise Architecture.

PART III

(ADM Guidelines & Techniques) This part contains a collection of guidelines and techniques available for use in applying the TOGAF approach and the TOGAF ADM.

PART IV

(Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.

PART V

(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.

PART VI

(Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

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.

Keywords

architecture, architecture framework, architecture development method, architect, architecting, enterprise architecture, enterprise architecture framework, enterprise architecture method, method, methods, open, group, technical reference model, standards, standards information base

1. The TOGAF Library (https://publications.opengroup.org/togaf-library) provides a publicly available structured list of Guides and White Papers which provide guidance in the practical application of the TOGAF approach.

2. A full comparison of this version with the TOGAF Version 9.1 standard may be found in The Open Group White Paper: An Introduction to the TOGAF® Standard, Version 9.2 (www.opengroup.org/library/w182).

About The Open Group

The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 580 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.

The Open Group aims to:

■ Capture, understand, and address current and emerging requirements, establish policies, and share best practices

■ Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source technologies

■ Operate the industry’s premier certification service

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 Open Group 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.

Trademarks

ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®, UNIXWARE®, X/Open®, and the Open Brand X® logo are registered trademarks and Boundaryless Information Flow™, Build with Integrity Buy with Confidence™, Dependability Through Assuredness™, EMMM™, FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open Trusted Technology Provider™, SOSA™, the Open O™ logo, and The Open Group Certification logo (Open O and check™) are trademarks of The Open Group.

CMMI®, IPD-CMM®, P-CMM®, SA-CMM®, SCAMPI®, SE-CMM®, and SW-CMM® are registered trademarks of the Software Engineering Institute (SEI), Carnegie Mellon University.

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.

FICO® is a registered trademark of Fair Isaac Corporation in the United States and other countries. IEEE® is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc. ITIL®, MSP®, PRINCE®, 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®, SysML®, and UML® are registered trademarks and BMM™, BPMN™, Business Motivation Model™, Business Process Modeling Notation™, ITPMF™, IT Portfolio Management Facility™, SPEM™, Systems Modeling Language™, and Unified Modeling Language™ are trademarks of the Object Management Group.

Merriam-Webster Collegiate Dictionary® is a registered trademark of Merriam-Webster, Incorporated. OASIS® is a registered trademark of OASIS, the open standards consortium.

PMBOK® is a registered trademark of the Project Management Institute, Inc. which is registered in the United States and other nations.

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.

Participants

This document was prepared by The Open Group Architecture Forum. When The Open Group approved the TOGAF Standard, Version 9.2 on March 5, 2018, the Architecture Forum officers were as follows:

Mike Lambert, Fellow of The Open Group, Chair

Robert Weisman, Build The Vision, Vice-Chair

Sonia Gonzalez, The Open Group, Architecture and ArchiMate Forum Director

Architecture Forum Technical Reviewers

Technical reviewers are those individuals who have submitted comments during the company review, or participated in an issue resolution meeting during the development of the TOGAF Standard, Version 9.2:

Rob Akershoek, DXC Technology

Emmanuel Amamoo-Otchere, Huawei Technologies, Co. Ltd.

Michael Anniss, M.J. Anniss Ltd.

Graham Berrisford, Avancier

Terence Blevins, Fellow of The Open Group

Bill Estrem, Metaplexity Associates Inc.

Abdallah Fateen, Microsoft

Michael Fulton, Nationwide

Sonia Garnica, Intelligent Training de Colombia

Mats Gejnevall, Innovate

Kirk Hansen, Metaplexity Associates Inc.

Laura Hart, The MITRE Corporation

Judith Jones, ATE Enterprises

Andrew Josey, The Open Group

Rolf Knoll, NovaTec Consulting GmbH

J. Bryan Lail, Raytheon

Mike Lambert, Fellow of The Open Group

Neil Levette, TRM Technologies Inc.

Kenneth Lind, XLENT IT Consulting

Stephen Marshall, IBM

Chalon Mullins, Business Architecture Guild

Alain Picard, Benchmark Consulting

Sriram Sabesan, Conexiam

Satish Shettar, IBM

Robert Weisman, Build The Vision

Paul Williams, Capgemini

Architecture Forum Members

An up-to-date list of Forum members can be found at: www.opengroup.org/architecture.

Acknowledgements

The Open Group gratefully acknowledges The Open Group Architecture Forum for developing the TOGAF standard.

The Open Group gratefully acknowledges the contribution of the US Air Force for its Headquarters Air Force Principles.

The Open Group gratefully acknowledges those past and present members of the Architecture Forum who have served as its officers (Chairs and Vice-Chairs) since its inception. In alphabetical order:

Mick Adams

Christer Askerfjord

Terence Blevins

Bill Estrem

Hugh Fisher

Chris Forde

Chris Greenslade

Ed Harrington

Peter Haviland

Dave Hornford

David Jackson

Mike Lambert

Stuart Macgregor

Ian McCall

Tara Paider

Barry Smith

Walter Stahlecker

Sheena Thompson

Paul van der Merwe

Dave Van Gelder

Jane Varnus

Vish Viswanathan

Robert Weisman

Hal Wilson

Referenced Documents

The following documents are referenced in the TOGAF standard:

■ A Guide to the Project Management Body of Knowledge (PMBOK®) Guide), Project Management Institute; refer to www.pmi.org/pmbok-guide-standards

■ A Method for Identifying Process Re-Use Opportunities to Enhance the Operating Model, M. de Vries, A. van der Merwe, P. Kotze, A. Gerber, in proceedings of the 2011 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM)

■ Analysis Patterns — Reusable Object Models, M. Fowler, ISBN: 0-201-89542-0, Addison-Wesley

■ ANSI/IEEE Std 1471-2000: Systems and Software Engineering — Recommended Practice for Architectural Description of Software-intensive Systems

■ A Pattern Language: Towns, Buildings, Construction, Christopher Alexander, ISBN: 0-19-501919-9, Oxford University Press, 1979

■ Business Capabilities, an Open Group Guide, March 2016 (G161), published by The Open Group; refer to www.opengroup.org/library/g161

■ Business Motivation Model™ (BMM™), Object Management Group (OMG); refer to www.omg.org/spec/BMM/About-BMM

■ Business Transformation Enablement Program (BTEP), Canadian Government; refer to www.tbs-sct.gc.ca/btep-pto/index_e.asp

■ Business Process Modeling Notation™ (BPMN™) Specification, Object Management Group (OMG); refer to www.bpmn.org

■ Control Objectives for Information and related Technology (COBIT®), Version 4.0, IT Governance Institute, 2005

■ Corporate Governance, Ranami Naidoo, ISBN: 1-919-903-0086, Double Storey, 2002

■ Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, ISBN: 0-201-63361-2, Addison-Wesley, October 1994

■ Enterprise Architecture as Strategy, Jeanne Ross, Peter Weill, David C. Robertson, ISBN: 1-59139-839-8, Harvard Business School Press, 2006

■ Enterprise Architecture Capability Maturity Model (ACMM), Version 1.2, United States Department of Commerce, December 2007

■ Enterprise Architecture Maturity Model, Version 1.3, National Association of State CIOs (NASCIO), December 2003

■ Enterprise Architecture Planning (EAP): Developing a Blueprint for Data, Applications, and Technology, Steven H. Spewak, Steven C. Hill, ISBN: 0-47-159985-9, John Wiley & Sons, 1993

■ Exploring Synergies between TOGAF® and Frameworx, White Paper, May 2011 (W114), published by The Open Group; refer to www.opengroup.org/library/w114

■ Headquarters Air Force Principles for Information Management, US Air Force, June 29, 1998

■ Integrating Risk and Security within a TOGAF® Enterprise Architecture, an Open Group Guide, January 2016 (G152), published by The Open Group; refer to www.opengroup.org/library/g152

■ Integrating the TOGAF® Standard with the BIAN Service Landscape, White Paper, October 2013 (W135), published by The Open Group; refer to www.opengroup.org/library/w135

■ ISO/IEC 20000: 2011, Information Technology — Service Management

■ ISO/IEC/IEEE 15288: 2015, Systems and Software Engineering — System Life Cycle Processes

■ ISO/IEC/IEEE 42010: 2011, Systems and Software Engineering — Architecture Description

■ IT Portfolio Management Facility™ (ITPMF™) Specification, Object Management Group (OMG); refer to www.omg.org/spec/ITPMF

■ Merriam-Webster Collegiate Dictionary, Merriam-Webster, English Language, 11th Edition, April 2008, ISBN-10: 0877798095, ISBN-13: 978-0877798095; refer to www.merriam-webster.com

■ Model-Driven Architecture® (MDA®) Specification, Object Management (OMG); refer to www.omg.org/mda

■ OECD Principles of Corporate Governance, Organization for Economic Co-operation and Development, December 2001; refer to www.oecd.org

■ Organigraphs: Drawing How Companies Really Work, H. Mintzberg and L. Van der Heyden, Harvard Business Review, October 1999; refer to https://hbr.org/1999/09/organigraphs-drawing-how-companies-really-work

■ Pattern-Oriented Software Architecture: A System of Patterns, F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, ISBN: 0-471-95869-7, John Wiley & Sons, 1996

■ Patterns and Software: Essential Concepts and Terminology, Brad Appleton, 2000; refer to www.bradapp.com/docs/patterns-intro.html

■ Re-usable Asset Specification (RAS), Version 2.2, Object Management Group (OMG), November 2005; refer to www.omg.org/spec/RAS

■ Service Component Architecture (SCA) Specification, developed by the Open Service Oriented Architecture (OSOA) collaboration; refer to www.oasis-opencsa.org/sca

■ Service Data Objects (SDO) Specification, developed by the Open Service Oriented Architecture (OSOA) collaboration; refer to www.oasis-opencsa.org/sdo

■ Software Processing Engineering Metamodel (SPEM™) Specification, Version 2.0, Object Management Group (OMG), April 2008; refer to www.omg.org/spec/SPEM

■ Systems Modeling Language™ (SysML®), Object Management Group (OMG); refer to www.sysml.org

■ The Art of Systems Architecting, Eberhardt Rechtin, Mark W. Maier, 2000

■ The Open Group IT4IT™ Reference Architecture, Version 2.1, an Open Group Standard, January 2017 (C171), published by The Open Group; refer to www.opengroup.org/library/c171

■ The Oregon Experiment, Christopher Alexander, ISBN: 0-19-501824-9, Oxford University Press, 1975

■ The Timeless Way of Building, Christopher Alexander, ISBN: 0-19-502402-8, Oxford University Press, 1979

■ TOGAF® 9 and DoDAF 2.0, White Paper, July 2010 (W105), published by The Open Group; refer to www.opengroup.org/library/w105

■ TOGAF® and SABSA® Integration, White Paper, October 2011 (W117), published by The Open Group; refer to www.opengroup.org/library/w117

■ TOGAF® Series Guide: Business Scenarios, September 2017 (G176), published by The Open Group; refer to www.opengroup.org/library/g176

■ TOGAF® Series Guide: The TOGAF Integrated Information Infrastructure Reference Model (III-RM): An Architected Approach to Boundaryless Information Flow™, November 2017 (G179), published by The Open Group; refer to www.opengroup.org/library/g179

■ TOGAF® Series Guide: The TOGAF Technical Reference Model (TRM), September 2017 (G175), published by The Open Group; refer to www.opengroup.org/library/g175

■ TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented Architectures, September 2017 (G174), published by The Open Group; refer to www.opengroup.org/library/g174

■ TOGAF® Series Guide: Value Streams, October 2017 (G178), published by The Open Group; refer to www.opengroup.org/library/g178

■ UML Profile and Metamodel for Services (UPMS) RFP (OMG soa/2006-09-09), Object Management Group (OMG), June 2007

■ Unified Modeling Language™ (UML®) Specification, Object Management Group (OMG); refer to www.uml.org

The following websites provide useful reference material:

■ The Cloud Computing Design Patterns community website (refer to www.cloudpatterns.org)

■ The Information Technology Governance Institute: www.isaca.org/About-ISACA/IT-Governance-Institute

This website has many resources that can help with corporate assessment of both IT and governance in general.

■ The Patterns Home Page: hillside.net/patterns

This website is hosted by The Hillside Group and provides information about patterns, links to online patterns, papers, and books dealing with patterns, and patterns-related mailing lists.

■ The Patterns-Discussion FAQ: g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

This website is maintained by Doug Lea and provides a thorough and highly readable FAQ about patterns.

■ The SOA Patterns community website (refer to www.soapatterns.org/), dedicated to the ongoing development and expansion of the SOA design pattern catalog

■ The Volere website has a useful list of leading requirements tools www.volere.co.uk/tools.htm

The TOGAF Standard, Version 9.2

Part I:Introduction

The Open Group

Chapter 1

Introduction

The TOGAF standard is a framework for Enterprise Architecture. It may be used freely by any organization wishing to develop an Enterprise Architecture for use within that organization (see Section 1.4.1).

The TOGAF standard is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create Version 1 of the TOGAF standard by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment.

Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of the TOGAF standard and published each one on The Open Group public website.

This version builds on previous versions of the TOGAF standard and updates the material available to architecture practitioners to assist them in building a sustainable Enterprise Architecture. Work on White Papers and Guides describing how to to integrate and use this standard with other frameworks and architectural styles has highlighted the universal framework parts of the standard, as well as industry, architecture style, and purpose-specific tools, techniques, and guidance. This work is embodied in the TOGAF Library.1

Although all of the TOGAF documentation works together as a whole, it is expected that organizations will customize it during adoption, and deliberately choose some elements, customize some, exclude some, and create others. For example, an organization may wish to adopt the TOGAF metamodel, but elect not to use any of the guidance on how to develop an in-house Technology Architecture because they are heavy consumers of cloud and Open Platform 3.0™.

Regardless of your prior experience, you are recommended to read the Executive Overview (see Section 1.3), where you will find an outline of The Open Group understanding of Enterprise Architecture and answers to fundamental questions, such as:

■ Why is an Enterprise Architecture needed?

■ Why use the TOGAF standard as a framework for Enterprise Architecture?

1.1Structure of this Document

The structure of this document reflects the structure and content of an Architecture Capability within an enterprise, as shown in Figure 1-1.

Figure 1-1 Structure of the TOGAF Standard

There are six parts to this document:

PART I

(Introduction) This part provides a high-level introduction to the key concepts of Enterprise Architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout this standard.

PART II

(Architecture Development Method) This part is the core of the TOGAF framework. It describes the TOGAF Architecture Development Method (ADM) — a step-by-step approach to developing an Enterprise Architecture.

PART III

(ADM Guidelines & Techniques) This part contains a collection of guidelines and techniques available for use in applying the TOGAF approach and the TOGAF ADM. Additional guidelines and techniques are available in the TOGAF Library.

PART IV

(Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.

PART V

(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.

PART VI

(Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

The intention of dividing the TOGAF standard into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption while excluding others. For example, an organization may wish to adopt the ADM process, but elect not to use any of the materials relating to Architecture Capability.

As an open framework, such use is encouraged, particularly in the following situations:

■ Organizations that are new to the TOGAF approach and wish to incrementally adopt TOGAF concepts are expected to focus on particular parts of the specification for initial adoption, with other areas tabled for later consideration

■ Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects of the TOGAF standard

1.2Structure of the TOGAF Library

Accompanying this standard is a portfolio of guidance material, known as the TOGAF Library, to support the practical application of the TOGAF approach. The TOGAF Library is a reference library containing guidelines, templates, patterns, and other forms of reference material to accelerate the creation of new architectures for the enterprise.

The TOGAF Library is maintained under the governance of The Open Group Architecture Forum.

Library resources are organized into four sections:

■ Section 1. Foundation Documents

■ Section 2. Generic Guidance and Techniques

■ Section 3. Industry-Specific Guidance and Techniques

■ Section 4. Organization-Specific Guidance and Techniques

Where resources within the Library apply to the deployment of the TOGAF ADM and make explicit reference to "anchor points" within the TOGAF standard they are classified within the Library as Dependent documents. Resources that provide guidance on how to utilize features described in the standard are classified as Supporting documents. Resources that relate to Enterprise Architecture in general, and that do not make any specific references to the TOGAF standard, are classified as EA General documents.

1.3Executive Overview

This section provides an executive overview of Enterprise Architecture, the basic concepts of what it is (not just another name for IT Architecture), and why it is needed. It provides a summary of the benefits of establishing an Enterprise Architecture and adopting the TOGAF approach to achieve that.

What is an enterprise?

The TOGAF standard considers an "enterprise" to be any collection of organizations that have common goals.

For example, an enterprise could be:

■ A whole corporation or a division of a corporation

■ A government agency or a single government department

■ A chain of geographically distant organizations linked together by common ownership

■ Groups of countries or governments working together to create common or shareable deliverables or infrastructures

■ Partnerships and alliances of businesses working together, such as a consortium or supply chain

The term "Enterprise" in the context of "Enterprise Architecture" can be applied to either an entire enterprise, encompassing all of its business activities and capabilities, information, and technology that make up the entire infrastructure and governance of the enterprise, or to one or more specific areas of interest within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.

The enterprise operating model concept is useful to determine the nature and scope of the Enterprise Architecture within an organization. Many organizations may comprise multiple enterprises, and may develop and maintain a number of independent Enterprise Architectures to address each one. These enterprises often have much in common with each other including processes, functions, and their information systems, and there is often great potential for wider gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of common building blocks and solutions, and a shareable Architecture Repository for the integration and re-use of business models, designs, information, and data.

Why is an Enterprise Architecture needed?

The purpose of Enterprise Architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Today’s CEOs know that the effective management and exploitation of information and Digital Transformation are key factors to business success, and indispensable means to achieving competitive advantage. An Enterprise Architecture addresses this need, by providing a strategic context for the evolution and reach of digital capability in response to the constantly changing needs of the business environment.

For example, the rapid development of social media, Internet of Things, and cloud computing has radically extended the capacity of the enterprise to create new market opportunities.

Furthermore, a good Enterprise Architecture enables you to achieve the right balance between business transformation and continuous operational efficiency. It allows individual business units to innovate safely in their pursuit of evolving business goals and competitive advantage. At the same time, the Enterprise Architecture enables the needs of the organization to be met with an integrated strategy which permits the closest possible synergies across the enterprise and beyond.

What are the benefits of an Enterprise Architecture?

An effective Enterprise Architecture can bring important benefits to the organization. Specific benefits of an Enterprise Architecture include:

■ More effective and efficient business operations:

— Lower business operation costs

— More agile organization

— Business capabilities shared across the organization

— Lower change management costs

— More flexible workforce

— Improved business productivity

■ More effective and efficient Digital Transformation and IT operations:

— Extending effective reach of the enterprise through digital capability

— Bringing all components of the enterprise into a harmonized environment

— Lower software development, support, and maintenance costs

— Increased portability of applications

— Improved interoperability and easier system and network management

— Improved ability to address critical enterprise-wide issues like security

— Easier upgrade and exchange of system components

■ Better return on existing investment, reduced risk for future investment:

— Reduced complexity in the business and IT

— Maximum return on investment in existing business and IT infrastructure

— The flexibility to make, buy, or out-source business and IT solutions

— Reduced risk overall in new investments and their cost of ownership

■ Faster, simpler, and cheaper procurement:

— Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan

— The procurement process is faster — maximizing procurement speed and flexibility without sacrificing architectural coherence

—The ability to procure heterogeneous, multi-vendor open systems

— The ability to secure more economic capabilities

What specifically would prompt the development of an Enterprise Architecture?

Typically, preparation for business transformation needs or for radical infrastructure changes initiates an Enterprise Architecture review or development. Often key people identify areas of change required in order for new business goals to be met. Such people are commonly referred to as the "stakeholders" in the change. The role of the architect is to address their concerns by:

■ Identifying and refining the requirements that the stakeholders have

■ Developing views of the architecture that show how the concerns and requirements are going to be addressed

■ Showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders

Without the Enterprise Architecture, it is highly unlikely that all the concerns and requirements will be considered and met.

What is an architecture framework?

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.

Why use the TOGAF standard as a framework for Enterprise Architecture?

The TOGAF standard has been developed through the collaborative efforts of the whole community. Using the TOGAF standard results in Enterprise Architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and the perceived future needs of the business.

Developing and sustaining an Enterprise Architecture is a technically complex process which involves many stakeholders and decision processes in the organization. The TOGAF standard plays an important role in standardizing and de-risks the architecture development process. The TOGAF standard provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which address their business issues and needs.

Who would benefit from using the TOGAF standard?

Any organization undertaking, or planning to undertake, the development and implementation of an Enterprise Architecture for the support of business transformation will benefit from use of the TOGAF standard.

Organizations seeking Boundaryless Information Flow™ can use the TOGAF standard to define and implement the structures and processes to enable access to integrated information within and between enterprises.

Organizations that design and implement Enterprise Architectures using the TOGAF standard are assured of a design and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk.

1.4Information on Using the TOGAF Standard

1.4.1Conditions of Use

The TOGAF standard is freely available for viewing online without a license. Alternatively, it can be downloaded and stored under license, as explained on the TOGAF information website.

In either case, the TOGAF standard can be used freely by any organization wishing to do so to develop an architecture for use within that organization. No part of it may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, for any other purpose including, but not by way of limitation, any use for commercial gain, without the prior permission of the copyright owners.

1.4.2How Much Does the TOGAF Standard Cost?

The Open Group is committed to delivering greater business efficiency by bringing together buyers and suppliers of information systems to lower the barriers of integrating new technology across the enterprise. Its goal is to realize the vision of Boundaryless Information Flow.

The TOGAF standard is a key part of its strategy for achieving this goal, and The Open Group wants it to be taken up and used in practical architecture projects, and the experience from its use fed back to help improve it.

The Open Group therefore publishes it on its public web server, and allows and encourages its reproduction and use free-of-charge by any organization wishing to use it internally to develop an Enterprise Architecture. (There are restrictions on its commercial use, however; see Section 1.4.1.)

1.4.3Downloads

Downloads of the TOGAF standard, including printable PDF files, are available under license from the TOGAF information website (refer to www.opengroup.org/togaf/downloads). The license is free to any organization wishing to use the standard entirely for internal purposes (for example, to develop an Enterprise Architecture for use within that organization).

1.5Why Join The Open Group?

Organizations wishing to reduce the time, cost, and risk of implementing multi-vendor solutions that integrate within and between enterprises need The Open Group as their key partner.

The Open Group brings together the buyers and suppliers of information systems worldwide, and enables them to work together, both to ensure that IT solutions meet the needs of customers, and to make it easier to integrate IT across the enterprise. The TOGAF standard is a key enabler in this task.

Yes, the TOGAF standard itself is freely available. But how much will you spend on developing or updating your Enterprise Architecture? And how much will you spend on procurements based on that architecture? The price of membership of The Open Group is insignificant in comparison with these amounts.

In addition to the general benefits of membership, as a member of The Open Group you will be eligible to participate in The Open Group Architecture Forum, which is the development program within which the TOGAF standard is evolved, and in which TOGAF users come together to exchange information and feedback.

Members of the Architecture Forum gain:

■ Immediate access to the fruits of the current TOGAF work program (not publicly available until publication of the next edition of the TOGAF standard) — in effect, the latest information on the standard

■ Exchange of experience with other customer and vendor organizations involved in Enterprise Architecture in general, and networking with architects using the TOGAF standard in significant architecture development projects around the world

■ Peer review of specific architecture case study material

1. The TOGAF Library provides an online publicly available structured list of Guides, White Papers, and other resources. Refer to The Open Group Library at https://publications.opengroup.org/togaf-library.

Chapter 2

Core Concepts

For the purposes of the TOGAF standard, the core concepts provided in this chapter apply.

2.1What is the TOGAF Standard?

The TOGAF standard is an architecture framework. It provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an Enterprise Architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

2.2What is Architecture in the Context of the TOGAF Standard?

ISO/IEC/IEEE 42010: 2011 defines "architecture" as:

"The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution."

The TOGAF standard embraces but does not strictly adhere to ISO/IEC/IEEE 42010: 2011 terminology. In addition to the ISO/IEC/IEEE 42010: 2011 definition of "architecture", the TOGAF standard defines a second meaning depending upon the context:

"The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time."

The TOGAF standard considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology drawn from relevant standards, and commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to Chapter 3 and Part IV, Chapter 31.

2.3What Kind of Architecture Does the TOGAF Standard Deal With?

There are four architecture domains that are commonly accepted as subsets of an overall Enterprise Architecture, all of which the TOGAF standard is designed to support:

■ The Business Architecture defines the business strategy, governance, organization, and key business processes

■ The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources

■The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization

■ The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services; this includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

2.4Architecture Development Method

The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.