The TOGAF® Standard, 10th Edition - ADM Practitioners’ Guide – 2025 Update E-Book

The Open Group

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

Seitenzahl: 235

Veröffentlichungsjahr: 2025

Beschreibung

#html-body [data-pb-style=I03V7UM],This document is a TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM. It has been developed and approved by The Open Group, and is part of the TOGAF Standard, 10th Edition. Designed to help the Practitioner, it provides guidance on using the TOGAF framework to develop, maintain, and use an Enterprise Architecture. It is a companion to the TOGAF framework and is intended to bring the concepts and generic constructs in the TOGAF framework to life. It puts forward an approach to develop, maintain, and use an Enterprise Architecture that aligns to a set of requirements and expectations of the stakeholders, and enables predictable value creation. This document: Introduces key topics of concern Describes the TOGAF Standard concepts related to the topic Shows how it is related to developing, maintaining, and using an EA Discusses what the Practitioner needs to know Describes what the Practitioner should do with this knowledge It covers the following topics: An introduction to the topic, including how to use this guide with the TOGAF framework and definitions Guidance on Enterprise Architecture, including what it is and what it is used for Coordinating EA development across the EA Landscape and business cycle Using the ADM to develop an Enterprise Architecture Guidance on using an Enterprise Architecture Guidance on maintaining an Enterprise Architecture ‘A quality hard copy of the TOGAF method - easier to read than endless htm docs or huge pdfs! The TOGAF framework has become the de facto standard for developing Enterprise Architectures.' ‘A good one-stop-shop guide and toolsets for getting your Enterprise Architecture right. A lot of thought, experience, and funding have gone into this, and the results are well worth the price you pay for the book (and the actual accreditation should you or your organization wish to go down that route).’Amazon Comment ‘…it still is the best documented Enterprise Architecture method publicly available. The book is of high quality binding and will endure browsing through the pages for a long time.’Amazon Comment

Leseprobe

The TOGAF® Standard, 10th Edition

ADM Practitioners’ Guide

2025 Update

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

TOGAF® Business Architecture Foundation Study Guide

TOGAF® Enterprise Architecture Foundation Study Guide

The TOGAF Series (Version 9.2):

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

The Open Group Series:

The IT4IT™ Standard, Version 3.0

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.2 Specification

The Digital Practitioner Pocket Guide

The Digital Practitioner Foundation Study Guide

Open Agile Architecture™ – A Standard of The Open Group

Hospital Reference Architecture Guide: The Complete and Expanded English Translation of the Dutch ZiRA

The Open Group Press:

The Turning Point: A Novel about Agile Architects Building a Digital Foundation

Managing Digital

Ecosystems Architecture

For Your Information - About Information, the Universe, and the Modern Age

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 — ADM Practitioners’ Guide — 2025 Update

Series:

TOGAF Series Guide

A Publication of:

The Open Group

Publisher:

Van Haren Publishing, ’s-Hertogenbosch - NL, www.vanharen.net

ISBN Hardcopy:

978 94 018 1339 6

ISBN eBook:

978 94 018 1340 2

ISBN ePub:

978 94 018 1341 9

Edition:

First edition, first impression, April 2022Second edition, first impression, June 2025

Layout and Cover Design:

The Open Group

Copyright:

© 2018-2025 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. Specifically, without such written permission, the use or incorporation of this publication, in whole or in part, is NOT PERMITTED for the purposes of training or developing large language models (LLMs) or any other generative artificial intelligence systems, or otherwise for the purposes of using, or in connection with the use of, such technologies, tools, or models to generate any data or content and/or to synthesize or combine with any other data or content.

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 — ADM Practitioners’ Guide

Document number:            G186

Published by The Open Group, June 2025.

This document supersedes the previous version published in April 2018.

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]

Table of Contents

Preface

The Open Group

The TOGAF® Standard, a Standard of The Open Group

This Document

Trademarks

About the Authors

Acknowledgements

