A White Paper by:

Dave Hornford, Conexiam

Nathan Hornford, Conexiam

Mike Lambert, Fellow of The Open Group

Ken Street, Conexiam

April 2022

Copyright © 2022, The Open Group

The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.

This document may contain other proprietary notices and copyright information.

Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed as conferring any license or right under any copyright of The Open Group.

Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The Open Group, and may not be licensed hereunder.

This document is provided "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you.

Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to these publications; these changes will be incorporated in new editions of these publications. The Open Group may make improvements and/or changes in the products and/or the programs described in these publications at any time without notice.

Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing products incorporating such information.

If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of this publication may be downloaded at www.opengroup.org/library.

This White Paper is an informational document. Readers should note that this document has not been approved through The Open Group Standards Process and does not represent the formal consensus of The Open Group Architecture Forum.

ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.

Business Model Canvas is a trademark of Alexander Osterwalder.

SABSA is a registered trademark of SABSA Limited.

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.

An Introduction to the TOGAF® Standard, 10th Edition

Document No.: W212

Published by The Open Group, April 2022.

Any comments relating to the material contained in this document may be submitted to:

The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom

or by email to:

ogpubs@opengroup.org

Boundaryless Information Flow™ achieved through global interoperability in a secure, reliable, and timely manner

Executive Summary

The aim of this document is to introduce you to the TOGAF Standard, 10th Edition and to start your journey to using the TOGAF Standard most effectively.

The document is written to three audiences who are concerned with the TOGAF Standard, namely: Enterprise Architecture practitioners, leaders of Enterprise Architecture teams, and the sponsors of Enterprise Architecture teams. Stakeholders, implementers, planners, and other consumers of Enterprise Architecture are rarely directly involved with the TOGAF Standard. Instead, Enterprise Architecture consumers are interested in using Enterprise Architecture to guide their decisions and govern their change.

The intent of this document is to introduce newcomers, and seasoned practitioners, to the TOGAF Standard, 10th Edition. This version of the standard makes adoption of best practices easier. It shows you where to find enduring and universal concepts. It highlights where to find stable, proven best practice. It underscores where to look for new emerging ideas. Together universal concepts, best practice guidance, and emerging ideas are how you adapt the TOGAF Standard for your configured Enterprise Architecture practice.

This document introduces the TOGAF Standard, 10th Edition. Topics addressed include:

•   Introduction to the TOGAF Standard

•   The structure of the TOGAF documentation set

•   The TOGAF Standard documentation set: TOGAF Fundamental Content and TOGAF Series Guides

•   What to do next

•   Summary of changes between Version 9.2 and the TOGAF Standard, 10th Edition

Every Enterprise Architecture team delivers support for selecting the most effective improvement and guiding the resulting change. To deliver, every Enterprise Architecture team faces the same three challenges:

•   How to configure their Enterprise Architecture team

•   How to configure their method of developing Enterprise Architecture

•   How they document their enterprise’s architecture

The TOGAF Standard provides the common concepts, structure, and enduring best practice to help Enterprise Architects deliver.

Every organization is distinct. It has a unique structure and place in an ecosystem. The TOGAF Standard is used by small, medium, and large commercial businesses, as well as government departments, non-government public organizations, and defense agencies. The TOGAF Standard, 10th Edition is designed for the dichotomy of common universal concepts and variable detailed configuration. This version of the standard aligns enduring stable concepts, proven practice, and new emerging ideas.

Changes to the TOGAF Fundamental Content are provided in Appendix A for readers who need to follow the changes between Version 9.2 and the TOGAF Standard, 10th Edition.

Introduction to the TOGAF Standard

The TOGAF Standard, 10th Edition is a significant structural change to support the separation of universal concepts, stable best practice, and thought leadership. This version of the standard makes adoption of stable best practice and emerging ideas easier. Combining universal concepts, stable best practice guidance, and emerging ideas is how you develop and use the best Enterprise Architecture. Any organization undertaking the development of an Enterprise Architecture to guide change and improvement will benefit from use of the TOGAF Standard. It provides stable best practice to develop, maintain, and use an Enterprise Architecture.

Members of The Open Group, working within the Architecture Forum, develop and maintain the TOGAF Standard.[1] The shared experience of the members proved the concepts, practices, and guidance contained in the standard. The TOGAF Standard is an open industry consensus that applies to the development of any kind of architecture in any context. It includes an extensive and growing portfolio of guidance material, providing practical guidance for specific contexts.

In short, the TOGAF Standard provides essential universal scaffolding and enduring best practice. Configuration of the universal scaffolding is necessary to align with the enterprise’s requirements and expectations.

The TOGAF Standard is divided into the TOGAF Fundamental Content and the TOGAF Series Guides. The TOGAF Fundamental Content provides the essential scaffolding. The TOGAF Series Guides advise on the configuration of the scaffolding. Together, the TOGAF Fundamental Content and the TOGAF Series Guides provide stable best practice used by the world’s leading organizations to improve.

Membership of The Open Group Architecture Forum is open to any organization. Members are drawn from different vertical sectors, such as Finance, Manufacturing, Professional Services, Academia, Government, Telecommunications, Defense, and Digital Platform. Members are drawn from around the world. The Open Group Standards Process[2] ensures every member has a voice and an equal opportunity to contribute.

The rigor of The Open Group Standards Process ensures stable, proven, best practice. The design of the TOGAF Standard supports leading, and even experimental, ideas. These ideas are provided in the complementary TOGAF Library.[3] The TOGAF Library is a reference library containing guidelines, templates, patterns, and other forms of reference material to speed up the creation and use of new architectures.

The central point of this document is that the Fundamental Content of the TOGAF Standard is enduring, stable, and universal. All customizations of the TOGAF Standard use the same scaffolding and standard. The concepts always remain – the configuration changes how the concepts are operated.

The Structure of the TOGAF Documentation Set

The TOGAF documentation set is structured to address the transition from common universal scaffolding to the unique configuration within an organization. It includes the formal TOGAF Standard and a broader body of knowledge in the TOGAF Library.

The TOGAF Standard represents today’s stable, scalable, best practice. This is expected from a standard – proven practice and stable concepts. Concepts and guidance apply across industries, scale, and pace of change. The TOGAF Standard provides a body of proven practice addressing its broad uses. The TOGAF Fundamental Content includes the universal concepts of Enterprise Architecture. The TOGAF Series Guides take these concepts and make them actionable – they provide proven, stable, and enduring best practice. Together, the TOGAF Fundamental Content and the TOGAF Series Guides are the TOGAF Standard.

The TOGAF documentation set anticipates emerging practice, specialist use-cases, and experimentation. The TOGAF Library provides a home for emerging practice and experimentation. The updated document structure of the TOGAF documentation set makes adoption of your optimal method easier.

Together, the TOGAF Standard and the TOGAF Library provide the best of both worlds.

Figure 1: TOGAF Documentation Set Structure

Members of The Open Group Architecture Forum are drawn from a wide range of industries and institutions. Members range in size from small and medium organizations to global giants. Across the Architecture Forum members there is no single universally correct detailed method or document for Enterprise Architecture. An Enterprise Architecture that supports strategic transformation looks very different from an Enterprise Architecture that supports consolidating operations in a small acquisition.

However, members have shown that there is one set of universal scaffolding for Enterprise Architecture. The methods and concepts to develop Enterprise Architecture used to support strategic transformation look very similar to the architecture for consolidating operations in a small acquisition.

