TOGAF standard

Core concepts
?What is the TOGAF Standard
The TOGAF standard is an architecture
framework. It 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
?What is Architecture in the Context of the TOGAF Standard

:ISO/IEC/IEEE 42010: 2011 defines "architecture" as

The fundamental concepts or properties of a"
system in its environment embodied in its
elements, relationships, and in the principles of its
".design and evolution
The TOGAF standard embraces but does not strictly
adhere to ISO/IEC/IEEE 42010: 2011
terminology. In addition to the ISO/IEC/IEEE 42010:
2011 definition of "architecture", the TOGAF
standard defines a second meaning depending
upon the context "The structure of components,
their inter-relationships, and the principles and
guidelines governing their design and evolution
".over time
?What is Architecture in the Context of the TOGAF Standard

The TOGAF standard considers the enterprise

as a system and endeavors to strike a
balance
between promoting the concepts and
terminology drawn from relevant standards,
and commonly accepted terminology that is
familiar to the majority of the TOGAF
.readership
For more on terminology, refer to Chapter 3
.and Part IV, Chapter 31
?What Kind of Architecture Does the TOGAF Standard Deal With

There are four architecture domains that are

commonly accepted as subsets of an overall
Enterprise Architecture, all of which the TOGAF
:standard is designed to support
The Business Architecture defines the ■
business strategy, governance, organization, and
key business processes
The Data Architecture describes the ■
structure of an organization’s logical and physical
data assets and data management resources
?What Kind of Architecture Does the TOGAF Standard Deal With

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
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
Architecture Development
Method
: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 the TOGAF framework and
definition of Architecture Principles

Phase A: Architecture Vision describes ■

the initial phase of an architecture
development
cycle
Architecture Development
Method
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
Architecture Development
Method
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 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
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, Chapter 29) 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
Deliverables, Artifacts, and
Building Blocks
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
Deliverables, Artifacts, and
Building Blocks
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
Deliverables, Artifacts, and
Building Blocks
A building block represents a (potentially re-usable)
component of enterprise 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
Deliverables, Artifacts, and
Building Blocks
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
Relationships between Deliverables, Artifacts, and Building
Blocks
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 process (a
building block). This artifact may also describe other
building blocks, such as the actors involved in the process
.(e.g., a Customer Services Representative)
An example of the relationships between
deliverables, artifacts, and building blocks is illustrated in
.Figure 29-2
Enterprise Continuum
The TOGAF standard includes the concept of the
Enterprise Continuum, which sets the broader context for
an architect and explains how generic solutions can be
leveraged and specialized in order to support the
.requirements of an individual organization

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

The Enterprise Continuum comprises two complementary

:concepts
.The Architecture Continuum and the Solutions Continuum
Enterprise Continuum
Architecture Repository

Supporting the Enterprise Continuum is the concept

of an Architecture Repository which can be used to
store different classes of architectural output at
.different levels of abstraction, created by the ADM

in this way, the TOGAF standard facilitates

understanding and co-operation between
stakeholders and practitioners at different levels By
means of the Enterprise Continuum and Architecture
Repository, architects are encouraged to leverage all
other relevant architectural resources and assets in
.developing an Organization- Specific Architecture
Architecture Repository
In this context, the TOGAF ADM can be regarded as
describing a process lifecycle that operates at multiple
levels within the organization, operating within a
holistic governance framework and producing aligned
.outputs that reside in an Architecture Repository

The Enterprise Continuum provides a valuable context

for understanding architectural models: it shows
building blocks and their relationships to each other,
and the constraints and requirements on a cycle of
.architecture development

The structure of the TOGAF Architecture Repository is

.shown in Figure 2-4
Architecture Repository
Architecture Repository
The major components within an Architecture
:Repository are as follows
The Architecture Metamodel describes the ■
organizationally tailored application of an architecture
framework, including a metamodel for architecture
content
The Architecture Capability defines the ■
parameters, structures, and processes that support
governance of the Architecture Repository
The Architecture Landscape is the architectural ■
representation of assets deployed within the operating
enterprise at a particular point in time — the landscape
is likely to exist at multiple levels of abstraction to suit
different architecture objectives
Architecture Repository
The Standards Information Base (SIB)
captures the standards with which new
architectures must comply, which may include
industry standards, selected products and
services from suppliers, or shared services
already deployed within the organization
The Reference Library provides guidelines, ■
templates, patterns, and other forms of reference
material that can be leveraged in order to
accelerate the creation of new architectures for
the enterprise
The Governance Log provides a record of ■
governance activity across the enterprise
Architecture Repository
The Architecture Requirements
Repository provides a view of all authorized
architecture
requirements which have been agreed with
the Architecture Board