Referenced Documents

Part 1: Introduction

1. Introduction

1.1. Overview

1.2. How to Use this Document with the TOGAF Framework

1.3. Referenced Techniques

2. Definitions

2.1. Enterprise

2.2. Enterprise Architecture (EA)

2.3. Practitioner

Part 2: Guidance on Enterprise Architecture

3. The Purpose of Enterprise Architecture

3.1. Why is it Important to Develop an Enterprise Architecture?

3.2. What is an Enterprise Architecture?

3.2.1. Introduction to the EA Landscape

3.2.2. Introduction to Purpose

3.2.3. What an Enterprise Architecture Looks Like

3.3. How to Use an Enterprise Architecture?

3.3.1. Communicating with Stakeholders (Concern and View)

3.3.2. Communicating with Implementers (Gap, Specification, and Control)

3.3.3. Communicating with Decision-Makers (Other Useful Things)

3.4. Conclusion

4. Business Cycle

4.1. Budget Cycle

4.1.1. Budget Planning and Architecture to Support Strategy

4.1.2. Budget Preparation and Architecture to Support Portfolio

4.1.3. Budget Allocation and Architecture to Support Project

4.1.4. Budget Control and Architecture to Support Solution Delivery

4.2. Business Cycle Conclusion

5. Coordination Across the EA Landscape and EA Team

5.1. What to Expect in a Well-Run Architecture Repository & EA Landscape

5.1.1. What to Expect in a Well-Run EA Repository: EA Landscape

5.1.2. What to Expect in a Well-Run EA Repository: Reference Library

5.1.3. What to Expect in a Well-Run EA Repository: Standards Library

5.1.4. What to Expect in a Well-Run EA Repository: Architecture Requirements Repository

5.1.5. What to Expect in a Well-Run EA Repository: Compliance Assessments

5.2. How is ADM Iteration Realized in Practice?

5.2.1. Phase A: The Starting Point

5.2.2. Essential ADM Output and Knowledge

5.2.3. Iteration

5.2.4. ADM Plan for Architecture to Support Strategy

5.2.5. ADM Plan for Architecture to Support Portfolio

5.2.6. ADM Plan for Architecture to Support Project

5.2.7. ADM Plan for Architecture to Support Solution Delivery

5.2.8. Iteration Conclusion

5.3. Operating in the Context of Superior Architecture

5.4. Managing Multiple States (Candidate, Current, Transition, and Target)

5.5. Where are ABBs?

Part 3: Guidance on Developing the Enterprise Architecture

6. Approach to the ADM

6.1. Key Activity

6.1.1. Stakeholder Engagement and Requirements Management

6.1.2. Trade-Off

6.2. Trade-Off Decisions

6.3. Phases B, C, and D – Developing the Architecture

6.3.1. Select Reference Models, Viewpoints, and Tools

6.3.2. Develop Target, Baseline, and Gap

6.3.3. Identify the Work to Reach the Target Considering Cost and Value

6.3.4. Resolving Impacts

6.3.5. Approval

6.3.6. Minimum Needed and Look in the EA Repository

6.4. ADM Conclusion

7. Walk Through Architecture to Support Strategy

7.1. Introduction

7.2. Understanding Context

7.3. Assess the Enterprise

7.4. Define an Approach to Target State

7.4.1. Confirm Enterprise Change Attributes

7.4.2. Develop Value Proposition

7.4.3. Identify and Sequence Work Packages

7.5. Finalize Architecture Vision and Target Architecture

7.6. Conclusion

8. Walk Through Architecture to Support Portfolio

8.1. Introduction

8.2. Group Work Packages to Themes

8.3. Balance Opportunity and Viability

8.4. Run Up to Budget

8.4.1. Internal Engagement

8.4.2. Has the Target been Reached?

8.5. Drive Confidence of Delivery

8.6. Request for Architecture Work Originating from a Random Idea from the Wild

8.7. Conclusion