The TOGAF Standard applies to all Enterprise Architecture practices. It does not matter whether your architecture will support strategy, portfolio, project, or solution delivery or whether it is about embarking on a Digital Transformation or legacy simplification – the TOGAF Fundamental Content and TOGAF Series Guides provide enduring, stable, universal concepts and proven best practice. Emerging ideas and practices can extend the TOGAF Standard. Together, universal concepts, best practice guidance, and emerging ideas are how you adapt the TOGAF Standard for your configured Enterprise Architecture practice.

Universal to Unique

The strength of the TOGAF Standard is to provide universal scaffolding that is uniquely customized. An Enterprise Architect working on the Data Architecture supporting a strategic transformation may not recognize a Business Architect’s work to support consolidating operations. Both are delivering Enterprise Architecture. Both will use the TOGAF Standard.

The Data Architect and Business Architect both serve stakeholders. They both help stakeholders understand the available changes in terms of a complex set of priorities. They both provide a roadmap of change and criteria to constrain the change and judge its success. They are working on problems with radically different scope in different domains. Neither needs merely different concepts or approaches. They need different specialist analytic, communication, and documentation techniques. Further, both need to bring their work together into a consistent whole. After all, they may work in the same organization on different aspects of the same change.

To facilitate transition from universal to unique, different TOGAF documents are used. The TOGAF Standard provides stable, enduring concepts and best practices. The TOGAF Fundamental Content provides the general content. The TOGAF Series Guides that describe proven, stable, and enduring best practice provide guidance in more specific topics. Together these documents are the TOGAF Standard. The TOGAF Standard is expected to have a longer lifecycle. Best practice is enduring, stable, and requires time to become proven.

Figure 2: The Purpose of Enterprise Architecture

Journey from Universal to Unique

The TOGAF Standard is developed by consensus of The Open Group Architecture Forum members. Work to improve, or expand, the TOGAF Standard is undertaken by practitioners based on the interests of the members. In many regards, it is a crowd-sourcing model. Member companies come from every industry, ecosystem, position, and size. They have different experiences. The Open Group Standards Process ensures the TOGAF Standard represents widely applicable best practice.

The release of the TOGAF Standard, Version 9 started the transition to better support the reality of universal and unique content. At that time, the TOGAF Standard was a monolithic document of 780 pages. It tried to speak to everyone. It required interpretation to understand which section was speaking to whom. Members felt it was too difficult to adopt and apply.

A White Paper on how to customize the TOGAF Standard to support Service-Oriented Architecture was developed and published.[4] The customization required no changes to the essential scaffolding. The customization used the universal concepts. Because the TOGAF Standard at the time consisted of a large monolithic document, it required the Work Group to ignore irrelevant specialist advice that was embedded in the text. The need to interpret the audience and applicability of the whole document made the task difficult. The members’ answer was to rip the book apart and liberate the specialists to speak to their specialization.

This learning was used to start the restructuring of the TOGAF Standard which was released in an interim state as the TOGAF Standard, Version 9.2. Material was pulled out of the monolith and published as separate TOGAF Series Guides. More importantly, the journey of speaking to specialists in specialist documents started. Guides addressing Risk and Security, Business Architecture, and Leading an Enterprise Architecture Team were published.

The TOGAF® Series Guide: The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability outlined a standard approach to use the same Architecture Development Method (ADM) to deliver architecture to support strategy, portfolio, project, and solution delivery. The TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture demonstrated that removing guidance and specialized deliverables from the central document did not mean Security Architecture was not important. Rather, it highlighted that risk and security were so important it was worth providing concise guidance on a specialist topic. The same for guides for addressing Business Architecture.

The TOGAF Standard, Version 9.2 represented an interim state. Some material was extracted from the core document and published in the TOGAF Series Guides. The TOGAF Standard had reached the next stage of its evolution. A structure existed to support practitioners with best practice to develop Enterprise Architecture in their unique circumstances using the same universal concepts. However, guidance remained in the central document and the specialist advice was not complete.

The members mobilized. Work Groups spanning hundreds of members worked to create the TOGAF Fundamental Content as a body of stable concepts and to create a set of TOGAF Series Guides that provide stable best practice. Today, with the release of the TOGAF Standard, 10th Edition there is a useful body of stable, proven practice. The body of proven practice addresses broad uses. In some areas – like Security and Business Architecture – it goes deeper.

The TOGAF Standard document structure is modular. There is a clear hierarchy from the universal concepts in the TOGAF Fundamental Content, to the stable best practice in the TOGAF Series Guides, to emerging ideas in the TOGAF Library.

The path to adopting the TOGAF Standard is significantly easier. Specialist guidance that supports specific needs can be added. Specialist guidance that is not relevant to you can also be identified. It can then be assessed whether the ideas are stable, proven best practice, or emerging. Your organization is unique; your customization of the TOGAF Standard will be unique.

TOGAF Standard Documentation Set

Over time, the TOGAF Standard documentation set will be expanded, enhanced, and updated. The current TOGAF Standard documentation set will be available online at www.opengroup.org/library/c220. The TOGAF Fundamental Content is expected to be the most stable. The TOGAF Series Guides will expand as the professional body of knowledge expands with more stable best practice.

Figure 3: TOGAF Standard Documentation Set

The document structure focuses on what most architects want – more, better, and topical guidance on how to deliver the best Enterprise Architecture that supports their stakeholders and their organization.

With the desire for more and better guidance on how to develop more useful Enterprise Architecture, the TOGAF Series Guides are presented first. Stakeholders want to have useful Enterprise Architecture guidance to change their decisions and govern their execution. This comes from best practice development of Enterprise Architecture and governance.

At time of writing the TOGAF Series Guides cover a range of topics, from general how-to and guidance on establishing an Enterprise Architecture team, to domain-specific material for Business and Security Architecture, and application with agile methods and agile software development.

The current TOGAF Standard documentation set (at the time of writing) is summarized in Table 1.

Table 1: TOGAF Standard Documentation Set

TOGAF Standard Document	General How-To	Establishing an EA Team	Domains					TOGAF Fundamental Content
			Security Architecture	Business Architecture	Data/Information Architecture	Agile Methods	Reference Models & Method
TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM	X
TOGAF Series Guide: Using the TOGAF Standard in the Digital Enterprise	X
TOGAF Series Guide: Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development	X
TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability		X
TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture			X
TOGAF Series Guide: Business Models				X
TOGAF Series Guide: Business Capabilities, Version 2				X
TOGAF Series Guide: Value Streams				X
TOGAF Series Guide: Information Mapping				X
TOGAF Series Guide: Organization Mapping				X
TOGAF Series Guide: Business Scenarios				X
TOGAF Series Guide: Information Architecture: Customer Master Data Management (C-MDM)					X
TOGAF Series Guide: Enabling Enterprise Agility						X
TOGAF Series Guide: Applying the TOGAF ADM using Agile Sprints						X
TOGAF Series Guide: TOGAF Digital Business Reference Model (DBRM)				X			X
TOGAF Series Guide: Government Reference Model				X			X
TOGAF Series Guide: Architecture Maturity Models							X
TOGAF Series Guide: Architecture Project Management							X
TOGAF Series Guide: Architecture Skills Framework							X
The TOGAF Standard: Introduction and Core Concepts								X
The TOGAF Standard: Architecture Development Method								X
The TOGAF Standard: ADM Techniques								X
The TOGAF Standard: Applying the ADM								X
The TOGAF Standard: Architecture Content								X
The TOGAF Standard: Enterprise Architecture Capability and Governance								X

General How-To Guidance

•     TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM

This document provides guidance on using the TOGAF framework to develop, maintain, and use an Enterprise Architecture. It is a companion to the TOGAF Fundamental Content and brings the concepts and generic constructs to life. Available at: www.opengroup.org/library/g186.

•     TOGAF Series Guide: Using the TOGAF Standard in the Digital Enterprise

This document describes how and when Enterprise Architecture should be used to enable a digital enterprise. It provides insight on how to integrate the DPBoK™ Standard^[5] concepts and contexts. Available at: www.opengroup.org/library/g217.

•     TOGAF Series Guide: Digital Technology Adoption: A Guide to Readiness Assessment and Roadmap Development

This document addresses the critical tenets of digital technology adoption readiness and the roadmap of change. It provides a digital technology readiness assessment and roadmap development. Available at: www.opengroup.org/library/g212.

Establishing an Enterprise Architecture Team Guidance

•     TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability

This document describes how to establish and enhance an Enterprise Architecture capability that aligns to your enterprise and what your Enterprise Architecture team is expected to support. Available at: www.opengroup.org/library/g184.

Domain-Specific Guidance

Security Architecture

•     TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture

This document describes how to integrate security and risk into an Enterprise Architecture. It provides guidance for both security practitioners and Enterprise Architects working with the TOGAF Standard. Available at: www.opengroup.org/library/g152.

Business Architecture

•     TOGAF Series Guide: Business Models

This document provides a basis to understand and utilize business models. It covers the concept and purpose of business models and highlights the Business Model Canvas™ technique. Available at: www.opengroup.org/library/g18a.

•     TOGAF Series Guide: Business Capabilities, Version 2

This document answers important questions about what a business capability is and how it is being used to enhance business analysis and planning. Available at: www.opengroup.org/library/g211.

•     TOGAF Series Guide: Value Streams

Value streams are one of the core elements of a Business Architecture. This document provides an architected approach to developing a business value model. Available at: www.opengroup.org/library/g178.

•     TOGAF Series Guide: Information Mapping

This document describes how to develop an Information Map that articulates, characterizes, and visually represents critical information. Available at: www.opengroup.org/library/g190.

•     TOGAF Series Guide: Organization Mapping

This document shows how organization mapping provides the organizational context to an Enterprise Architecture. Available at: www.opengroup.org/library/g206.

•     TOGAF Series Guide: Business Scenarios

This document shows how Business Scenarios can develop resonating business requirements and how they support and enable the enterprise to achieve its business objectives. Available at: www.opengroup.org/library/g176.

Data/Information Architecture

•     TOGAF Series Guide: Information Architecture: Customer Master Data Management (C-MDM)

This document describes an approach for implementing Customer Master Data Management (C-MDM) in an organization. It includes people, process, organizations, and systems to manage customer master data as an asset. Available at: www.opengroup.org/library/g21b.

Agile Methods

This subject area covers agile architecture supporting enterprise agility and delivered following agile principles, approaches, and methods.

•     TOGAF Series Guide: Enabling Enterprise Agility

This document describes how to apply the TOGAF ADM in an agile delivery environment by dividing an architecture development project into small time-boxed increments and applying common agile techniques. Available at: www.opengroup.org/library/g20f.

•     TOGAF Series Guide: Applying the TOGAF ADM using Agile Sprints

This document describes in detail how to deliver Enterprise Architecture with the TOGAF ADM in agile sprints. Available at: www.opengroup.org/library/g210.

Reference Models and Methods

•     TOGAF Series Guide: TOGAF Digital Business Reference Model (DBRM)

This document provides an industry-independent outline of common core components that are essential building blocks. Available at: www.opengroup.org/library/g21h.

•     TOGAF Series Guide: Government Reference Model

This document provides a national government capability reference model. Available at: www.opengroup.org/library/g21d.

•     TOGAF Series Guide: Architecture Maturity Models

This document introduces the concept of Architecture Capability Maturity Models, techniques for evaluating and quantifying an organization’s maturity in Enterprise Architecture. Available at: www.opengroup.org/library/g203.

•     TOGAF Series Guide: Architecture Project Management

This document provides guidance on using project management techniques to manage the development of Enterprise Architecture. Available at: www.opengroup.org/library/g188.

•     TOGAF Series Guide: Architecture Skills Framework

This document provides a set of role, skill, and experience norms for staff undertaking Enterprise Architecture work. Available at: www.opengroup.org/library/g198.

TOGAF Fundamental Content

The TOGAF Standard Fundamental Content is presented as six free-standing documents.

•     The TOGAF Standard: Introduction and Core Concepts

This document introduces the TOGAF Standard and outlines core concepts.

•     The TOGAF Standard: Architecture Development Method

This document describes the TOGAF ADM, which is an iterative approach to developing an Enterprise Architecture.

•     The TOGAF Standard: ADM Techniques

This document contains a collection of techniques available for applying the TOGAF approach and the TOGAF ADM.

•     The TOGAF Standard: Applying the ADM

This document contains guidelines for adapting the TOGAF ADM to address the specific style of architecture required in a practical context.

•     The TOGAF Standard: Architecture Content

This document describes the TOGAF Content Framework and a structured metamodel for architectural artifacts, and an overview of typical architecture deliverables.

•     The TOGAF Standard: Enterprise Architecture Capability and Governance

This document discusses the organization, processes, skills, roles, and responsibilities applicable to an Enterprise Architecture team.

The TOGAF Library

The TOGAF Series Guides are proven, stable best practice. The Enterprise Architecture profession must address emerging business challenges, business models, and technology capabilities. In addition to proven best practice, the young, vibrant profession requires innovation, leading-edge, and novel practices. The highest functioning Enterprise Architects are part of the innovation.

Leading Enterprise Architecture practitioners continually refresh their method and approach. One place to find leading-edge ideas, methods, approaches, and techniques is the TOGAF Library. The TOGAF Library is a curated collection of emerging and proven ideas plus additional useful materials. Within the TOGAF Standard documentation set, the TOGAF Library provides material that is likely to extend your capability to develop and use powerful Enterprise Architecture.

One set of documents in the TOGAF Library is developed elsewhere in The Open Group – three examples are The Open Group IT4IT™ Reference Architecture, The Open Group Commercial Aviation Reference Architecture, and the O-PAS™ Standard. They are reference architectures developed by experts in their industry. They can be adopted or used as an example.

The last set of material in the TOGAF Library is emerging ideas. Material in this category either has not yet stood the test of time, or the members developed the idea to a usable point and have moved their innovative thinking to a new idea.

All documents in the TOGAF Library can be used as-is or used as a start for developing your organization’s Enterprise Architecture. While you can expect more work integrating TOGAF Library materials, you gain the benefit of time-to-market.

TOGAF Library Examples

Business Architecture:

•     The Open Group IT4IT Reference Architecture

This is a reference architecture for Information Technology outlining value chains and information flows necessary to support digital products from strategy through to operational support. Available at: www.opengroup.org/library/c171.

•     The Open Group Commercial Aviation Reference Architecture

This is an industry vertical reference Business Architecture developed by a consortium of aviation firms. Available at: www.opengroup.org/library/p180.

Information Systems Architecture:

•     The O-PAS Standard

This document describes a standard architecture and interfaces for industrial process control equipment. Available at: www.opengroup.org/library/p210.

Re-purposable techniques:

•     Open FAIR™ Risk Analysis

This is a standard method for reducing subjectivity in risk analysis.

Emerging ideas:

•     Starting an Enterprise Architecture Capability in the Government Sector

