Core Concepts 

2.1 What is TOGAF?

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

        
2.2 What is Architecture in the Context of TOGAF?

       ISO/IEC 42010: 2007 defines ‘‘architecture’’ as:

              ‘‘The fundamental organization of a system, embodied in its components, their
                    relationships to each other and the environment, and the principles governing its design
                 and evolution.’’

        TOGAF embraces but does not strictly adhere to ISO/IEC 42010: 2007 terminology. In TOGAF,
      ‘‘architecture’’ has two meanings depending upon the context:

             1. A formal description of a system, or a detailed plan of the system at component level to
                 guide its implementation
             2. The str ucture of components, their inter-relationships, and the principles and guidelines
                governing their design and evolution over time

    In TOGAF we endeavor to str ike a balance between promoting the concepts and terminology of
    ISO/IEC 42010: 2007 — ensuring that our usage of terms defined by ISO/IEC 42010: 2007 is
    consistent with the standard — and retaining other commonly accepted terminology that is
    familiar to the majority of the TOGAF readership. For more on terminology, refer to Chapter 3

2.3 What Kind of Architecture Does TOGAF Deal With?

        There are four architecture domains that are commonly accepted as subsets of an overall
        enter prise architecture, all of which TOGAF is designed to support:

            ■ The Business Architecture defines the business strategy, gover nance, organization, and key                        business processes.

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

            ■ The Application Architecture provides a bluepr int for the individual application systems to
                be deployed, their interactions, and their relationships to the core business processes of
                the organization.
            ■ The Technology Architecture descr ibes the logical software and hardware capabilities
                that are required to support the deployment of business, data, and application services.
               This includes IT infrastr ucture, middleware, networ ks, communications, processing,
                standards, etc.

2.4 Architecture Development Method

      The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process
      for dev eloping architectures. The ADM includes establishing an architecture framework,
      developing architecture content, transitioning, and governing the realization of architectures.
      All of these activities are carried out within an iterative cycle of continuous architecture definition
      and realization that allows organizations to transfor m their enterpr ises in a controlled manner in
      response to business goals and opportunities.

      Phases within the ADM are as follows:

            ■ The Preliminar y Phase descr ibes the preparation and initiation activities required to
                prepare to meet the business directive for a new enter prise architecture, including the
                definition of an Organization-Specific Architecture framework and the definition of
                pr inciples.
            ■ Phase A: Architecture Vision descr ibes the initial phase of an architecture development
                cycle. It includes infor mation about defining the scope, identifying the stakeholders,
                creating the Architecture Vision, and obtaining approvals.
            ■ Phase B: Business Architecture descr ibes the development of a Business Architecture
                to support an agreed Architecture Vision.
            ■ Phase C: Information Systems Architectures descr ibes the development of Infor mation
                Systems Architectures for an architecture project, including the development of Data and
                Application Architectures.
            ■ Phase D: Technology Architecture descr ibes the development of the Technology
                Architecture for an architecture project.
            ■ Phase E: Oppor tunities & Solutions conducts initial implementation planning and the
                identification of deliver y vehicles for the architecture defined in the previous phases.                           ■ Phase F: Migration Planning addresses the for mulation of a set of detailed sequence                                of transition architectures with a supporting Implementation and Migration Plan.                                ■ Phase G: Implementation Governance provides an architectural oversight of                                            the implementation.                                                                                                                                  ■ Phase H: Architecture Change Management establishes procedures for managing change to                    the new architecture.                                                                                                                                  ■ Requirements Management examines the process of managing architecture requirements                        throughout the ADM.

2.5 TOGAF Document Categorization Model

      A TOGAF document categorization model exists to structure the release management of the
      TOGAF specification. It is not intended to serve as an implementation guide for practitioners.

         Within the model, the content of the TOGAF document is categorized according to the following
         four categories:
                ■ TOGAF Core consists of the fundamental concepts that for m the essence of TOGAF.
                ■ TOGAF Mandated consists of the normative par ts of the TOGAF specification. These
                    elements of TOGAF are central to its usage and without them the framework would not be
                    recognizably TOGAF. Strong consideration must be given to these elements when applying
                    TOGAF.                                                                                                                                                  ■ TOGAF Recommended consists of a pool of resources that are specifically referenced                            in TOGAF as ways in which the TOGAF Core and Mandated processes can be                                        accomplished (e.g., the SEI Architecture Trade-Off Analysis Method or business                                    scenarios).                                                                                                                                               ■ TOGAF Supporting consists of additional resources that are not referenced in the                                    other three TOGAF categories itself but provide valuable assistance.

Release Notes

3.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 str uctured         in a modular way. The modular seven-par t str ucture of TOGAF allows for the concepts in each              part to be dev eloped 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 wor k 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 wor k products across an enterpr ise. The content framework is intended to
      be adapted and then adopted by an enter prise in order to mandate standard architectural
      concepts, ter ms, 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 wor king, 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.

3.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, consider ing the ways in which IT can support
        enter prise change. How ever, as TOGAF has grown in depth and maturity it has become a
        framework for managing the entire spectrum of change required to transfor m an enterpr ise
        towards a target operating model. TOGAF 9 continues this evolution and incorporates a broader
        perspective of change that allows enterpr ise architecture to be used to specify transfor mation
        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 wor k
        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 Enterpr ise Continuum, Architecture Par titioning, and Architecture
        Repositor y sections provide detailed guidance on how architectural deliverables can be scoped,
        governed, and integrated.