9. Walk Through Architecture to Support Project

9.1. Ascertain Dependencies

9.1.1. Project is not a Magical Place to Swap Out Stakeholders

9.1.2. Stakeholders versus Key Players

9.1.3. Viewpoints and Requirements

9.1.4. Go Talk to the “Neighbors”

9.1.5. Delivery and Acceptance Ability Assessment

9.2. Balance Options and Suppliers

9.2.1. Performing Trade-Off

9.2.2. Managing the Current Approach towards Implementing the Change

9.3. Finalize Scope and Budget

9.4. Prepare for Solution Delivery Governance

9.5. Project Request for Architecture Work Originating from the Wild

10. Walk Through Architecture to Support Solution Delivery

10.1. Introduction

10.1.1. Scoping

10.1.2. Function Purity and Solution Innovation

10.1.3. Handover and Closure

10.2. Aligning Implementers

10.3. Guiding Delivery

10.4. Realizing the Solution

10.5. Project Request for Architecture Work Originating from the Wild

10.6. Conclusion

Part 4: Guidance on Using the Enterprise Architecture

11. Jumping to Phase G

11.1. Failure Pattern: Missing the Purpose

11.2. Failure Pattern: Missing the Business Cycle

11.2.1. Architecture after Decision

11.3. Failure Pattern: Not Doing Architecture

11.4. Managing Innovation, Creativity, and Circumstance

12. Special Cases

12.1. Architecture in an Agile Enterprise

12.2. Architecture for a Domain

12.3. Architecture in Response to an Incident

Part 5: Guidance on Maintaining and Enterprise Architecture

13. Transition Architecture: Managing Complex Roadmaps

13.1. Roadmap Grouping

13.2. Comparing Architectures

13.3. General Guidance

14. Phase H (Coordination and Business Cycle in Action)

15. Architecture Governance

15.1. What is Governed and Why?

15.1.1. Target Architecture

15.1.2. Implementation Projects and Other Change

15.2. Roles, Duties, and Decision Rights

15.2.1. Target Checklist

15.2.2. Implementation and Other Change Checklist

15.2.3. Long-Term Compliance Reporting

15.3. Conclusion

Part 6: Appendices

A: Partial List of Modeling Approaches

B: Stakeholder/Concern Matrix

B.1. Common Stakeholder Classes

B.2. Common Concern Classes

C: Sample Viewpoint Library

D: Architecture Contract Template

E: Another ADM Journey: Leader’s Guide Capability-Based Planning Journey

F: Evolving List of Domain Architectures

Index

Preface

The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards and open source initiatives by fostering a culture of collaboration, inclusivity, and mutual respect among our diverse group of 900+ memberships. Our membership includes customers, systems and solutions suppliers, tool vendors, integrators, academics, and consultants across multiple industries.

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 are available at www.opengroup.org/library.

The TOGAF® Standard, a Standard of The Open Group

The TOGAF Standard is a proven enterprise methodology and framework used by the world’s leading organizations to improve business efficiency.

This Document

It has been developed and approved by The Open Group.

Trademarks

ArchiMate, FACE, FACE logo, Future Airborne Capability Environment, Making Standards Work, Open Footprint, Open O logo, Open O and Check certification logo, Open Subsurface Data Universe, OSDU, SOSA, SOSA logo, The Open Group, TOGAF, UNIX, UNIXWARE, and 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, FHIM Profile Builder, FHIM logo, FPB, IT4IT, IT4IT logo, O-AA, O-DA, O-DEF, O-HERA, OPAS, O-TTPS, O-VBA, Open Agile Architecture, Open FAIR, Open Process Automation, Open Trusted Technology Provider, Sensor Integration Simplified, and Sensor Open Systems Architecture are trademarks of The Open Group.

UML is a registered trademark and BMM, BPMN, Business Motivation Model, Business Process and Model Notation, and Unified Modeling Language are trademarks of the Object Management Group, Inc. in the United States and/or other countries.