This is a specialist guide for developing an Enterprise Architecture capability in the face of a significant public sector initiative. Available at: www.opengroup.org/library/g18c.

•     World-Class EA: Governors’ Approach to Developing and Exercising an Enterprise Architecture Governance Capability

This document provides emerging ideas on effective governance of developing Enterprise Architecture and directing the resulting change. Available at: www.opengroup.org/librrary/w178.

What to do Next

Each of the core communities for which this document was written has a different call to action coming from the release of the TOGAF Standard, 10th Edition.

Next Steps: Enterprise Architect Practitioner

High-functioning Enterprise Architecture practitioners are always looking for ways to improve their craft. The stable TOGAF Series Guides provide a mixture of broadly applicable guidance and specialized guidance. Different guides directly apply to every Enterprise Architecture practitioner.

A good first step is to get a copy of the TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM. Chapter 3 and Chapter 6 set the stage for applying everything in the TOGAF Standard, other TOGAF Series Guides, and the TOGAF Library.

A next step is to read the TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture. Risk and security are central to every Enterprise Architecture practitioner. Every practitioner has accountability to improve the performance of their organization. Practitioners are accountable for reducing the uncertainty of the organization reaching its objectives and improving its security.

Then get a copy of each guide that applies to your work. The guides are applicable because of the problem or domain they are designed to address. If your organization has digital initiatives, then get the digital-specific guides. If you need to enable agile development, then get the agile guides. If you are a Business Architect, then get the Business Architecture guides. If you are a Data Architect, then the TOGAF Series Guide: Information Architecture: Customer Master Data Management (C-MDM) may be helpful.

Explore the TOGAF Library. You will find documents that directly help you do your job or show you a very effective approach. Both make you a better Enterprise Architect.

Look for updates on the TOGAF Certification Program and The Open Group Open Badges Program. The updated and improved TOGAF Certification Program is all about effectively delivering useful Enterprise Architecture, either by application of the essential scaffolding, or by education on problems and domains.

Next Steps: Leader of an Enterprise Architecture Team

Leaders have the challenge of optimizing their Enterprise Architecture capability and developing their practitioners. Your organization’s need for useful Enterprise Architecture is constantly evolving. You need to continually improve your Enterprise Architecture team.

Download a copy of the TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability. Ensure that you have clarity on the purpose of your Enterprise Architecture Team (Section 3.3), and the boundary of your enterprise (Sections 4.1 and 4.2).

Identify any gaps in your ability to deliver the Enterprise Architecture your organization wants to consume. Start filling them. You will likely find the following TOGAF Series Guides useful: Integrating Risk and Security within a TOGAF® Enterprise Architecture and Using the TOGAF Standard in the Digital Enterprise. High-functioning Enterprise Architecture teams always reduce the uncertainty of the organization reaching its objectives and improving its security. If your organization is not on a Digital Transformation journey, then you should expect it to start soon.

The third step is to get a copy of each guide that applies to your team. Become familiar and distribute them to your team. Require them to leverage applicable best practice. If your Enterprise Architecture team is re-inventing readily available practices, then they are spending time in the wrong place. Your organization wants useful Enterprise Architecture.

Consider joining The Open Group Architecture Forum. Members of the Architecture Forum gain a unique ability to network and collaborate with other practitioners. The collaborative work to develop best practice guidance will improve your practitioners’ skill and knowledge and your team’s practices.

Keep an eye on the TOGAF Certification Program and other professional development. Establishing an effective Enterprise Architecture team requires configuring the TOGAF Standard to your organization. Every Enterprise Architecture team carries a large opportunity cost. Building the optimal team for your enterprise is required to realize the benefits of Enterprise Architecture.

Updates on the TOGAF Certification Program and the credentials, programs, and specialized training apply to your Enterprise Architecture team. You are responsible for your Enterprise Architecture team’s professional development. Leverage established training and accreditation programs.

Next Steps: Sponsor of an Enterprise Architecture Team

Sponsors know they can improve their organization’s ability to make better change decisions and execute the changes with Enterprise Architecture. They will have championed their Enterprise Architecture team to help their organization. Most sponsors have the additional challenge of not being Enterprise Architecture practitioners, or Enterprise Architecture team leads. Most want the outcome without understanding the detail of how the work is done.

Read the TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability. You should provide clarity on the purpose of your Enterprise Architecture team (Sections 3.3 and 8.2), the boundary of your enterprise (Sections 4.1 and 4.2), and how success will be measured (Section 5.4). Further, you need to assist with the improvement of your governance structure (Chapter 6).

Work with the leader of your Enterprise Architecture team to identify gaps in delivery of the Enterprise Architecture your organization wants to consume, and how to improve the team.

Look for updates on the TOGAF Certification Program, the TOGAF Certification Credentials Program, and specialized training. You are accountable for your Enterprise Architecture team’s professional development. Leverage established training and accreditation programs.

Next Steps: Everyone who Consumes Enterprise Architecture

Stakeholders, implementers, and other consumers of Enterprise Architecture have a different next step. You should look at the Enterprise Architecture you are receiving and compare it with the architecture you should be receiving. Work with the leader and sponsor of your Enterprise Architecture capability to define their business objectives. Chapter 5 of the TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability should help you communicate with them.

Raise your expectations. Best practice Enterprise Architecture is transformative. For stakeholders, the exercise of developing a good Enterprise Architecture will provide you with confidence of the best path for your organization; the best path that addresses all your opportunities and concerns.

Appendix A: Changes to the TOGAF Fundamental Content

Essential scaffolding and established best practices are stable and enduring. For example, Phase B has guided the development of Business Architecture since the TOGAF Standard, Version 8. The high-level steps of selecting reference architectures, viewpoints, developing the target, and rationalizing impacts across your architecture landscape are almost unchanged.

A significant change in the TOGAF Standard, 10th Edition is in the TOGAF Fundamental Content restructure and consistency improvements. One of the strengths of the TOGAF Fundamental Content is the completeness of the fundamental concepts. Little completely new material has been introduced in the Fundamental Content. Rather, the bulk of the work has been in improving consistency. The work to improve consistency serves to help all practitioners configure and use the TOGAF Standard. New material is largely in the TOGAF Series Guides.

This appendix contains a detailed list of changes introduced in the TOGAF Standard, 10th Edition compared to Version 9.2. This appendix does not include editorial changes, such as changes to cross-references to reflect changes to the structure of the TOGAF Standard, or changes to section numbering as a result or new or deleted sections.

The primary audience for this material is organizations that need to conform fully to the revised standard.

For a description of changes introduced in Version 9.1, please refer to the referenced White Paper: An Introduction to TOGAF® 9.1.[6]

For a description of changes introduced in Version 9.2, please refer to the referenced White Paper: An Introduction to the TOGAF® Standard, Version 9.2.[7]

Systematic Changes

The following changes are applied systematically across the six Fundamental Content volumes of the TOGAF Standard:

•     The ADM graphic (the TOGAF Standard: Introduction and Core Concepts, Figure 3-1 et al.)

The arrow heads on the links between phases are removed to avoid the implication that the ADM is a waterfall model. The link between Phase A and the Preliminary Phase is changed to bidirectional to reflect the need to re-enter the Preliminary Phase when the Architecture Capability needs to be changed.

•     The term Content Framework and Metamodel is changed to TOGAF Content Framework and TOGAF Enterprise Metamodel because these are two distinct concepts; the Content Framework is a model of architecture deliverables, and the Enterprise Metamodel is a model of the entities in the enterprise