3.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9

        Listed below are the Par ts of the TOGAF 8 specification. For each Par t, a descr iption 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 Par t 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. Par t II: Architecture
        Development Method (ADM) within TOGAF 9 is structured along similar lines to Par t 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 Par t 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 Enterpr ise Continuum has seen a substantial degree of change. The
        Enter prise Continuum concept is retained within Par t V: Enter prise Continuum & Tools. The
        TOGAF Technical Reference Model and Integrated Infor mation Infrastr ucture Reference Model
        are extracted and placed within Par t VI: TOGAF Reference Models in TOGAF 9.

        TOGAF 9 adds new mater ials 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 Enterpr ise Continuum.

        TOGAF 9 removes the Standards Infor mation Base from the TOGAF specification. However, an
        example SIB remains at The Open Group web site (www.opengroup.org). The concept of a
        Standards Infor mation 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 for m. Other elements of the Resource Base have been moved to other areas of the
        specification.

4.1 Using TOGAF

4.1.1 Conditions of Use
        The TOGAF documentation is freely available for viewing online without a license. Alter natively,
        the complete TOGAF documentation set may be downloaded and stored under license, as
        explained on the TOGAF infor mation 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 for m 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 copyr ight owners.

4.1.2 How Much Does TOGAF Cost?

        The Open Group operates as a not-for-profit consortium committed to deliver ing greater
        business efficiency by bringing together buyers and suppliers of infor mation systems to lower the
        barr iers of integrating new technology across the enterpr ise. Its goal is to realize the vision of
        Boundar yless Infor mation Flow.

        TOGAF is a key par t 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 exper ience 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
        inter nally to develop an enterpr ise architecture. (There are restrictions on its commercial
        exploitation, however; see Section 4.5.1.)

4.1.3 Downloads

        Downloads of the TOGAF documentation, including a printable PDF file, are available under
        license from the TOGAF infor mation 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 dev elop an enterpr ise architecture for use within that organization)

4.2 Why Join The Open Group?

        Organizations wishing to reduce the time, cost, and risk of implementing multi-vendor solutions
        that integrate within and between enterpr ises need The Open Group as their key par tner.
        The Open Group brings together the buyers and suppliers of infor mation systems wor ldwide,
        and enables them to wor k together, both to ensure that IT solutions meet the needs of
        customers, and to make it easier to integrate IT across the enterpr ise.

        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 enterpr ise 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 For um, which is the development program
        within which TOGAF is evolved, and in which TOGAF users come together to exchange
        infor mation and feedback.

        Members of the Architecture For um gain:

            ■ Immediate access to the fruits of the current TOGAF wor k program (not publicly available
               until publication of the next edition of the TOGAF document) — in effect, the latest
               infor mation on TOGAF
            ■ Exchange of exper ience with other customer and vendor organizations involved in
                enter prise architecture in general, and networ king with architects using TOGAF in
                significant architecture development projects around the wor ld
            ■ Peer review of specific architecture case study material

 4.3   Architecture Development Cycle

4.3.1 Key Points

        The following are the key points about the ADM:

            ■ The ADM is iterative, over the whole process, between phases, and within phases (see
                Part III, Chapter 19). For each iteration of the ADM, a fresh decision must be taken as to:

                    — The breadth of coverage of the enterpr ise to be defined

                    — The level of detail to be defined

                    — The extent of the time period aimed at, including the number and extent of any
                         inter mediate time periods

                    — The architectural assets to be leveraged, including :

                            — Assets created in previous iterations of the ADM cycle within the enterpr ise

                            — Assets available elsewhere in the industry (other frameworks, systems models,
                                 vertical industry models, etc.)

            ■ These decisions should be based on a practical assessment of resource and competence
                availability, and the value that can realistically be expected to accrue to the enterpr ise from
                the chosen scope of the architecture work.

            ■ As a generic method, the ADM is intended to be used by enter prises in a wide var iety of
                different geographies and applied in different ver tical sectors/industr y types. As such, it
                may be, but does not necessarily have to be, tailored to specific needs. For example, it may
                be used in conjunction with the set of deliverables of another framework, where these have
                been deemed to be more appropriate for a specific organization. (For example, many US
                federal agencies have dev eloped individual frameworks that define the deliverables specific
                to their particular departmental needs.)

4.3.2 Basic Structure

         The basic structure of the ADM is shown in Figure 5-1.

         Throughout the ADM cycle, there needs to be frequent validation of results against the original
         expectations, both those for the whole ADM cycle, and those for the particular phase of the
         process.

            ■ Select reference models, viewpoints, and tools

            ■ Develop Baseline Technology Architecture Description

            ■ Develop Target Technology Architecture Description

            ■ Perfor m gap analysis

            ■ Define roadmap components

            ■ Resolve impacts across the Architecture Landscape

            ■ Conduct for mal stakeholder review

            ■ Finalize the Technology Architecture

            ■ Create Architecture Definition Document