All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.

About the Authors

(Please note affiliations were current at the time of approval.)

Dave Hornford, Conexiam

Dave Hornford is Conexiam’s Managing Partner and leads Conexiam’s Boston practice. Dave serves on the board of trustees of The SABSA® Institute. He is the former Chair of The Open Group Architecture Forum and was a key contributor to the TOGAF® 9 standard. Based in North America, he works in a variety of industries including financial services, oil and gas, technology, and capital-intensive industry. Typically, he helps clients develop and execute a roadmap to transform.

Nathan Hornford, Conexiam

Nathan Hornford is a management consultant and ABACUS Certified Architect and Designer. Nathan is based in Canada. Nathan works with all of Conexiam’s practices to provide consistent architecture methods and tools that address the client’s change needs.

Sriram Sabesan, Conexiam

Sriram Sabesan is a Certified Distinguished Architect, certified by The Open Group. Based in North America, he specializes in technology, manufacturing, telecommunication, and financial services industries. Sriram helps clients to develop and execute strategies in response to digital or economic disruptions. He is actively involved in development of different Open Group standards.

Sadie Scotch, Conexiam

Sadie Scotch is an Enterprise Architect. Sadie is based in the US and is a member of Conexiam’s Boston practice. Sadie specializes in governance, option analysis, and roadmap development. She helps clients to develop and govern change programs to address current Enterprise priorities.

Ken Street, Conexiam

Ken Street is an Enterprise Architect. Based in Canada, he leads Conexiam’s Governance and IT4IT™ initiatives. He is the current Vice-Chair of The Open Group Big Data project and is active within The Open Group IT4IT™ and Open Platform 3.0 Forums. He works primarily in financial services and oil and gas, helping clients to develop their EA Capability, improve their IT organization, and execute architecture-driven change programs.

Samantha Toder, Conexiam

Samantha Toder is a management consultant and ABACUS Certified Architect and Designer. Sam is based in the US. She helps clients to develop in-house EA Capability and execute complex transformation programs in the financial services industry.

Acknowledgements

The Open Group gratefully acknowledges the authors and also past and present members of The Open Group Architecture Forum for their contribution in the development of this Guide.

Referenced Documents

The following documents are referenced in this TOGAF® Series Guide:

[C220]

The TOGAF® Standard, 10th Edition, a standard of The Open Group (C220), published by The Open Group, April 2022; refer to: www.opengroup.org/library/c220

[C226]

ArchiMate® 3.2 Specification, a standard of The Open Group (C226), published by The Open Group, October 2022; refer to: www.opengroup.org/library/c226

[Carver, 2006]

John Carver: Reinventing your Board: A Step-by-Step White Paper to Implementing Policy Governance, Jossey-Bass, 2006

[Conklin, 2005]

Jeff Conklin: Wicked Problems & Social Complexity within Dialog Mapping: Building Shared Understanding of Wicked Problems, Wiley, 2005

[G152]

TOGAF® Series Guide: Integrating Risk & Security within a TOGAF® Enterprise Architecture, The Open Group Guide (G152), published by The Open Group, April 2022; refer to: www.opengroup.org/library/g152

[G184]

TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (G184), published by The Open Group, April 2022; refer to: www.opengroup.org/library/g184

[G188]

TOGAF® Series Guide: Architecture Project Management (G188), published by The Open Group, April 2022; refer to: www.opengroup.org/library/g188

[Hambrick & Fredrickson, 2001]

Donald C. Hambrick, James W. Fredrickson: Are you Sure you have a Strategy?, The Academy of Management Executive, 15, 4; ABI/INFORM Global, November 2001

[ISO/IEC 38500]

ISO/IEC 38500:2015: Information Technology – Governance of IT for the Organization

[ISO/IEC/IEEE 42010]

ISO/IEC/IEEE 42010:2022: Systems and Software Engineering – Architecture Description

[Kaplan & Norton, 1992]