•     In most instances, the term “Architecture Building Block (ABB)” is abbreviated to “ABB”; the term “Solution Building Block (SBB)” to “SBB”, and the term “Architecture Development Method (ADM)” to “ADM

•     Many definitions of terminology used in the TOGAF Standard are updated to improve their clarity; others have been added

The TOGAF Standard: Introduction and Core Concepts

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Chapter 1
2	The TOGAF Documentation Set	This material is largely new.
3	Core Concepts	Chapter 2
4	Definitions	Chapter 3
Appendix A	Referenced Documents	Front Matter
Appendix B	Glossary of Supplementary Definitions	Appendix A
Appendix C	Abbreviations	Appendix B

Detailed Changes

Reference	Details of Change
	Structure of this Document and Structure of the TOGAF Library, Sections 1.1 and 1.2 of Version 9.2, are replaced by a new Chapter 2.
Introduction	The term “Open Platform 3.0™” is dropped from the sentence referencing a Technology Architecture viz. “…. to develop an in-house Technology Architecture because they are heavy consumers of cloud and Open Platform 3.0™” and is replaced with “ heavy consumers of cloud services”. The sentence referencing The Open Group understanding of Enterprise Architecture and answers to fundamental questions such as … is simplified to read: “You are recommended to first read the Executive Overview (see Section 1.1), which includes an outline of The Open Group understanding of Enterprise Architecture and answers to fundamental questions, such as: …”
1.1	The sentence “An enterprise may include partners, suppliers, and customers as well as internal business units” is added to clarify the applicability of the term “enterprise”, replacing the penultimate paragraph of Section 1.3 in Version 9.2. The examples of changes to the IT environment are removed, because it is not appropriate to include an evolving list in a stable standard. Paragraph 4 relating to privacy is new. The list of benefits of an Enterprise Architecture is extended with “More effective strategic decision-making …” and there is some clarification of sub-bullets in subsequent sections. A new paragraph is added breaking down the reasons for embarking on an Enterprise Architecture review. The section “What is an architecture framework” is shortened and reorganized, and leaves out the reference to “... include a list of recommended standards and compliant products that can be used to implement the building blocks”. The need to tailor the framework to meet the specific needs of an organization is added, Two paragraphs are added to the section “Why use the TOGAF Standard”, setting out the TOGAF Standard value proposition. One paragraph relating to Digital Transformation is added to the section “Who would benefit from using the TOGAF Standard”. The section “When should Enterprise Architecture be done?” is new.
1.2	Structure of the document is new.
2	This chapter explaining the structure of the extended TOGAF Standard, referred to as “The TOGAF Documentation Set”, is new.
3.2	The reference to Part IV, Chapter 31 in the last paragraph of “What is an Architecture in the Context of the TOGAF Standard” is replaced with “the TOGAF Standard – Architecture Content”.
3.3	The description of other architecture domains is new.
3.4	The ADM graphic Figure 3.1 is added. The material after the bullet list of ADM phases is new and stresses the need to adapt the ADM and to treat the ADM as a reference model, rather than as a process model.
3.5	The section on Enterprise Architecture Services is new.
3.6	The words “Part IV, Chapter 29” in the first paragraph are replaced with “The TOGAF Standard – Architecture Content”. At the end of the description of Artifact the sentence “An artifact may or may not be considered a deliverable based on the contractual specification.” is added. The description of Building Block drops the concept of “component of enterprise capability” and is reworded to reflect it as “a potentially re-usable component that can be combined with other building blocks to deliver architectures and solutions”. The last two paragraphs are new. They reference where detail of Deliverables, Artifacts, and Building Blocks can be found in the new standard.
3.7	The section on Architecture Abstraction is new.
3.8	The summary description of Architecture Principles is extracted from the start of Section 20.1 of Version 9.2.
3.9	The summary description of Interoperability is extracted from Section 25.1 and the start of Section 25.2 of Version 9.2.
3.10	The opening paragraph replaces the sentence “The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures.” with the sentence “The Enterprise Continuum is a categorization for assets held in the Enterprise Repositories that provides methods for classifying assets, including architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures.” A sentence is added describing where a detailed description of the Enterprise Continuum can be found.
3.11	Figure 3-5 is updated to align with Figure 7-1 in the TOGAF Standard – Architecture Content: The term “Standards Information Base” is replaced by “Standards Library”. The term “Governance Log” is replaced by “Governance Repository”. The bulleted definitions of the concepts in the new diagram are updated with the new terms described above. A sentence is added describing where a detailed description of the TOGAF Architecture Repository can be found.
3.12	The summary description of the TOGAF Content Framework and Enterprise Metamodel is extracted from Chapter 30 of Version 9.2, as amended in Chapter 1 of the TOGAF Standard – Architecture Content.
3.14	Risk Management is changed to Risk and Opportunity Management.
3.16	The section on Architecture Styles is new. The concept of Architecture Styles was introduced in the TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures.
3.17	The summary description of Architecture Views and Viewpoints is taken from Chapter 31 of Version 9.2, as amended for inclusion in the TOGAF Standard – Architecture Content.
3.18	The section on Enterprise Agility is new.
3.19	The summary description of Risk Management is extracted from Chapter 27.
4	Definitions are changed: To support usage of terms in the extended TOGAF Standard and the TOGAF Library To remove inconsistencies where terms were effectively defined more than once in different parts of the TOGAF Standard New Definitions Added Definitions Changed Definitions Removed Application Service Architecture Level Architecture Partition Digital Architecture Enterprise Architecture Service Product Standards Library Application Architecture Architecture Building Block (ABB) Architecture Continuum Architecture Development Method (ADM) Architecture Domain Building Block Business Function Business Service Capability Capability Architecture Enterprise Continuum Information Technology (IT) Logical Metamodel Objective Physical Service Solution Architecture Solution Building Block (SBB) Solutions Continuum Information System Service Organization Map Repository Standards Information Base (SIB)
Appendix A	The list of referenced documents is regenerated to include all documents referenced from the revised six Fundamental Content volumes.
Appendix B	Descriptions of Enterprise Metamodel entities are no longer included in the list of definitions. They may be found in Section 2.4 of the TOGAF Standard – Architecture Content. New Definitions Added Definitions Changed Definitions Removed Metaview Portfolio Contract Control Data Entity Driver Event Functional Decomposition Goal Guideline Location Logical Application Component Logical Data Component Logical Technology Component Measure Physical Application Component Physical Data Component Physical Technology Component Process Product Profile Profiling Transaction
Appendix C	New Abbreviations Added Abbreviations Changed Abbreviations Removed MSA MVA NAF None. IPD-CMM P-CMM SA-CMM SCAMPI SE-CMM SIB SW-CMM

The TOGAF Standard: Architecture Development Method

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Chapter 4
2	Preliminary Phase	Chapter 5
3	Phase A: Architecture Vision	Chapter 6
4	Phase B: Business Architecture	Chapter 7
5	Phase C: Information Systems Architectures	Chapter 8
6	Phase C: Information Systems Architectures – Data Architecture	Chapter 9
7	Phase C: Information Systems Architectures – Application Architecture	Chapter 10
8	Phase D: Technology Architecture	Chapter 11
9	Phase E: Opportunities & Solutions	Chapter 12
10	Phase F: Migration Planning	Chapter 13
11	Phase G: Implementation Governance	Chapter 14
12	Phase H: Architecture Change Management	Chapter 15
13	ADM Architecture Requirements Management	Chapter 16

Systematic Changes

The following changes are applied systematically throughout the document:

•     The lists of catalogs, matrices, and diagrams which may be output from each phase are replaced by a cross-reference to TOGAF Standard – Architecture Content to eliminate duplication and the risk of inconsistency

•     The version numbers associated with deliverables are replaced: 0.1 by draft, 1.0 by approved

•     The Create Architecture Definition Document step in several ADM phases is renamed Create/Amend Architecture Definition Document to reflect the likely pre-existence of the document

•     A reference to evaluation of Target Architecture alternatives is added to several ADM phases; this supports the concept of Architecture Alternatives, which is introduced in Section 1.6

•     Because the reference to specific version numbering is removed, the description of the contents of the Architecture Definition Document as an input to each phase of the ADM is simplified to “Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain”

Detailed Changes

Reference	Details of Change
1.1	Simplified. Reference to IT needs removed.
1.2	The reference to a specific version numbering convention is replaced by “draft” and “approved”. Table 4.1 is removed.
1.2.2	The example list of steps in Phases B, C, and D is removed. The table illustrating version numbering is replaced by text explaining the terms “draft” and “approved”.
1.3	Material is added to identify the potential need to adapt the Content Framework and Enterprise Metamodel and to support an Agile Enterprise Architecture delivery style together with cross-references to TOGAF Series Guides describing Enterprise Agility. A cross-reference is added to the TOGAF Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF ADM.
1.6	The concept of Architecture Alternatives is new in this version.
2.3.6.1	This section is copied unchanged from Section 38.2 in Version 9.2.
2.5	The final two paragraphs are added to enable a reference to the TOGAF Standard – Enterprise Architecture and Governance.
2.5.6	The penultimate paragraph is added to enable a reference to the TOGAF Series Guide: Architecture Project Management.
2.5.7	The reference to guidance on the use of Capability Maturity Models is removed because this material is longer part of the TOGAF Standard.
3.5.2	Reference to the TOGAF Series Guide: Organization Mapping, which provides additional guidance on how to develop Organization Maps, is added to the bullet Organization Maps.
4.3.1.1	Information Mapping is added. The descriptions of Process Modeling and Use-case Analysis are simplified. The description of Structured Analysis is changed to reference business capabilities instead of business functions. The sequence of the list of techniques is changed to reference a more logical sequence.
	The section “Identify Required Service Granularity Level, Boundaries, and Contracts (Section 7.3.1.2 in Version 9.2) is removed.
4.3.9	The second bullet is rewritten and sub-bullets removed.
4.4	Business services and products are added to the list of contents of the Target Business Architecture. The description of Business Services is expanded.
4.5.1	The final sentence of paragraph 5, relating Business Strategy to Business Architecture, is removed.
4.5.6	The section Applying Information Maps is new.
4.5.7	The description of Use-Case Models is simplified to remove duplication. The bullet Class Models is changed to Logical Data Model (or Class Model) and the description generalized, with class model introduced as a specific type of Logical Data Model. The description of Node Connectivity Diagram and Information Exchange Matrix are removed, because they are not generally applicable.
4.5.8	The list of examples of Industry Reference Models is removed.
6.2.1	Two new TOGAF Series Guides are added to the list of Reference Materials External to the Enterprise.
6.3.1	Reference to two new TOGAF Series Guides providing further guidance on Information Architecture reference models is added.
6.3.1.2	The first paragraph is simplified.
6.3.1.3	The first two sentences explaining the term matrices are removed.
6.5.1	The section describing Data Structure is new.
6.5.2.1	A reference to the new TOGAF Series Guide: Information Architecture: Customer Master Data Management (C-MDM) is added.
6.5.3	The examples of generic industry reference models are removed, because the examples are no longer current.
7.3.9	The step name is changed to Create/Update the Architecture Definition Document because the document may already exist.
7.5.1	The examples of generic industry reference models are removed, because some, at least, of the examples are no longer current.
8.5.2	The reference to the TM Forum is removed, because many other examples also exist.
9.3.1	The “Implementation Factor Assessment and Deduction Matrix” is renamed the “Implementation Factor Catalog”. This change is also in Sections 9.3.3, 9.3.9, and 9.4.
9.3.3	The sentence “The SBBs are created based on the candidate roadmap components from Phases B, C, and D.” is added.
11.2	Architecture Governance Framework is added to the list of Architectural Inputs.
11.4	Architecture Building Blocks (ABBs) are added as part of the deployed Architecture-compliant solution.
13.3	The description of step 1, Identify requirement, is extended and clarified.
13.3	The description of step 2 is clarified by removing the specific reference to the current phase of the ADM.
13.5.3.1	The description of Business Scenarios is expanded.
13.5.3.2	The reference to the Volère website is removed.

The TOGAF Standard: ADM Techniques

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Chapter 17, Section 17.2
2	Architecture Principles	Chapter 20
3	Stakeholder Management	Chapter 21
4	Architecture Patterns	Chapter 22
5	Gap Analysis	Chapter 23
6	Migration Planning Techniques	Chapter 24
7	Interoperability Requirements	Chapter 25
8	Business Transformation Readiness Analysis	Chapter 26
9	Risk Management	Chapter 27
10	Architecture Alternatives & Trade-Offs	New

Chapter 28 in Version 9.2 (Capability-Based Planning) is removed because extended guidance available in the TOGAF Series Guide: Business Capabilities, Version 2 is not compatible with the contents of Chapter 28.

Detailed Changes

Reference	Details of Change
2.6.1	Principle 4. Rationale. The enterprise business functions must be capable of operating on alternative information delivery mechanisms. “The enterprise business functions” is replaced by “The enterprise”.
3.4	Catalogs, Matrices, and Diagrams list. The following changes are applied where the list in Version 9.2 includes Functional Decomposition Diagram: Functional Decomposition Diagram is removed Organization Map is added
5.2	In the last line, “Function” is replaced by “Building block”.
6	Throughout the section, the term “Implementation Factor Assessment and Deduction Matrix” is replaced by “Implementation Factor Catalog”.

The TOGAF Standard: Applying the ADM

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Adapted from Chapter 17
2	Applying Iteration to the ADM	Chapter 18
3	Applying the ADM Across the Architecture Landscape	Chapter 19
4	Architecture Partitioning	Chapter 36

Detailed Changes

Reference	Details of Change
1	The opening section is taken from Section 17.1 in Version 9.2, and extended to include a summary description of Using the TOGAF Framework with Different Architecture Styles and Architecture Partitioning.
1.1	The references to other guides are removed from the first paragraph, because they are repeated later in the section. The sentence “Some styles can be considered fashionable …” is removed. The bullet list of distinctive features of SOA as an architectural style is removed. The reference to “Integrating the TOGAF Standard with the BIAN service Landscape” is replaced by “Archi Banking Group: Combining the BIAN Reference Model, ArchiMate Modeling Notation, and the TOGAF Framework”. The final paragraph explaining the TOGAF Library is simplified.
3.3/3.4	These sections are reversed in sequence to provide a more logical flow.

The TOGAF Standard: Architecture Content

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Chapters 29, 30
2	TOGAF Content Framework and Enterprise Metamodel	Chapter 30
3	Architectural Artifacts	Chapter 31
4	Architecture Deliverables	Chapter 32
5	Building Blocks	Chapter 33
6	Enterprise Continuum	Chapter 35
7	Architecture Repository	Chapter 37

Detailed Changes

