For the purposes of TOGAF 9, the release notes provided in this chapter apply.

4.1 What's New in TOGAF 9?

This section provides an overview of the major new features within TOGAF 9.

Modular Structure

One focus of TOGAF 9 development has been to ensure that the specification content is structured in a modular way. The modular seven-part structure of TOGAF allows for the concepts in each part to be developed with limited impacts on other parts. Content that was contained within the TOGAF 8.1.1 Resource Base has been classified and moved into parts that have a defined purpose (as opposed to generic "resources").

The modular structure in TOGAF is intended to support greater usability, as each part has a defined purpose and can be read in isolation as a stand-alone set of guidelines. The modular structure is also expected to support incremental adoption of the TOGAF specification. Finally, the modular structure supports more sophisticated release management of the TOGAF specification. In future, individual parts may evolve at different speeds and the current specification structure is intended to allow changes in one area to take place with limited impacts across the specification.

Content Framework

A significant addition of new content to the TOGAF specification is the content framework. The TOGAF content framework provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent. The intention of including a content framework within TOGAF is to drive greater consistency in the outputs that are created when following an Architecture Development Method (ADM).

The benefit of including a content framework applies at a number of levels. Firstly, within a single architecture development initiative the content framework provides a comprehensive checklist of architecture outputs that could be created and consequently reduce the risk of gaps within the final architecture deliverable set.

The second major benefit of inclusion of a content framework applies when attempting to integrate architectural work products across an enterprise. The content framework is intended to be adapted and then adopted by an enterprise in order to mandate standard architectural concepts, terms, and deliverables. If all architecture initiatives use the same models for content, their outputs can be combined much more easily than in situations where each architect uses a completely different approach.

Finally, a substantial benefit of the inclusion of a content framework within TOGAF is that it provides (for the first time) a detailed open standard for how architectures should be described. The existence of this standard allows tools vendors, product vendors, and service vendors to adopt consistent ways of working, which in turn will result in greater consistency between architecture tools, better tool interoperability, more consistent reference architectures, and better comparability between related reference architectures.

Extended Guidance on Adopting TOGAF within an Enterprise

Within larger organizations, the practice of enterprise architecture requires a number of individuals and teams that work together on many architectures. Although each architecture will address a specific problem, in an ideal situation architectures can be considered as a group in order to develop an overall integrated view of how the enterprise is changing.

This version of TOGAF features an extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures being developed by teams that operate within an overarching architectural governance model. In particular, the following concepts are introduced:

• Partitioning: In order to develop architectures that have manageable levels of cost and complexity, it is necessary to partition the enterprise into specific architectures. TOGAF discusses the concept of partitioning and provides a variety of techniques and considerations on how to partition the various architectures within an enterprise.
• Architecture Repository: TOGAF provides a logical information model for an Architecture Repository, which can be used as an integrated store for all outputs created by executing the ADM.
• Capability Framework: This version of TOGAF provides a more structured definition of the organization, skills, roles, and responsibilities required to operate an effective enterprise Architecture Capability. The new TOGAF materials also provide guidance on a process that can be followed to identify and establish an appropriate Architecture Capability.

Explicit Consideration of Architectural Styles, Including SOA and Security Architecture

The new Part III: ADM Guidelines and Techniques brings together a set of supporting materials that show in more detail how the ADM can be applied to specific situations. The new guidelines discuss:

• The varying uses of iteration that are possible within the ADM and when each technique should be applied
• The linkages between the TOGAF ADM and Service Oriented Architecture (SOA)
• The specific considerations required to address security architecture within the ADM
• The various types of architecture development required within an enterprise and how these relate to one another

Additional ADM Detail

This version of the TOGAF specification includes more detailed information supporting the execution of the ADM. Particular areas of enhancement are:

• The Preliminary Phase, which features extended guidance on establishing an enterprise architecture framework and planning for architecture development. The extended Preliminary Phase also provides pointers to the definition of a governance model for architecture benefit realization and also discusses the linkage between TOGAF and other management frameworks.
• The Opportunities & Solutions phase and Migration Planning phase, which feature a more detailed and robust method for defining and planning enterprise transformation, based on the principles of capability-based planning.