Robert S. Kaplan, David P. Norton: The Balanced Scorecard – Measures that Drive Performance, Harvard Business Review, 70(1), Jan-Feb 1992

[Kruchten, 1995]

Philippe Kruchten: Architectural Blueprints – The “4+1” View Model of Software Architecture, November 1995; refer to: www.cs.ubc.ca/\~gregor/teaching/papers/4+1view-architecture.pdf

[Mintzberg et al., 2005]

Henry Mintzberg, Bruce Ahlstrand, and Joseph Lampel: Strategy Bites Back: It is Far More, and Less, than You Ever Imagined, April 2005

[W102]

World-Class Enterprise Architecture, White Paper (W102), published by The Open Group, April 2010; refer to: www.opengroup.org/library/w102

[W16B]

Architecture Project Management: How to Manage an Architecture Project using the TOGAF® Framework and Mainstream Project Management Methods, White Paper (W16B), published by The Open Group, August 2016; refer to: www.opengroup.org/library/w16b

Suggested Reading:

• Cuypers Ataya: Enterprise Value: Governance of IT Investments, The Business Case, IT Governance Institute, 2006

• Peter Swartz: The Art of the Long View: Planning for the Future in an Uncertain World, Currency Doubleday, 1996

• Kees van der Heijden: Scenarios: The Art of Strategic Conversation, 2nd Edition, Wiley, 2005

Part 1: Introduction

The Open Group

1. Introduction

1.1. Overview

This document provides guidance on using the TOGAF framework to develop, maintain, and use an Enterprise Architecture (EA). This document is a companion to the TOGAF framework and is intended to bring the concepts and generic constructs in the TOGAF framework to life. This document puts forward an approach to develop, maintain, and use an EA that aligns to a set of requirements and expectations of the stakeholders and enables predictable value creation.

It is intended to take the TOGAF concepts and show how each Practitioner can use the same concept to (a) deliver useful EA for their Enterprise and (b) deliver improvements to EA Capability. This point is important: use the same concept. Not the same technique, not the same template, not the same process. The same concept. For example, evidence from prevalent practice shows that there is not a single EA team that didn’t use a repository, whether the repository is a file folder or a fully-fledged installation of modeling and analytic software. If you are struggling with this point, stop and think about any preconceptions you are carrying into the conversation. For example, while reading, if you have a reaction similar to “but a real repository includes …”, ask yourself if this is universally true. The concept of a repository is universal; the implementation varies.

The essential scaffolding of the TOGAF framework is the concepts. Everything else in the TOGAF framework is either an example or a starter set to get you moving. If you do not like the example, then you can take advantage of the modular structure of the TOGAF framework and substitute it. Leading Practitioners and users often take this approach. This document is about advising the Practitioner in making the universal structure of the TOGAF framework work.

This document is written for the Practitioner, the person who is tasked to develop, maintain, and use an EA. Choice of the term Practitioner is deliberate, reflecting the role, rather than one of the myriad job titles in an Enterprise the Practitioner may have.

This document is structured to provide the context, content, and rationale behind choices and steps that an EA Practitioner can consult at any point. When effectively used, a thoughtfully developed EA optimizes Boundaryless Information Flow™ within and between Enterprises based on open standards and global interoperability.

This document is explicitly about developing, maintaining, and, most importantly, using an EA. The range of potential Enterprises and purposes require a guide of this length to define the direction.[1] Following the approach suggested in the World-Class Enterprise Architecture White Paper [W102], the TOGAF Standard is routinely applied to develop architectures supporting strategy development, portfolio management, project planning and execution, and solution development. Collective experiences reflect that there is no one right EA deliverable, model, view, work product, or technique. Rather, the correct approach is specific to the purpose of the architecture development initiative. Anyone who suggests there is a single correct approach, model, view, work product, or technique is not providing the right advice for you to succeed. This document will help you, the Practitioner, to identify the approach that is appropriate to any particular purpose.