Reference	Details of Change
1.1	The description of Architecture Building Blocks (ABBs) is rewritten. The reference to required capability is removed. The fact that logical business, application, and technology components are ABBs is added. The description of SBBs is also rewritten.
1.2	This section is rewritten to explain the difference between the TOGAF Content Framework and the Enterprise Metamodel: The Content Framework defines a categorization framework to be used to Structure the Architecture Description (new Section 1.2.2) The Enterprise Metamodel defines the types of entity likely to appear in the models that describe the enterprise, together with the relationships between those entities (new Section 1.2.3)
1.2.4	Developed from Chapter 30, this section provides an overview of the TOGAF Content Framework and its relationship to the TOGAF ADM. Figure 1.3 is revised as follows: To show that Architecture Change Management underpins all architecture activity The Business Architecture, Information Systems Architecture, and Technology Architecture are structured as part of the Architecture Definition Motivation impacts Business, Information Systems, and Technology; it is not just part of the Business Architecture The Business Architecture is restructured into Strategy and Operational instead of Organization and Behavior The contents of the bullet list below Figure 1.3 are reworded to show that the Content Framework contains architecture models, not entities from the enterprise. Architecture Realization is renamed Architecture Realization/Transformation. A bullet describing Architecture Change Management is added. Figure 1.4 shows how the Content Framework can be used to structure entities in the TOGAF Enterprise Metamodel.
1.4	This summary of the Enterprise Continuum is added.
1.5	This summary of the Architecture Repository is added.
2.1	The description of the Content Metamodel in Version 9.2 is expanded to show the difference between the Content Framework and the Enterprise Metamodel.
2.2	This section specifically describes the purpose of the TOGAF Enterprise Metamodel. The concepts of Core and Extension Content (Section 30.2.1 in Version 9.2) are dropped, because full content is relevant to the majority of enterprises and the content of extensions was contentious and did not represent current best practice. The description of extensions (Section 30.4 in Version 9.2) is removed in its entirety. Figure 2-1 shows how the entities in the TOGAF Enterprise Metamodel can be structured according to the Content Framework.
2.3	This section describes the TOGAF Enterprise Metamodel, including all the entities and the most significant relationships between them. The entities and relationships shown in Figure 2-2 contain numerous detailed changes to reflect evolving thinking about the structure of the enterprise, particularly in the area of Business Architecture. New entity: Business information Changed entities: Information System Service changed to Application Service Note: While it might be desirable to capture the rationale for every individual change to the TOGAF Enterprise Metamodel, space in this document does not permit this. To understand the rationale, readers are referred to Section 2.3 of the TOGAF Standard – Architecture Content.
2.4	In Version 9.2, there were contradictory descriptions/definitions of metamodel entities in Chapter 3 (Definitions), Section 30,2, and Section 30.5. In this volume, two different lists are combined and definitions aligned with the list of definitions in the TOGAF Standard – Introduction and Core Concepts. That means that Section 2.4 is the definitive list of metamodel entities and their descriptions/definitions. New Metamodel Entities Added Metamodel Entities with Revised Description/Definition Names/Descriptions Removed Application Service Business Service Application Component * Business Information Capability Information System Service Contract Service * Data Entity Technology Component * Function Location Logical Application Component Logical Data Component Logical Technology Component Objective Physical Application Component Physical Data Component Physical Technology Component Process Product Service Quality Value Stream * These are classes of entities that do not appear in the Enterprise Metamodel, but specific instances do.
2.5	Section 2.5 contains a highly detailed reference list of typical attributes for each of the entities in the TOGAF Metamodel. This list of attributes for the following metamodel entities are changed: Requirement Information System Service (name changed to Application Service)
2.6	Section 2.6 contains a full list of relationships between entities in the TOGAF Enterprise Metamodel. Because the concepts of Core and Extension Content is removed (see changes to Section 2.2 above), the column “Extension Module” is removed from the table in Section 2.6. New Relationships Changed Relationships Relationships Removed Actor consumes Business Service Actor triggers process Actor participates in process Actor performs a task in value stream Actor triggers value stream Actor consumes service Application Service automates some or all of Business Service Application Service used by Data Entity Application Service is realized through Logical Application Component Application Service is served by Technology Service Information System Service realizes Service Information System Service used by Data Entity Information System Service is realized through Logical Application Component Information System Service is served by Technology Service Business Capability uses Business Information Business Information is used by Business Capability Business Information is used to derive Business Service Business Information is delivered by Function Business Information is realized by Data Entity Business Information uses Process Business Service is provided by Actor Business Service uses Application Service Business Service is derived from Business Information Business Service meets Business Service Quality Business Service Consumes Business Service Business Service decomposes Business Service Business Service is governed and measured by Contract Business Service is accessed and updated through Data Entity Business Service resolves Event Business Service provides governed interface to access Function Business Service is implemented on Logical Technology Component Business Service is owned and governed by Organization Unit Business Service is realized by Process Business Service supports Process All relationships involving Service as the source entity are removed. The majority are replaced by the relationships using Business Service as the source entity (left column). Contract governs and measures business service Course of Action influences Business Information Course of Action influences Organization Unit Course of Action influences Product Data Entity is supplied or consumed by Actor Data Entity realizes Business Information Data Entity uses Application Service Data Entity is accessed and updated through Business Service Event is resolved by Business Service Function is influenced by Course of Action Function is bounded by Business Service Function orchestrates Process Function decomposes Process Function is performed by Actor Goal is made specific by Objective Logical Application Component implements Application Service Logical Technology Component provides platform for Business Service Measure sets performance criteria for Service Organization Unit participates in Course of Action Organization Unit delivers Business Capability Organization Unit owns and governs Business Service Organization Unit enables Function Organization Unit delivers Product Organization Unit involves Process Physical Data Component used by Physical Application Component Process is produced by Actor Process supports Actor Process operationalizes Business Capability Process is used by Business Information Process operationalizes Value Stream Process orchestrates Business Service Process decomposes Business Service Process supports Function Process is realized by Function Process delivers Product Process involves Organization Unit Product is produced by Course of Action Technology Service serves Application Service Value Stream is operationalized by Process
3.1	The Note at the end of Section 31.1 in Version 9.2 is replaced with a paragraph establishing the relationship between concerns and requirements.
3.6	Figure 3-4 is updated to remove any reference to content extensions and to align with the up-to-date list of artifacts by ADM phase in the following sections. In Version 9.2, there were two lists of artifacts that could be produced in each ADM phase: one in the description of the phase in the section description of the ADM, and one in Section 31.6. These lists are combined and aligned, meaning that Section 3.6 is the definitive list of recommended artifacts for production in each ADM phase.
3.6.2	The Stakeholder Map Matrix is renamed Stakeholder Catalog. The descriptions of the following artifacts are updated: Business Capability Map: Not a family of diagrams Value Stream Map: Not a family of diagrams
3.6.3	The descriptions of the following artifacts are updated: Business Service/Function Catalog: Information Systems Service changed to Application Service Contract/Measure Catalog: Information Systems Service changed to Application Service Business Capabilities Catalog: the word definitive is removed Value Stream Catalog: the word definitive is removed Value Stream Stages Catalog: the word definitive is removed Business Glossary Catalog: new Product LIfecycle Diagram: reworded and simplified Goal/Objective/Business Service Diagram: Service changed to Business Service Business Event Diagram: Event changed to Business Event Business Capability Map: not a family of diagrams Value Stream Map: not a family of diagrams
3.6.4	The descriptions of the following artifacts are updated: Data Entity/Data Component Catalog: restructured Data Security Diagram: restructured Data Migration Diagram: reworded and simplified
3.6.5	The descriptions of the following artifacts are updated: Application/Organization Matrix: Business functions changed to Business operations Role/Application Matrix: the final paragraph and bullet list are removed
4.1	The mapping of the following deliverables as “output from …” and “input to …” phases of the ADM are revised: Architecture Contract Architecture Definition Document
7.1	The specific term “Standards Information Base” is generalized to “Standards Library”. The term “Governance Log” is changed to “Governance Repository” to reflect the breadth of governance material. Figure 7-1 is updated to reflect this change in terminology.
7.4	The term “Standards Information Base” is replaced by “Standards Library” in the title and throughout Section 7.4.
7.5	The term “Governance Log” is replaced by “Governance Repository” in the title and throughout Section 7.5.