4.1.1 Changes Applied in this Edition

This edition of TOGAF 9 includes a set of maintenance updates based on feedback received on the 2009 publication. A separate detailed document of the changes is available as TOGAF 9 Technical Corrigendum No. 1 (Document U112). A summary list of the changes is included below:

• Definitions of terms where usage by TOGAF is not distinctive from the common dictionary definition have been removed.
• The usage of the terms "application" versus "system" have been reviewed and made consistent.
• The Phase E and F descriptions have been reworked to match the level of detail in other phases.
• The uses of terminology for Transition Architecture/Roadmap/Implementation Strategy have been clarified and made consistent.
• The concepts of levels/iterations/partitions have been clarified and made consistent. This includes a reorganization of material in Part III, 19. Applying Iteration to the ADM and 20. Applying the ADM across the Architecture Landscape, and Part V, 40. Architecture Partitioning.
• The "Objectives" sections of the phases have been reworked to focus on actual objectives rather than techniques or a list of steps.
• The possible artifacts (viewpoints) for each phase are now listed in the description of that phase, not just in Part IV, 35. Architectural Artifacts.
• The terms "artifact" versus "viewpoint" have been clarified and made consistent. This includes a restructuring of Part IV, 35. Architectural Artifacts.
• The SOA chapter (Part III, 22. Using TOGAF to Define & Govern SOAs) has been updated to describe the latest SOA Work Group output.
• Additional introductory text on architectural styles has been added in Part III, 18. Introduction.
• Minor changes have been made to the Security Architecture chapter (Part III, 21. Security Architecture and the ADM) for consistency with the ADM.
• Corrections have been made to metamodel diagrams.
• Corrections have been applied to aspects of the metamodel.
• The Building Blocks example has been removed.
• The Document Categorization Model has been removed.
• Duplicate text in several places has been replaced with an appropriate reference:
  • Gap Analysis in Phases B, C, and D now references Part III, 27. Gap Analysis.
  • Requirements Management in several phases now references Part II, 17.2.2 Requirements Development in the Requirements Management phase.
• Some of the artifacts have been renamed to better reflect their usage:
  • System/Data matrix becomes Application/Data matrix
  • Class diagram has been replaced with Conceptual Data diagram and Logical Data diagram
  • System/Organization matrix becomes Application/Organization matrix
  • Role/System matrix becomes Role/Application matrix
  • System/Function matrix becomes Application/Function matrix
  • Process/System Realization diagram becomes Process/Application Realization diagram
  • System Use-Case diagram becomes Application Use-Case diagram
  • System/Technology matrix becomes Application/Technology matrix
• The description of Architecture Principles now divides them into two types only - Enterprise and Architecture - whereas before they called out IT Principles separately. IT Principles are now seen as just part of Enterprise Principles.
• The Stakeholder Map included in the Stakeholder Management chapter (Part III, 24. Stakeholder Management) is now explicitly referred to as an example, the table has been highlighted to refer to Stakeholder Concerns, and the list of artifacts for each stakeholder updated.
• The Business Scenarios chapter (Part III, 26. Business Scenarios and Business Goals) has been renamed to Business Scenarios and Business Goals to better reflect the contents of the chapter.
• The relationship of the Enterprise Repository to the Architecture Repository is clarified in Part V, 41. Architecture Repository.
• The Evaluation Criteria and Guidelines have been removed from Part V, 42. Tools for Architecture Development.
• The chapter on Architecture Maturity Models (Part VII, 51. Architecture Maturity Models) has been editorially revised for consistency and clarity.

4.2 The Benefits of TOGAF 9

TOGAF 9 provides a wide-ranging set of revisions to the TOGAF specification. When combined, these edits seek to achieve a set of objectives to improve the value of the TOGAF framework.

Greater Usability

A number of enhancements within TOGAF 9 support greater usability of the overall specification. Firstly, the modular structure of the specification makes it easier for an architect to consider a specific aspect of the Architecture Capability. In all areas, the specification seeks to add detail and clarity above and beyond previous TOGAF versions.

More Focus on Holistic Enterprise Change

TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change. However, as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model. TOGAF 9 continues this evolution and incorporates a broader perspective of change that allows enterprise architecture to be used to specify transformation across the business, data, application, and technology domains.

More Consistency of Output

Previous versions of TOGAF focused on providing a consistent process for developing architectures. TOGAF 9 includes a greatly enhanced consideration of architectural work products to ensure that a consistent process is used to produce consistent outputs. The Architecture Content Framework provides a detailed model of the outputs to be created by the ADM. Additionally, the Enterprise Continuum, Architecture Partitioning, and Architecture Repository sections provide detailed guidance on how architectural deliverables can be scoped, governed, and integrated.

4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9

Listed below are the Parts of the TOGAF 8 specification. For each Part, a description is given to explain where the TOGAF 8 content can be found within the current specification.

Part I: Introduction

The Introduction part of the TOGAF 8.1.1 specification has been used as the basis for creation of Part I: Introduction in TOGAF 9. The introduction to TOGAF 9 reflects the content of TOGAF 9 rather than the content of TOGAF 8.1.1, and also features a number of enhancements to improve accessibility.

Part II: Architecture Development Method

The essence of the TOGAF 8.1.1 ADM has been retained in TOGAF 9. Part II: Architecture Development Method (ADM) within TOGAF 9 is structured along similar lines to Part II of the TOGAF 8.1.1 document. TOGAF ADM phase inputs and outputs (Chapter 16 of TOGAF 8.1.1) have been moved from the ADM section of TOGAF 8.1.1 to Part IV: Architecture Content Framework of TOGAF 9.

TOGAF 9 ADM features additional content in the majority of ADM phases, which in the most part adds further detail and clarification to the same approach that was described in TOGAF 8.1.1.

Part III: Enterprise Continuum

The TOGAF 8.1.1 Enterprise Continuum has seen a substantial degree of change. The Enterprise Continuum concept is retained within Part V: Enterprise Continuum & Tools. The TOGAF Technical Reference Model and Integrated Information Infrastructure Reference Model are extracted and placed within Part VI: TOGAF Reference Models in TOGAF 9.

TOGAF 9 adds new materials that describe an approach to architecture partitioning and also provides a structured model of an Architecture Repository. These concepts support and elaborate on the original intent of the Enterprise Continuum.

TOGAF 9 removes the Standards Information Base from the TOGAF specification. However, an example SIB remains at The Open Group web site (www.opengroup.org). The concept of a Standards Information Base is important within TOGAF, but the breadth and speed of change of relevant architectural standards mean that it is impractical to maintain a current and relevant collection of standards within a specification such as TOGAF.

Part IV: Resource Base

The Resource Base is not included in this version of TOGAF. Some elements of the Resource Base have been deprecated from the TOGAF specification, but will still be available in White Paper form. Other elements of the Resource Base have been moved to other areas of the specification.

The following table illustrates where TOGAF 8.1.1 Resource Base content can now be located.

4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1

The following table illustrates where TOGAF 9 chapters map to those of TOGAF 8.1.1:

4.5 Using TOGAF

4.5.1 Conditions of Use

The TOGAF documentation is freely available for viewing online without a license. Alternatively, the complete TOGAF documentation set may be downloaded and stored under license, as explained on the TOGAF information web site.

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

4.5.2 How Much Does TOGAF Cost?

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

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

The Open Group therefore publishes TOGAF on its public web server, and allows and encourages its reproduction and use free-of-charge by any organization wishing to use it internally to develop an enterprise architecture. (There are restrictions on its commercial exploitation, however; see 4.5.1 Conditions of Use.)

4.5.3 Downloads

Downloads of the TOGAF documentation, including a printable PDF file, are available under license from the TOGAF information web site (refer to www.opengroup.org/architecture/togaf). The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an enterprise architecture for use within that organization).

4.6 Why Join The Open Group?

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

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

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

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

Members of the Architecture Forum gain:

• Immediate access to the fruits of the current TOGAF work program (not publicly available until publication of the next edition of the TOGAF document) - in effect, the latest information on TOGAF
• Exchange of experience with other customer and vendor organizations involved in enterprise architecture in general, and networking with architects using TOGAF in significant architecture development projects around the world
• Peer review of specific architecture case study material

return to top of page