Developing, maintaining, and using an EA requires deep interaction with several specialized functions such as strategy development, budgeting, benefits realization, portfolio management, program & project management, and operational units. This document will:

• Introduce key topics of concern

• Describe the TOGAF Standard concepts related to the topic

• Show how it is related to developing, maintaining, and using an EA

• Discuss what the Practitioner needs to know

• Describe what the Practitioner should do with this knowledge

Even though this document has a logical structure, it is not simple task list. The depth and detail of the steps needed to be taken by the Practitioner are specific to the purpose and are iterative. The only variable is time spent for every step. As with all change work, listing what you need to know is not the same as defining the level of detail in the documentation.

Key decisions are made in an Enterprise following a business cycle. An architecture should inform and enable decision-making. Just align the delivery of architecture to the Enterprise’s business cycle and the purpose of the architecture development initiative. The value is delivered when the architecture is used. It is plain and simple. This document is divided into six parts, as follows:

Part 1: Introduction

This part contains this introductory part and a set of definitions.

Part 2: Guidance on Enterprise Architecture

This part addresses:

• What an Enterprise Architecture is and what it is used for

• Coordinating EA development across the EA Landscape

• Coordinating EA development with the business cycle

Part 3: Guidance on Developing an Enterprise Architecture

This part addresses:

• Using the ADM

• Developing an Enterprise Architecture to Support Strategy

• Developing an Enterprise Architecture to Support Portfolio

• Developing an Enterprise Architecture to Support Project

• Developing an Enterprise Architecture to Support Solution Delivery

• Special Cases

Part 4: Guidance on Using an Enterprise Architecture

This part addresses:

• What to do when you are hip-deep in solution delivery

• Architecture in action (agile Enterprise, response to incident, etc.)

Part 5: Guidance on Maintaining an Enterprise Architecture

This part addresses:

• Managing multiple simultaneous roadmaps

• What to do when you are hip-deep in solution delivery

Part 6: Appendices

This part presents:

• A list of useful tables related to frameworks, reference models, etc.

1.2. How to Use this Document with the TOGAF Framework

The TOGAF framework provides essential universal scaffolding useful in a range of organizations, industries, and architectural styles. This document is designed to fill in what is not explicitly addressed by the TOGAF framework and provides an approach to interpret the standard. This does not suggest that the TOGAF framework is flawed. The TOGAF framework is designed to require interpretation or customization. It has to provide universal scaffolding. What is common and universal between all of the different examples provided in the definition of Enterprise? Essential scaffolding expressed as concepts.

One way to look at the TOGAF framework is that it is written for the expert theoretician – the person who thinks about the structure and practice of EA. TOGAF® Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability [G184] is for the person tasked with establishing or evolving an EA Capability.

This document is written directly for the person who does the work: develops, maintains, and uses an EA. The person who is not worried about the theory, and who is not worried about how to structure or maintain an EA Capability. The person who develops, uses, and maintains a good EA.

While this document assumes no detailed knowledge of the TOGAF framework, it explores the core concepts of the TOGAF Standard. It places these concepts together in the context of using them to develop, maintain, and use an EA. This includes guidance on iteration, an EA Repository, executing the ADM for the purpose of supporting Strategy, Portfolio, Project, and Solution Delivery, and performing effective governance of the development and use of the EA practice.

This document follows the approach of exploring the conceptual structures in the context of making use of them. This document assumes that you have established an EA Capability and have customized the TOGAF framework for your Enterprise.[2]

This document is part of the TOGAF Library.[3] Other documents in the TOGAF Library include the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability. The TOGAF Library provides a complete interpretation of the TOGAF Standard to establish an EA Capability, develop the EA Capability team, and deliver a useful architecture to guide change and govern the Enterprise change initiatives.

1.3. Referenced Techniques

References to key literature and their techniques within this document are intended only to be representative. This document does not suggest that the referenced tools, techniques, and literature are definitive. Other tools, techniques, and literature can readily be substituted.