The TOGAF Standard: Enterprise Architecture Capability and Governance

Structural Changes

The following table maps the contents of this document to the TOGAF Standard, Version 9.2.

Chapter	Title	Source in Version 9.2
1	Introduction	Adapted from Section 39.2
2	Establishing an Architecture Capability	Chapter 40
3	Architecture Governance	Chapter 44
4	Architecture Board	Chapter 41
5	Architecture Contracts	Chapter 43
6	Architecture Compliance	Chapter 42

Detailed Changes

Reference	Details of Change
1	References to Architecture Maturity Models and Architecture Skills Framework are removed since content was decoupled as guides.
2.2	In the third bullet, the first clause is removed.
2.11	A reference to the “TOGAF Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability” is added.
3.1.5.2	The first paragraph “As mentioned above” is removed.
3.2.1.2	“(also known as Waiver)” is added to title “Dispensation”.
3.2.2.1	Figure 3-2 is modified to show the Architecture Board independent of the Development team; “Outside Providers” is added and relationships clarified.
4.3.1	A new bullet is added as part of the triggers for setting up the Architecture Board: Organizational restructuring.
4.3.2	Paragraph 2 is added.
5.2.3	The target of the Architecture Contract is changed from “Business Users” to “Business Stakeholders”. The first paragraph is simplified. “Service Architecture …” is replaced by “SLA”.
6.3.1	In bullet 2 in the second bullet list, “CIO” is replaced by “executive management”.
6.4.1	The note below Figure 6-2 is added.
6.4.2	The focus on IT is removed: Row 4: “An IT architecture specialist” is replaced by “An appropriate architecture specialist” Row 5: “technical assistants” is replaced by “assistants” Row 6: “success of the IT described in the architecture” is replaced by “success of the Enterprise Architecture”
6.4.3	The focus on IT is removed: Row 1: changed from “As mandated by IT Governance” to “As mandated by governance”

About the Authors

Dave Hornford, Conexiam

Dave Hornford is Conexiam’s Managing Partner and leads Conexiam’s EA Capability practice. Dave co-authored the TOGAF® Series Guide: The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability. 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 document structure of the TOGAF Standard, 10th Edition. Based in Canada, 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 co-authored the TOGAF® Series Guide: The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability and the TOGAF® Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM. Nathan is based in Canada. He configures Conexiam’s Navigate content framework enabling predictable Enterprise Architecture. Nathan works with all of Conexiam’s practices to provide consistent architecture methods and tools and to address clients’ change needs.

Mike Lambert, Fellow of The Open Group

Mike Lambert is a Fellow of The Open Group. Mike has made ongoing contributions to the development of the TOGAF® Standard. Under his chairmanship of The Open Group Architecture Forum, the early work to release the TOGAF Standard, Version 9.2 was accomplished. Mike continued to lead the Architecture Forum through the re-structuring of the TOGAF Standard, 10th Edition until it was in the final editorial stages.

Ken Street, Conexiam

Ken Street is a Management Consultant. Ken co-authored the TOGAF® Series Guide: The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability and the TOGAF® Series Guide: A Practitioners’ Approach to Developing Enterprise Architecture Following the TOGAF® ADM. Ken is active within The Open Group IT4IT™, Architecture, and Open Platform 3.0™ Forums. Based in Canada, he leads Conexiam’s Business & IT Alignment, Governance, and Big Data practices. His focus is on helping clients to develop their EA Governance Capability, improve their Business/IT alignment, and execute architecture-driven change programs.

Acknowledgements

The authors gratefully acknowledge the contribution of the following people in the development of this document:

•     Shammi Bhandaru, Archi Tacts, Inc.

•     Chris Frost, Fujitsu

•     Rolf Knoll, Novatec Consulting GmbH

•     Rita Neelam, Archi Tacts, Inc.

•     Michael Payne, Real IRM Solutions (Pty) Ltd.

The authors gratefully acknowledge the contribution of the following people through the comment and review of the document:

•     David Gilmour, Mundo Cognito

•     Andy Ruth, Sustainable Evolution, Inc.

Special Acknowledgements for the Development of the TOGAF Standard, 10^th Edition

Since the release of the TOGAF Standard, Version 9 hundreds of people have worked thousands of hours to improve the TOGAF Standard, and work through its restructuring. Contributors to different documents are thanked in each document. However, there are five groups of people who made a significant difference. Without their contribution we would not have a visibly modular and expandable standard.

First, the authors of the TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures. This document, and the process of writing it, was the basis of the re-architecture of the TOGAF Standard. The authors put together a guide and inadvertently found the way to go forward.

Second, The Open Group Security Forum with The SABSA® Institute who embarked on improving the handling of Security Architecture early in the restructuring of the TOGAF Standard. It was difficult to develop Security Architecture guidance on a changing TOGAF Standard. They proved the restructuring model with what is now the TOGAF Series Guide: Integrating Risk and Security within a TOGAF Enterprise Architecture.

Third, a team led by Kirk Hansen worked relentlessly to overhaul the TOGAF Standard top-to-bottom. Without the supporting TOGAF Series Guides, their work was put aside. It provided a set of central inputs used to rationalize the TOGAF Fundamental Content.

Fourth, the staff of The Open Group supported the Forum members through nearly a decade of work, changing participation, changing direction, and failing memory. The Open Group structure, where the staff facilitate and draw out the members’ knowledge and expertise, enables creation of open standards in which you can have confidence.

Last, an individual, Mike Lambert. Mike took on the duty of Chairing the Architecture Forum and taking part in hundreds of change and comment review sessions. His history with The Open Group, and the TOGAF Standard, combined with his belief in the power of the re-structured document, his grace, and expertise made it possible.

About The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. With more than 870 member organizations, we have a diverse membership that spans all sectors of the technology community – customers, systems and solutions suppliers, tool vendors, integrators and consultants, as well as academics and researchers.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

•     Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices

•     Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies

•     Offering a comprehensive set of services to enhance the operational efficiency of consortia

•     Developing and operating the industry’s premier certification service and encouraging procurement of certified products

Further information on The Open Group is available at www.opengroup.org.

[1] Refer to: www.opengroup.org/architecture-forum.

[2] Refer to: www.opengroup.org/standardsprocess.

[3] Available at: www.opengroup.org/togaf-library.

[4] Service-Oriented Architecture (SOA), White Paper (W074), July 2007, published by The Open Group; refer to: www.opengroup.org/library/w074.

[5] Digital Practitioner Body of Knowledge™ Standard (also known as the DPBoK Standard), The Open Group Standard (C196), January 2020, published by The Open Group; refer to: www.opengroup.org/library/c196.

[6] An Introduction to TOGAF^® 9.1, White Paper (W118), December 2011, published by The Open Group; refer to: www.opengroup.org/library/w118.

[7] An Introduction to the TOGAF^® Standard, Version 9.2, White Paper (W182), April 2018, published by The Open Group; refer to: www.opengroup.org/library/w182.