The Solutions Landscape presents an ■

architectural representation of the SBBs
supporting the Architecture Landscape which
have been planned or deployed by the
enterprise
Establishing and Maintaining an Enterprise Architecture Capability

In order to carry out architectural activity

effectively within an enterprise, it is
necessary to put in place an appropriate
business capability for architecture, through
organization structures, roles, responsibilities,
skills, and processes. An overview of the
TOGAF Architecture Capability
.is shown in Figure 2-5
Establishing and Maintaining an
Enterprise Architecture Capability
Establishing the Architecture Capability as an Operational Entity

Barring Architecture Capabilities set up to purely

support change delivery programs, it is increasingly
recognized that a successful Enterprise Architecture
practice must sit on a firm
.operational footing

In effect, an Enterprise Architecture practice must be

run like any other operational unit within a business;
i.e., it should be treated like a business. To this end,
and over and above the core processes defined
within the ADM, an Enterprise Architecture practice
:should establish capabilities in the following areas
Establishing the Architecture
Capability as an Operational Entity
Financial Management
Performance Management ■
Service Management ■
Risk Management (see Section A.54) ■
Resource Management ■
Communications and Stakeholder Management ■
(see Section 3.33)
Quality Management ■
Supplier Management (see Section A.60) ■
Configuration Management (see Section A.7) ■
Environment Management ■
Establishing the Architecture
Capability as an Operational Entity
Central to the notion of operating an ongoing
architecture is the execution of well-defined and
effective governance, whereby all architecturally
significant activity is controlled and aligned
.within a single framework

As governance has become an increasingly visible

,requirement for organizational management
the inclusion of governance within the TOGAF standard
aligns the framework with current
business best practice and also ensures a level of
visibility, guidance, and control that will support all
.architecture stakeholder requirements and obligations
Establishing the Architecture
Capability as an Operational Entity
:The benefits of Architecture Governance include
Increased transparency of accountability, and ■
informed delegation of authority
Controlled risk management ■
Protection of the existing asset base through ■
maximizing re-use of existing architectural
components
Proactive control, monitoring, and management ■
mechanisms
Process, concept, and component re-use across all ■
organizational business units
Value creation through monitoring, measuring, ■
evaluation, and feedback
Establishing the Architecture
Capability as an Operational Entity
Increased visibility supporting internal processes ■
and external parties’ requirements; in particular,
increased visibility of decision-making at lower levels
ensures oversight at an appropriate level within the
enterprise of decisions that may have far-reaching
.strategic consequences for the organization

Greater shareholder value; in particular, Enterprise ■

Architecture increasingly represents
the core intellectual property of the enterprise —
studies have demonstrated a correlation
between increased shareholder value and well-
governed enterprises
Establishing the Architecture
Capability as an Operational Entity
Integrates with existing processes and ■
methodologies and complements
functionality by adding control capabilities
Further detail on establishing an Enterprise
Architecture Capability is given in Part VI,
. Chapter 39
Using the TOGAF Standard with Other Frameworks

Two of the key elements of any Enterprise Architecture

:framework are

A definition of the deliverables that the architecting activity ■

.should produce
A description of the method by which this should be done ■
With some exceptions, the majority of Enterprise Architecture
frameworks focus on the first of these — the specific set of
deliverables — and are relatively silent about the methods to be
used to generate them (intentionally so, in some cases)

Because the TOGAF standard is a generic framework and

intended to be used in a wide variety
of environments, it provides a flexible and extensible content
framework that underpins a set of
.generic architecture deliverables
Using the TOGAF Standard with Other
Frameworks
As a result, the TOGAF framework may be used either in its
own right, with the generic deliverables that it describes; or
else these deliverables may be replaced or extended by a
more specific set, defined in any
.other framework that the architect considers relevant

In all cases, it is expected that the architect will adapt and

build on the TOGAF framework in order to define a tailored
method that is integrated into the processes and
organization structures of the enterprise. This architecture
tailoring may include adopting elements from other
architecture frameworks, or integrating TOGAF methods
with other standard frameworks or best practices, such as
.®ITIL®, CMMI®, COBIT®, PRINCE2®, PMBOK®, and MSP
.
Using the TOGAF Standard with Other
Frameworks

As a generic framework and method for Enterprise

Architecture, the TOGAF standard provides the
capability and the collaborative environment to
.integrate with other frameworks

Organizations are able to fully utilize vertical

business domains, horizontal technology areas
or application ,)such as security or manageability(
areas (such as e-Commerce) to produce a
competitive Enterprise Architecture framework
.which maximizes their business opportunities