Endnotes

[1] See the definition of Enterprise in Chapter 2. The important concept to keep in mind is that the term “Enterprise” is used as a boundary of analysis.

[2] For assistance customizing the TOGAF framework, see the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability [G184], which provides in-depth commentary and guidance for executing the Preliminary Phase of the TOGAF ADM.

[3] The TOGAF Library is available at publications.opengroup.org/togaf-library.

2. Definitions

To share a clear understanding a few terms need to be defined distinctly from common English usage. The terms below are distinctly defined, and capitalized wherever found. They mean exactly these definitions and nothing else in this document.

2.1. Enterprise

The highest level of description of an organization used to identify the boundary encompassed by the EA and EA Capability.

Note: This definition is deliberately flexible and not associated with an organization’s legal or functional boundaries. It must cover monolithic organizations and extended organizations that include separate organizations connected by a mission or supply chain, as well as operating entities within an organization. Consider an organization that uses outsourced partners to provide manufacturing, logistics, and support; a multi-national peacekeeping force; and a multi-billion-dollar division of a Fortune 50 firm. All are Enterprises.

2.2. Enterprise Architecture (EA)

As the focus of this document is to explain the TOGAF framework and the concept of Enterprise Architecture, it is better to define this concept in some detail. Succinct definitions tend to require specialized knowledge to understand the nuance. See Chapter 3 for a discussion of EA.

Two concise definitions that can be used are from Gartner and DoDAF. Gartner[1] defines Enterprise Architecture as: “the process of translating business vision and strategy into effective Enterprise change by creating, communicating, and improving the key principles and models that describe the Enterprise’s future state and enable its evolution”. DoDAF defines architecture as: “a set of abstractions and models that simplify and communicate complex structures, processes, rules, and constraints to improve understanding, implementation, forecasting, and resourcing”.

While many in the EA profession find distinguishing the terms “architecture” and “architecture description” useful, this document does not make any such distinction.

2.3. Practitioner

The person tasked to develop, maintain, and use an Enterprise Architecture.

Note: This term reflects the role, rather than one of the myriad job titles that may apply.

Endnotes

[1] Refer to: psu.instructure.com/courses/1783235/files/77571925/download, August 12, 2008.

Part 2: Guidance on Enterprise Architecture

The Open Group

3. The Purpose of Enterprise Architecture

A quick perusal of the literature will rapidly highlight that there is no consistent understanding of what an Enterprise Architecture (EA) looks like, or how one uses an EA. Attempts to succinctly define EA speak of fundamental concepts, elements, relationships, and properties of a system. These attempts tend to carry a high level of specialized knowledge and often make little sense to non-specialists. Further, it can be argued that this is the result of many commentators focusing on the architecture they develop, with the implicit assumption that everyone should do the same. Understanding comes from purpose.

EA is a strategic tool that presents an approach to identify and address gaps between aspirations and reality, whatever drives the gaps. It accelerates the ability of an Enterprise to achieve its stated objectives. The tool comes with its method to use, taxonomy to support the directions, and resources needed to benefit from using the tool.

This chapter will address the following questions:

• Why is it important to develop an Enterprise Architecture?

• What is an Enterprise Architecture?

• How to use an Enterprise Architecture?

3.1. Why is it Important to Develop an Enterprise Architecture?

An EA is developed for one very simple reason: to guide effective change.

All Enterprises are seeking to improve. Regardless of whether it is a public, private, or social Enterprise, there is a need for deliberate, effective change to improve. Improvement can be shareholder value or agility for a private Enterprise, mandate-based value proposition or efficiency for a public Enterprise, or simply an improvement of mission for a social Enterprise.

Guidance on effective change will take place during the activity to realize the approved EA. During implementation,[1] EA is used by the stakeholders to govern change. The first part of governance is to direct change activity – align the change with the optimal path to realizing the expected value. The second part of governance is to control the change activity – ensuring the change stays on the optimal path.