Unformatted text preview: Welcome to TOGAF® Version 9.1, an Open Group Standard
1.1 Structure of the TOGAF Document | 1.2 Executive Overview TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise
architecture. It may be used freely by any organization wishing to develop an enterprise architecture for
use within that organization (see 4.5.1 Conditions of Use).
TOGAF is developed and maintained by members of The Open Group, working within the Architecture
Forum (refer to ). The original development of TOGAF Version 1 in 1995
was based on the Technical Architecture Framework for Information Management (TAFIM), developed by
the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and
encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of
development effort and many millions of dollars of US Government investment.
Starting from this sound foundation, the members of The Open Group Architecture Forum have
developed successive versions of TOGAF and published each one on The Open Group public web site.
If you are new to the field of enterprise architecture and/or TOGAF, you are recommended to read the
Executive Overview (refer to 1.2 Executive Overview), where you will find answers to questions such as: What is an enterprise?
Why do I need an enterprise architecture?
Why do I need TOGAF as a framework for enterprise architecture? 1.1 Structure of the TOGAF Document
The structure of the TOGAF documentation reflects the structure and content of an Architecture
Capability within an enterprise, as shown in Figure 1-1. PART I
(Introduction) This part provides a high-level introduction to the key concepts of enterprise
architecture and in particular the TOGAF approach. It contains the definitions of terms used
throughout TOGAF and release notes detailing the changes between this version and the
previous version of TOGAF.
(Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF
Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise
(ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques
available for use in applying TOGAF and the TOGAF ADM.
PART IV (Architecture Content Framework) This part describes the TOGAF content framework, including a
structured metamodel for architectural artifacts, the use of re-usable architecture building blocks,
and an overview of typical architecture deliverables.
(Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to
categorize and store the outputs of architecture activity within an enterprise.
(TOGAF Reference Models) This part provides a selection of architectural reference models,
which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure
Reference Model (III-RM).
(Architecture Capability Framework) This part discusses the organization, processes, skills, roles,
and responsibilities required to establish and operate an architecture function within an
The intention of dividing the TOGAF specification into these independent parts is to allow for different
areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts
work together as a whole, it is also feasible to select particular parts for adoption while excluding others.
For example, an organization may wish to adopt the ADM process, but elect not to use any of the
materials relating to Architecture Capability.
As an open framework, such use is encouraged, particularly in the following situations: Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are
expected to focus on particular parts of the specification for initial adoption, with other areas
tabled for later consideration.
Organizations that have already deployed architecture frameworks may choose to merge these
frameworks with aspects of the TOGAF specification. 1.2 Executive Overview
This section provides an executive overview of enterprise architecture, the basic concepts of what it is
(not just another name for IT Architecture), and why it is needed. It provides a summary of the benefits of
establishing an enterprise architecture and adopting TOGAF to achieve that. What is an enterprise?
TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For
example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a
single department, or a chain of geographically distant organizations linked together by common
The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire
enterprise - encompassing all of its information and technology services, processes, and infrastructure and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and
multiple functional groups within the enterprise. Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise
nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended
enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal
The business operating model concept is useful to determine the nature and scope of the enterprise
architecture within an organization. Large corporations and government agencies may comprise multiple
enterprises, and may develop and maintain a number of independent enterprise architectures to address
each one. However, there is often much in common about the information systems in each enterprise,
and there is usually great potential for gain in the use of a common architecture framework. For example,
a common framework can provide a basis for the development of an Architecture Repository for the
integration and re-use of models, designs, and baseline data. Why do I need an enterprise architecture?
The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of
processes (both manual and automated) into an integrated environment that is responsive to change and
supportive of the delivery of the business strategy.
Today's CEOs know that the effective management and exploitation of information through IT is a key
factor to business success, and an indispensable means to achieving competitive advantage. An
enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT
system in response to the constantly changing needs of the business environment.
Furthermore, a good enterprise architecture enables you to achieve the right balance between IT
efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of
competitive advantage. At the same time, it ensures the needs of the organization for an integrated IT
strategy are met, permitting the closest possible synergy across the extended enterprise.
The advantages that result from a good enterprise architecture bring important business benefits, which
are clearly visible in the net profit or loss of a company or organization: A more efficient business operation:
o Lower business operation costs
o More agile organization
o Business capabilities shared across the organization
o Lower change management costs
o More flexible workforce
o Improved business productivity
A more efficient IT operation:
o Lower software development, support, and maintenance costs
o Increased portability of applications
o Improved interoperability and easier system and network management
o Improved ability to address critical enterprise-wide issues like security
o Easier upgrade and exchange of system components
Better return on existing investment, reduced risk for future investment:
o Reduced complexity in the business and IT
o Maximum return on investment in existing business and IT infrastructure
o The flexibility to make, buy, or out-source business and IT solutions
o Reduced risk overall in new investments and their cost of ownership
Faster, simpler, and cheaper procurement:
o Buying decisions are simpler, because the information governing procurement is readily
available in a coherent plan o
o The procurement process is faster - maximizing procurement speed and flexibility without
sacrificing architectural coherence
The ability to procure heterogeneous, multi-vendor open systems
The ability to secure more economic capabilities What specifically would prompt me to develop an enterprise architecture? Typically, preparation for business transformation needs or for radical infrastructure changes initiates an
enterprise architecture review or development. Often key people identify areas of change required in
order for new business goals to be met. Such people are commonly referred to as the "stakeholders" in
the change. The role of the architect is to address their concerns by: Identifying and refining the requirements that the stakeholders have
Developing views of the architecture that show how the concerns and requirements are going to
Showing the trade-offs that are going to be made in reconciling the potentially conflicting
concerns of different stakeholders Without the enterprise architecture, it is highly unlikely that all the concerns and requirements will be
considered and met.
What is an architecture framework? An architecture framework is a foundational structure, or set of structures, which can be used for
developing a broad range of different architectures. It should describe a method for designing a target
state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit
together. It should contain a set of tools and provide a common vocabulary. It should also include a list of
recommended standards and compliant products that can be used to implement the building blocks.
Why do I need TOGAF as a framework for enterprise architecture? TOGAF has been developed through the collaborative efforts of over 300 Architecture Forum member
companies from some of the world's leading companies and organizations. Using TOGAF results in
enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practice, and
gives due consideration both to current requirements and the perceived future needs of the business.
Developing and sustaining an enterprise architecture is a technically complex process which involves
many stakeholders and decision processes in the organization. TOGAF plays an important role in
standardizing and de-risks the architecture development process. TOGAF provides a best practice
framework for adding value, and enables the organization to build workable and economic solutions which
address their business issues and needs.
Who would benefit from using TOGAF? Any organization undertaking, or planning to undertake, the development and implementation of an
enterprise architecture for the support of business transformation will benefit from use of TOGAF.
Organizations seeking Boundaryless Information Flow can use TOGAF to define and implement the
structures and processes to enable access to integrated information within and between enterprises.
Organizations that design and implement enterprise architectures using TOGAF are assured of a design
and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk.
return to top of page 2. Core Concepts
2.1 What is TOGAF? | 2.2 What is Architecture in the Context of TOGAF? | 2.3 What Kind of Architecture Does
TOGAF Deal With? | 2.4 Architecture Development Method | 2.5 Deliverables, Artifacts, and Building Blocks | 2.6
Enterprise Continuum | 2.7 Architecture Repository | 2.8 Establishing and Maintaining an Enterprise Architecture
Capability | 2.9 Establishing the Architecture Capability as an Operational Entity | 2.10 Using TOGAF with Other
Frameworks For the purposes of TOGAF 9, the core concepts provided in this chapter apply. 2.1 What is TOGAF?
TOGAF is an architecture framework. TOGAF provides the methods and tools for assisting in the
acceptance, production, use, and maintenance of an enterprise 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
2. The structure of components, their inter-relationships, and the principles and guidelines governing
their design and evolution over time
TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the
concepts and terminology of ISO/IEC 42010:2007 - ensuring that 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 3. Definitions and Part
IV, 35. Architectural Artifacts. 2.3 What Kind of Architecture Does TOGAF Deal With?
There are four architecture domains that are commonly accepted as subsets of an overall enterprise
architecture, all of which TOGAF is designed to support: The Business Architecture defines the business strategy, governance, organization, and key
The Data Architecture describes the structure of an organization's logical and physical data
assets and data management resources.
The Application Architecture provides a blueprint for the individual applications to be deployed,
their interactions, and their relationships to the core business processes of the organization.
The Technology Architecture describes the logical software and hardware capabilities that are
required to support the deployment of business, data, and application services. This includes IT
infrastructure, middleware, networks, communications, processing, standards, etc. 2.4 Architecture Development Method
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for
developing 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 transform their enterprises in a controlled manner in response to
business goals and opportunities.
Phases within the ADM are as follows: The Preliminary Phase describes the preparation and initiation activities required to create an
Architecture Capability including customization of TOGAF and definition of Architecture Principles.
Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It
includes information about defining the scope of the architecture development initiative,
identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed
with the architecture development.
Phase B: Business Architecture describes the development of a Business Architecture to
support the agreed Architecture Vision.
Phase C: Information Systems Architectures describes the development of Information
Systems Architectures to support the agreed Architecture Vision.
Phase D: Technology Architecture describes the development of the Technology Architecture
to support the agreed Architecture Vision.
Phase E: Opportunities & Solutions conducts initial implementation planning and the
identification of delivery vehicles for the architecture defined in the previous phases.
Phase F: Migration Planning addresses how to move from the Baseline to the Target
Architectures by finalizing a detailed Implementation and Migration Plan.
Phase G: Implementation Governance provides an architectural oversight of the
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 Deliverables, Artifacts, and Building Blocks
Architects executing the ADM will produce a number of outputs as a result of their efforts, such as
process flows, architectural requirements, project plans, project compliance assessments, etc. The
TOGAF Architecture Content Framework (see Part IV, 33. Introduction) provides a structural model for
architectural content that allows major work products to be consistently defined, structured, and
presented. The Architecture Content Framework uses the following three categories to describe the type of
architectural work product within the context of use: A deliverable is a work product that is contractually specified and in turn formally reviewed,
agreed, and signed off by the stakeholders. Deliverables represent the output of projects and
those deliverables that are in documentation form will typically be archived at completion of a
project, or transitioned into an Architecture Repository as a reference model, standard, or
snapshot of the Architecture Landscape at a point in time.
An artifact is an architectural work product that describes an aspect of the architecture. Artifacts
are generally classified as catalogs (lists of things), matrices (showing relationships between
things), and diagrams (pictures of things). Examples include a requirements catalog, business
interaction matrix, and a use-case diagram. An architectural deliverable may contain many
artifacts and artifacts will form the content of the Architecture Repository.
A building block represents a (potentially re-usable) component of business, IT, or architectural
capability that can be combined with other building blocks to deliver architectures and solutions.
Building blocks can be defined at various levels of detail, depending on what stage of architecture
development has been reached. For instance, at an early stage, a building block can simply
consist of a name or an outline description. Later on, a building block may be decomposed into
multiple supporting building blocks and may be accompanied by a full specification. Building
blocks can relate to "architectures" or "solutions".
o o Architecture Building Blocks (ABBs) typically describe required capability and shape
the specification of Solution Building Blocks (SBBs). For example, a customer services
capability may be required within an enterprise, supported by many SBBs, such as
processes, data, and application software.
Solution Building Blocks (SBBs) represent components that will be used to implement
the required capability. For example, a network is a building block that can be described
through complementary artifacts and then put to use to realize solutions for the
enterprise. The relationships between deliverables, artifacts, and building blocks are shown in Figure 2-1. Figure 2-1: Relationships between Deliverables, Artifacts, and Building Blocks
For example, an Architecture Definition Document is a deliverable that documents an architecture
description. This document will contain a number of complementary artifacts that are views of the building
blocks relevant to the architecture. For example, a process flow diagram (an artifact) may be created to
describe the target call handling pro...
View Full Document