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.
The phases of the ADM cycle are further divided into steps; for example, the steps within the
Technology Architecture phase are as follows:
■ 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
