TOGAF

The Open Group

Architecture Framework

http://www.ibm.com/developerworks/librar
y/ar-togaf1/
http://www.slideshare.net/TransformationIn
novation/understanding-and-applying-theUseful Sites
open-group-architecture-framework-togaf368108?src=related_normal&rel=443776

TOGAF stands for The Open Group Architecture

Framework (TOGAF).
It provides a framework and set of supporting tools for
developing an Enterprise Architecture.
Original development of TOGAF was based on TAFIM,
1995, developed by the US Dept. of Defence (DoD). Now
continuously developed by The Open Group Architecture
Forum.
TOGAF documentation is available from
www.opengroup.org/architecture/togaf
Licensing is free for internal company use.

Definition of TOGAF

TOGAF is based on:

An iterative process model
A re-usable set of existing
architecture assets
Supported by architectural best
practices

What is an Open Group

The Open Group, an organization dedicated to
promulgating open standards in industry. For
example, it is The Open Group that maintains
the UNIX standard. This means that if you
want to put out an "industry-standard UNIX,"
you have to be sure it conforms to the
specifications maintained by The Open Group.

Global operation
Cross-Industry
Vendor neutral
What
is an Open
Technology
neutral Group
Brings the key constituencies together in
an open process
Operates the Industrys premier
certification service
country:

Membership by
USA 43.1%
UK 16.9%
India 1.4%
Japan 5.7%

Managed by The Open Group, which has

extensive experience and a track record in
facilitating consensus to develop global
standards such as UNIX, WAP, POSIX, and
LDAP, TOGAF 9 is developed, reviewed, and
approved by a collaboration of over of 300
experts from some of the worlds leading IT
customers and vendors.

A True Global Standard

TOGAF divides an enterprise architecture into four categories, as

follows:

Business architectureDescribes the processes the

business uses to meet its goals
Application architectureDescribes how specific
applications are designed and how they interact with
each other
Data architectureDescribes how the enterprise
datastores are organized and accessed

Enterprise Architecture

Technical architectureDescribes the hardware and

software infrastructure that supports applications and
their interactions

Enterprise-architectural
Many enterprise-architectural
methodologies have come
methodologies
and gone in the last 20 years. At this point, perhaps 90

percent of the field use one of these four methodologies:

The Zachman Framework for Enterprise Architectures

Although self-described as a framework, is actually more
accurately defined as a taxonomy

The Open Group Architectural Framework (TOGAF)

Although called a framework, is actually more accurately
defined as a process

The Federal Enterprise ArchitectureCan be viewed as

either an implemented enterprise architecture or a
proscriptive methodology for creating an enterprise
architecture

The Gartner MethodologyCan be best described as an

enterprise architectural practice

What is an enterprise? What is

enterprise architecture?
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 ownership.
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.
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.

De Facto Standard for EA

Since enterprise architecture was born, a number of
frameworks have come into being, such as Zachman,
FEAF, and DoDAF. All have their strengths and
weaknesses, but none links an enterprise architecture
framework with the process of enterprise architecture
like TOGAF 9 does.
But TOGAF 9 is not just another strategic management
tool that helps you plan your organization's future; it is
rather deeper than that it is thoroughly based on best
practice and is practical and proven.
Uniquely, TOGAF 9 provides a framework and process
to deliver your future vision a join-the-dots guide to
your success.

Enterprise Architecture is..

Enterprise Architecture is

Enterprise Architecture is

Typical problems in Enterprise

Architecture

What specifically would prompt me to develop an

enterprise architecture?
Typically, an enterprise architecture is developed because
key people have concerns that need to be addressed by
the IT systems within the organization. Such people are
commonly referred to as the "stakeholders" in the system.
The role of the architect is to address these concerns, by
identifying and refining the requirements that the
stakeholders have, developing views of the architecture
that show how the concerns and the requirements are
going to be addressed, and by 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.

Why do I need TOGAF as a framework for

enterprise architecture?
TOGAF has been developed through the collaborative
efforts of 300 Architecture Forum member companies
from some of the world's leading IT customers and
vendors and represents best practice in architecture
development.
Architecture design is a technically complex process, and
the design of heterogeneous, multi-vendor architectures
is particularly complex. TOGAF plays an important role in
helping to "de-mystify" and de-risk the architecture
development process.

TOGAF history and

development
The Open Group Architecture Framework
First version of TOGAF launched in 1995 originally
based on the US
department of defense TAFIM framework
First version of TOGAF focused primarily on
technology.
2002 Enterprise Edition TOGAF v 8
2009 TOGAF 9
Better linkage to business layer (business strategy,
business models, processes)
More user friendly framework (templates, guidelines)
Parts of the methodology have been simplified
TOGAF has been continuously improved for over 15
years!

What is TOGAF
TOGAF is a common sense, practical and effective
method of developing an enterprise architecture.
TOGAF describes itself as a "framework," but the most
important part of TOGAF is the Architecture
Development Method, better known as ADM. ADM is a
recipe for creating architecture. A recipe can be
categorized as a process. Given that ADM is the most
visible part of TOGAF, I categorize TOGAF overall as an
architectural process, instead of either an
architectural framework (as The Open Group describes
TOGAF) or a methodology (as it describes ADM).
TOGAF has 3 parts:
*The Architecture Development Method (ADM)
*The Enterprise Continuum
*The TOGAF Resource Base
TOGAF views the world of enterprise architecture as a
continuum of architectures, ranging from highly
generic to highly specific. It calls this continuum the
Enterprise Continuum.

TOGAF continued
The Architecture Development Method
(ADM):
The ADM explains how to derive an
organisation specific architecture to address
business requirements.
The Enterprise Continuum:
The Enterprise Continuum is a virtual
repository of all architecture assets, models,
patterns, architecture descriptions.
The TOGAF Resource Base:
The TOGAF Resource Base is a set of resources
- guidelines, templates, background
information etc., to help the architect.

Some clarifications

TOGAF Continued

*
*
*
*
*
*

The main benefits of TOGAF and Architecture Governance

are:
Increased transparency of accountability
Controlled risk
Protection of assets.
Proactive control
Value creation
Integration Opportunities.

TOGAF aligns with:

*
*
*
*

ITIL (& ISO20000)

MOF
CoBIT
ISO27001 (Security)

Why TOGAF
TOGAF is important for the enterprise IT architect for
one simple reason: It's needed. Large organizations
can no longer afford to create isolated applications
that perform single functions and don't communicate
with other applications. Nor can they ignore the effect
that actual business conditions have on their
technology requirements. Enterprise architecture is
stepping in to provide the link between a business and
its technology infrastructure, and TOGAF provides a
standard way, using best practices, to enable that link.

The role of an IT architect

The role of the IT architect is to be able to understand
the business problem and the business domain and
explain it to the technical people, and to be able to
understand the technology domains and explain the
technical possibilities to business people.

Defining TOGAF First Part

The first part of TOGAF is a methodology for developing your architecture design,
which is called the Architecture Development Method (ADM). It has the following nine
basic phases:
Preliminary phase: Framework and principles. Get everyone on board with the
plan.
Phase A: Architecture vision. Define your scope and vision and map your overall
strategy.
Phase B: Business architecture. Describe your current and target business
architectures and determine the gap between them.
Phase C: Information system architectures. Develop target architectures for
your data and applications.
Phase D: Technology architecture. Create the overall target architecture that you
will implement in future phases.
Phase E: Opportunities and solutions. Develop the overall strategy, determining
what you will buy, build or reuse, and how you will implement the architecture
described in phase D.
Phase F: Migration planning. Prioritize projects and develop the migration plan.
Phase G: Implementation governance. Determine how you will provide oversight
to the implementation.
Phase H: Architecture change management. Monitor the running system for
necessary changes and determine whether to start a new cycle, looping back to the
preliminary phase.
These phases provide a standardized way of analyzing the enterprise and planning
and managing the actual implementation.

Architecture Development
Method (ADM)

Preliminary Phase: Frameworks

& Principles
This phase prepares the
organization for undertaking
Enterprise Architecture
successfully
Understand business
environment
Commitment of key
stakeholders
Agreement on scope
Establish principles
Establish governance
structure
Agree method to be
adopted

Phase A: Architecture Vision

Initiates one iteration of the
architecture process
Sets scope, constraints,
expectations
Required at the start of
every architecture cycle
Validates business context
Creates Statement of
Architecture work

Phase B: Business Architecture

The fundamental
organization of a business,
embodied in
its business processes
and people,
their relationships
to each other and the
environment,
and the principles
governing its design and
evolution
Shows how the organization
meets its business goals

Business Architecture Contents

Organization structure
Business goals and objectives
Business functions
Business Services
Business processes
Business roles
Correlation of organization and functions.

Business Architecture Steps

Confirm context

Define baseline
Define target

Views are important

Validate
Requirements
Concerns

Perform Gap analysis

Produce report

Phase C: Information Systems

Architectures
The fundamental
organization of an IT
system, embodied in
relationships to each
other and the
environment, and the
principles governing its
design and evolution
Shows how the IT
systems meets the
business goals of the
enterprise

Phase C: Data or Applications

first ?
It is usually necessary to
address both
Not always the
case, depending on
project scope and
constraints
May be developed in
either order, or in parallel
Theory suggests
Data Architecture
comes first
Practical
considerations may
mean that starting
with Application
Systems may be
more efficient
There will need to be
some iteration to ensure

Phase D: Technology
Architecture
The fundamental
organization of an IT
system, embodied in
its hardware,
software and
communications
technology
their relationships
to each other and
the environment,
and the principles
governing its
design and
evolution

Phase E: Opportunities and

Solutions
Identify the major
implementation
projects
Decide on approach
Make v Buy v
Re-Use
Outsource
COTS
Open Source
Assess priorities
Identify
dependencies

Phase F: Migration Planning

For projects
identified in Phase
E perform
Cost/benefit
analysis
Risk
assessment
Produce an
implementation
road-map

Phase G: Implementation
Governance
Defines
architecture
constraints on
implementation
projects
Architecture
contract
Monitors
implementation
work for
conformance

Phase H: Architecture
Change Management
Ensures that changes
to the architecture are
managed in a cohesive
and architected way
Establishes and
supports the Enterprise
Architecture to provide
flexibility to evolve
rapidly in response to
changes in the
technology or business
environment

Overview of the ADM

The ADM is a generic method: It can be used by enterprises in a

wide
variety of different geographies, applied in different vertical
sectors/industry types and can be tailored to specific needs
The ADM is iterative: Over the whole process, between phases,
and
within phases
For each iteration of the ADM, a fresh decision must be taken as
to:
The breadth of coverage of the enterprise to be defined
The level of detail to be defined
The extent of the time period aimed at
The architectural assets to be leveraged, including:
Assets created in previous iterations of the ADM cycle within the
enterprise
Assets available elsewhere in the industry (other frameworks,
systems
models, vertical industry models, etc.)

Adapting the ADM

To take account of the maturity of the

architecture discipline within the
organization
e.g. by putting more emphasis on phases
that were formerly not well understood
by the organization
The business and/or architecture
principles of an enterprise may require
that the ADM is adapted
To integrate the ADM with another
enterprise framework or other firm
standards
e.g. the Zachman Framework
e.g. program management, business
planning or procurement

Advantages of the ADM as a

method

Strong focus on eliminating the barriers between

Business and IT
Ensures a high level of consistency and control
Through reuse of architectures, use of principles etc
Formal post-implementation feedback and control is
part of the method
Supports strategic, long-term architecture planning
Planning techniques, architecture governance after
implementation etc
A realistic method
Covers all the key domains, but does not force the
architect to make views that
are not necessary for anyone
Highly flexible and can be adapted:
For companies of any size, for architecture projects
to any level of detail

Applying the ADM at

Different Levels

Defining TOGAF Second

Part What is Architecture
Repository
The Architecture Repository provides a framework and
context to support
the leverage of relevant architecture assets in
executing the ADM
One part of the Architecture Repository is the
Enterprise Continuum, which is a
tool for categorizing architectural source material
At relevant places throughout the ADM, there are
reminders as to which assets
from the repository can be used
e.g. Foundation Architecture in Phase D: Technical
Architecture
In executing the ADM, the architect also populates
the organizations own
Architecture Repository
The criteria for including source materials in an
organizations
Architecture Repository will typically form part of the
enterprise
architecture governance process

Defining TOGAF Second

Part
The second major part of TOGAF is the Enterprise
Continuum. This collection of architectural building
blocks and models enable you to not only build your
architecture design more easily, but also to eliminate
ambiguity when discussing various concepts and
items involved in the analysis and implementation -which can be a problem even between groups within
a single organization.

Architecture Repository
An environment
used to store
architectural
output created
in the ADM
Helps
architects
leverage
relevant
resources and
assets
for developing
Architecture

Enterprise Continuum
A view of the
Architecture
Repository that
provides
methods for
classifying
architectures
and
solution
artifacts in a
structured way

TOGAF Enterprise
Continuum
TOGAF defines the various knowledge bases that live in

the Foundation Architecture. Two that you might run into

are the Technical Reference Model (TRM) and the
Standards Information Base (SIB). The TRM is a
suggested description of a generic IT architecture. The
SIB is a collection of standards and pseudo-standards
that The Open Group recommends that you consider in
building an IT architecture.
TOGAF presents both the TRM and the SIB as
suggestions; neither is required.

TOGAF 9 Components

ADM
Architecture Content Framework
Reference Models
ADM Guidelines and Techniques
Enterprise Continuum
Architecture Capability Framework

ADM Guidelines and

Techniques
A set of guidelines and techniques to support the

application of the ADM

The guidelines help to adapt the ADM to deal with
different
scenarios, including different process styles (e.g. the use of
iteration) and also specific requirements (e.g. security).
The techniques support specific tasks within the ADM
(e.g.
defining principles, business scenarios, gap analysis,
migration planning, risk management, etc).

Architecture Content
Provides a detailed model of
Framework
architectural
work products, including Deliverables,
Artifacts within deliverables, and the
Architecture Building Blocks (ABBs)
that deliverables represent.
It drives for greater consistency in the
outputs of TOGAF
It provides a comprehensive checklist
of
architecture outputs
It promotes better integration of work
products
It provides a detailed open standard
for
how architectures should be described
It includes a detailed metamodel

Enterprise Continuum

Enterprise Continuum

The Architecture Continuum

The Architecture Continuum illustrates how architectures are developed
across a continuum ranging from Foundation Architectures such as
TOGAF's, through common systems architectures, and industry-specific
architectures, to an enterprise's own individual architectures.
The arrows in The Architecture Continuum represent the bi-directional
relationship that exists between the different architectures in the
Architecture Continuum. The leftwards direction focuses on meeting
enterprise needs and business requirements, while the rightwards
direction focuses on leveraging architectural components and building
blocks.
The enterprise needs and business requirements are addressed in
increasing detail from left to right. The architect will typically look to find
re-usable architectural elements toward the left of the continuum. When
elements are not found, the requirements for the missing elements are
passed to the left of the continuum for incorporation. Those implementing
architectures within their own organizations can use the same continuum
models specialized for their business.
The four particular architectures illustrated in The Architecture Continuum
are intended to indicate the range of different types of architecture that
may be developed at different points in the continuum; they are not fixed
stages in a process. Many different types of architecture may occur at
points in-between those illustrated in The Architecture Continuum .

Foundation Architecture

A Foundation Architecture is an architecture of building blocks and

corresponding standards that supports all the common systems
architectures and, therefore, the complete computing environment.
For The Open Group, this Foundation Architecture is the Technical
Reference Model (TRM) and Standards Information Base (SIB). The
TOGAF ADM explains how to get from that Foundation Architecture to
an enterprise-specific one.
The TOGAF TRM and SIB describe a fundamental architecture upon
which other, more specific architectures can be based. The TOGAF
Foundation Architecture contains many alternatives in each of the
ABBs. Other characteristics of the TOGAF Foundation Architecture
include the following:
Reflects general computing requirements
Reflects general building blocks
Defines technology standards for implementing these building blocks
Provides direction for products and services
Reflects the function of a complete, robust computing environment
that can be used as a foundation
Provides open system standards, directions, and recommendations
Reflects directions and strategies

Common Systems
Architectures
Common Systems Architectures guide the selection and
integration of specific services from the Foundation Architecture
to create an architecture useful for building common (i.e., reusable) solutions across a wide number of relevant domains.
Examples of Common Systems Architectures include: a Security
Architecture, a Management Architecture, a Network
Architecture, etc. Each is incomplete in terms of overall
information system functionality, but is complete in terms of a
particular problem domain (security, manageability, networking,
etc.), so that solutions implementing the architecture constitute
re-usable building blocks for the creation of functionally
complete information systems.
Other characteristics of Common Systems Architectures include:
Reflects requirements specific to a generic problem domain
Defines building blocks specific to a generic problem domain
Defines technology standards for implementing these building
blocks
Provides building blocks for easy re-use and lower costs

Industry Architectures
Industry Architectures guide the integration of common systems
components with industry-specific components, and guide the
creation of industry solutions for targeted customer problems
within a particular industry.
A typical example of an industry-specific component is a data
model representing the business functions and processes
specific to a particular vertical industry, such as the Retail
industry's "Active Store" architecture, or an Industry
Architecture that incorporates the Petrotechnical Open Software
Corporation (POSC) (www.posc.org) data model.
Other characteristics of Industry Architectures include the
following:
Reflects requirements and standards specific to a vertical
industry
Defines building blocks specific to a generic problem domain
Contains industry-specific logical data and process models
Contains industry-specific applications and process models, as
well as industry-specific business rules
Provides guidelines for testing collections of systems
Encourages levels of interoperability throughout the industry

Enterprise Architectures

Enterprise architectures are the most relevant to the IT customer community,

since they describe and guide the final deployment of user-written or thirdparty components that constitute effective solutions for a particular
enterprise or enterprises that have a need to share information.
There may be a continuum of enterprise architectures that are needed to
effectively cover the organization's requirements by defining the enterprise
architecture in increasing levels of detail. Alternatively, this might result in
several more detailed enterprise architectures for specific entities within the
global enterprise.
The enterprise architecture guides the final customization of the solution, and
has the following characteristics:
Provides a means to communicate and manage the IT environment
Reflects requirements specific to a particular enterprise
Defines building blocks specific to a particular enterprise
Contains organization-specific physical data, applications, and process
models, as well as business rules
Provides a means to encourage implementation of appropriate IT to meet
business needs
Provides the criteria to measure and select appropriate products, solutions,
and services
Provides an evolutionary path to support growth and new business needs

The Solutions Continuum

The Solutions Continuum represents the implementations of the architectures at the

corresponding levels of the Architecture Continuum. At each level, the Solutions Continuum is
a population of the architecture with reference building blocks - either purchased products or
built components - that represent a solution to the enterprise's business need expressed at
that level. A populated Solutions Continuum can be regarded as a solutions inventory or reuse library, which can add significant value to the task of managing and implementing
improvements to the IT environment.

In the Architecture Continuum in The Architecture Continuum , the arrows represent bidirectional relationships that exist between the different architectures in the Architecture
Continuum (the leftwards direction focused on meeting customer needs and business
requirements, the rightwards direction on leveraging architectural components and building
blocks).
A similar concept applies to the bi-directional arrows underlying the Solutions Continuum in
The Solutions Continuum . The rightwards direction of the arrows is focused on providing
solutions value (i.e., Products and Services provide value in creating systems solutions;
systems solutions value is used to create industry solutions; and industry solutions are used
to create customer solutions). The leftwards direction is focused on addressing enterprise
needs.
These two viewpoints are significant for a company attempting to focus on its needs while
maximizing the use of its internal resources through leverage.
The following subsections describe each of the solution types within the Solutions Continuum.

Products and Services

Systems Solutions
A "system solution" is an implementation of a Common Systems Architecture comprised of a set of
products and services, which may be certified or branded. It represents the highest common denominator
for one or more solutions in the industry segments that the system solution supports.
System solutions represent collections of common requirements and capabilities, rather than those
specific to a particular customer or industry. System solutions provide organizations with operating
environments specific to operational and informational needs, such as high availability transaction
processing and scaleable data warehousing systems. Examples of systems solutions include: an enterprise
management system product or a security system product.
Computer systems vendors are the primary provider of systems solutions.
Industry Solutions
An "industry solution" is an implementation of an Industry Architecture, which provides re-usable packages
of common components and services specific to an industry.
Fundamental components are provided by system solutions and/or products and services, and are
augmented with industry-specific components. Examples include: a physical database schema or an
industry-specific point-of-service device.
Industry solutions are industry-specific, aggregate procurements that are ready to be tailored to an
individual organization's requirements.
In some cases an industry solution may include not only an implementation of the Industry Architecture,
but also other solution elements, such as specific products, services, and systems solutions that are
appropriate to that industry.
Enterprise Solutions
An "enterprise solution" is an implementation of the enterprise architecture that provides the required
business functions. Because solutions are designed for specific business operations, they contain the
highest amount of unique content in order to accommodate the varying people and processes of specific
organizations.
Building enterprise solutions on industry solutions, systems solutions, and products and services is the
primary purpose of connecting the Architecture Continuum to the Solutions Continuum, as guided by the
architects within an enterprise.

The Enterprise Continuum and Your Organization

The preceding sections have described both the Architecture Continuum and the
S+
A Solutions Continuum. As explained in Introduction to the Enterprise Continuum , the
combination of these two complementary concepts constitutes the Enterprise Continuum,
=
illustrated in The Enterprise Continuum .
E

Enterprise Continuum

Relationships
The relationship between the Architecture Continuum and the Solutions Continuum is one of guidance,
direction, and support.
For example, the Foundation Architecture guides the creation or selection of products and services. The
products and services support the Foundation Architecture by helping to realize the architecture defined in
the Architecture Continuum. The Foundation Architecture also guides development of products and services,
by providing descriptions of required functions to build open computing systems, and the rationale for those
functions. A similar relationship exists between the other elements of the Enterprise Continuum.
The Enterprise Continuum presents mechanisms to help improve productivity through leverage. The Solutions
Continuum offers a consistent way to understand the different products, systems, services, and solutions
required. The Architecture Continuum offers a consistent way to understand the different architectures and
their components.
The Enterprise Continuum should not be interpreted as representing strictly chained relationships. Enterprise
Architectures could have components from a Common Systems Architecture, and enterprise solutions could
contain a product or service. The relationships depicted in The Enterprise Continuum are a best case for the
ideal leveraging of architecture and solution components.
Finally, it is worth emphasizing that the beginning and the end of the Enterprise Continuum lie in a
Foundation Architecture, which serves as a tool chest or repository of re-usable guidelines and standards. For
The Open Group, this Foundation Architecture is the Technical Reference Model (TRM) and Standards
Information Base (SIB).
Your Enterprise
TOGAF provides a method for you to "architect" the IT systems in your enterprise. Your architecture
organization will have to deal with each type of architecture described above. For example, it is
recommended that you have your own Foundation Architecture that governs all of your IT systems. You
should also have your own Common Systems Architectures that govern major shared infrastructure systems such as the networking system or management system. You may have your own industry-specific
architectures that govern the way your IT systems must behave within your industry. Finally, any given
department or organization within your business may need its own individual enterprise architecture to
govern the IT systems within that department. All-in-all this implies that your architecture organization is
responsible for maintaining your business' Architecture Continuum.
Your architecture organization will either adopt or adapt existing architectures, or will develop its own
architectures from ground up. In either case, TOGAF represents a tool to help. It provides a method to assist
you in generating/maintaining any type of architecture within the Architecture Continuum while leveraging
architecture assets already defined, internal or external to your organization. The TOGAF Architecture
Development Method (ADM) helps you to re-use architecture assets, making your architecture organization
more efficient and effective.

TOGAF Reference Models

The two reference models are:

The TOGAF Technical Reference Model (TRM)
A Foundation Architecture
A model and a taxonomy of generic platform
services
The Integrated Information Infrastructure
Model (III-RM).
A model for business applications and
infrastructure applications
Specifically aimed to support the vision of
Boundaryless Information Flow

Detailed TRM

The Integrated Information Infrastructure

Reference Model (III-RM)

The Architecture Capability Framework

A structured definition of the organizations, skills,
roles and responsibilities
to establish and operate an Enterprise Architecture.

Relationship between EA
and
ADM
The TOGAF describes the process of developing an
enterprise-specific architecture and an enterprisespecific solution(s) which conform to that architecture
by adoptiong and adapting (where appropriate)
generic architectures and solutions

Skills framework

Types of skill categories used in the TOGAF skills framework:

Generic Skills: typically comprising leadership, team working, interpersonal
skills, etc
Business Skills & Methods: typically comprising business cases, business
process, strategic planning, etc
Enterprise Architecture Skills: typically comprising modeling, building
block
design, applications and role design, systems integration, etc
Program or Project Management Skills: typically comprising managing
business
change, project management methods and tools, etc
IT General Knowledge Skills: typically comprising brokering applications,
asset
management, migration planning, SLAs, etc
Technical IT Skills: typically comprising software engineering, security,
data
interchange, data management, etc
Legal Environment: typically comprising data protection laws, contract
law,
procurement law, fraud, etc

A more efficient IT
operation:
Lower software development, support, and
maintenance costs
Increased portability of applications
Improved interoperability and easier system and
network management
Improved ability to address critical enterprise-wide
issues like security
Easier upgrade and exchange of system
components

Better return on existing investment,

reduced risk for future investment:
Reduced complexity in IT infrastructure
Maximum return on investment in existing IT
infrastructure
The flexibility to make, buy, or out-source IT solutions
Reduced risk overall in new investment, and the costs
of IT ownership

Faster, simpler, and cheaper

procurement:
Buying decisions are simpler, because the information
governing procurement is readily available in a coherent plan.
The procurement process is faster - maximizing procurement
speed and flexibility without sacrificing architectural
coherence.
The ability to procure heterogeneous, multi-vendor open
systems.

Who would benefit from using TOGAF?

Any organization undertaking, or planning to undertake,
the design and implementation of an enterprise
architecture for the support of mission-critical business
applications 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.

Some Figures about TOGAF

Developed by 200+ organisations

worldwide involved in its development

Large IT users
IT vendors
System Integrators
Academics

Used in major IT projects worldwide

IBM, EDS, HP, Sun, Infosys, ..

Community of knowledgeable TOGAF

practitioners
Over 5000 certified

Supported by Architecture Tools

Lets summarize againTOGAF 9 - Why all the fuss?

TOGAF 8 has been around for around 5 years and is a

tremendous success. Major companies worldwide have
adopted TOGAF. More than 8500 individuals have achieved
TOGAF 8 Certification (more than half through Architecting
the Enterprise). However as the SWOT analysis that we carry
out on every single training course shows, there are many
areas where TOGAF 8 can be improved. TOGAF 9 addresses
these calls for improvement, including:
Increased rigor including a formal Meta Model that links the
artifacts of TOGAF together
Elimination of unnecessary differences
Additional guidelines and techniques, including
A formal business-driven approach to architecture scoping
and segmentation
Business capability-based planning
Guidance on how to use TOGAF to develop Security
Architectures and SOAs
Many more examples

TOGAF 9 - Is it a revolution?
No. A design objective for TOGAF 9 was that it should
represent a smooth transition from TOGAF 8. The base
structure of TOGAF, The Architecture Development Method
(ADM), remains unchanged. All of the new material is
added within that structure, which means that you can
select which of the new capabilities you adopt in your
organization. No organization needs to choose between
TOGAF 8 and TOGAF 9. Nothing from TOGAF 8 has been
lost in the evolution; much value has been added.

What are the differences between TOGAF 8 and

TOGAF 9? Features that are common to TOGAF 8 and
TOGAF 9

The business rationale for Enterprise Architecture and TOGAF

The TOGAF Architecture Development Method and its
deliverables, including Business, Data, Applications and
Technology Architecture
The Enterprise Continuum
Enterprise Architecture Governance
Architecture Principles and their development
Architecture Views and Viewpoints
Requirements Engineering using Business Scenarios
Architecture Maturity Assessments
Architecture Skills Framework
An Introduction to Building Blocks

Features added in TOGAF 9

Architecture Partitioning
Content Framework and Meta Model
Capability Based Planning
Business Transformation Readiness
Using TOGAF to develop Security Architectures
Architecture Repository
Using TOGAF to develop SOAs

An Example

the TOGAF ADM consists of eight phases that are cycled through after an initial "priming of
the pump." I'll take you through these phases as they could be applied to the MedAMore
case study. But, before MedAMore can start the ADM, it needs to gain some experience
with TOGAF. MedAMore will have two choices on how it can get this experience.
First, MedAMore can train itself in TOGAF. MedAMore can download the TOGAF
documentation [20]which describes all of TOGAF, including the ADM, in considerable
detail. It can purchase books on TOGAF [21]. There is probably more free and inexpensive
available information about TOGAF than about all other architectural methodologies
combined.
Second, MedAMore can buy expertise in TOGAF. There are consultants who specialize in
TOGAF and have earned Open Group certification [22]. Because MedAMore wants to
minimize any chances of failure, it has chosen to call in a TOGAF consultant. MedAMore has
brought in Teri, an Open Groupcertified TOGAF architect. Remember that the other players
at MedAMore are Cath, the CEO of MedAMore; Bret, the Business VP; and Irma, the CIO.
In the Preliminary Phase, Teri meets with the major players at MedAMore to introduce the
TOGAF process. Her three goals in the preliminary phase are to:
Make sure everybody is comfortable with the process.
Modify the TOGAF process, as necessary, to fit within the MedAMore culture.
Set up the governance system that will oversee future architectural work at MedAMore.
Teri will work closely with Bret to understand the business philosophy, business models,
and strategic drivers of MedAMore. She will work closely with Irma to define the
architectural principles that drive technological architectures at MedAMore and document
those principles using the TOGAF-recommended format.
In some organizations, achieving buy-in on the need for an enterprise architecture could be
very difficult. This is especially true when the effort is driven from the IT organization, and
even more so when there is a history of discord between the business and the technical
sides of the organization. MedAMore does have this history of animosity. However, it has
another fact going for it from which Teri should take heart: The effort is not driven by IT, but
is driven by Cath, the CEO. This gives the project high visibility and creates a positive
incentive for cooperation from all sides.

An Example

As soon as Teri and MedAMore have completed the Preliminary Phase, they are ready to
start Phase A. Phase A begins, at least in theory, with a Request for Architecture Work from
some organization within MedAMore. This document includes the business reasons for the
request, budget and personnel information, and any constraints that need to be
considered. Because MedAMore has never done a Request for Architecture Work, Teri will
probably need to work with the sponsoring organization in creating such a request.
As soon as the Request for Architecture Work (or some equivalent) has been received, Teri
(the TOGAF consultant) starts MedAMore on Phase A. In Phase A, Teri will ensure that the
project has the necessary support within MedAMore, define the scope of the project,
identify constraints, document the business requirements, and establish high-level
definitions for both the baseline (starting) architecture and target (desired) architecture.
These baseline and target definitions will include high-level definitions on all four of the EA
sub-architectures shown back in Figure 5namely, business, technology, data, and
application architectures.
The culmination of Phase A will be a Statement of Architecture Work, which must be
approved by the various stakeholders before the next phase of the ADM begins. The output
of this phase is to create an architectural vision for the first pass through the ADM cycle.
Teri will guide MedAMore into choosing the project, validating the project against the
architectural principles established in the Preliminary Phase, and ensure that the
appropriate stakeholders have been identified and their issues have been addressed.
The Architectural Vision created in Phase A will be the main input into Phase B. Teri's goal in
Phase B is to create a detailed baseline and target business architecture and perform a full
analysis of the gaps between them. She will work primarily with Bret (or Bret's team) to
achieve this.
Phase B is quite involvedinvolving business modeling, highly detailed business analysis,
and technical-requirements documentation. A successful Phase B requires input from many
stakeholders. The major outputs will be a detailed description of the baseline and target
business objectives, and gap descriptions of the business architecture.

An Example

Phase C does for the information-systems architecture what Phase B does for the business architecture.
In this phase, Teri works primarily with Irma (or her team). TOGAF defines nine specific steps, each with
multiple sub-steps:
Develop baseline data-architecture description
Review and validate principles, reference models, viewpoints, and tools
Create architecture models, including logical data models, data-management process models, and
relationship models that map business functions to CRUD (Create, Read, Update, Delete) data
operations
Select data-architecture building blocks
Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
Review qualitative criteria (for example, performance, reliability, security, integrity)
Complete data architecture
Conduct checkpoint/impact analysis
Perform gap analysis
The most important deliverable from this phase will be the Target Information and Applications
Architecture.
Phase D completes the technical architecturethe infrastructure necessary to support the proposed
new architecture. This phase is completed mostly by engaging with Irma's technical team.
Phase E evaluates the various implementation possibilities, identifies the major implementation
projects that might be undertaken, and evaluates the business opportunity associated with each. The
TOGAF standard recommends that Teri's first pass at Phase E "focus on projects that will deliver shortterm payoffs and so create an impetus for proceeding with longer-term projects."
This is good advice in any architectural methodology. Therefore, Teri should be looking for projects that
can be completed as cheaply as possible, while delivering the highest perceived value. A good starting
place to look for such projects is the organizational pain-points that initially convinced Cath (the
MedAMore CEO) to adopt an enterprise architectural-based strategy in the first place. These painpoints, described earlier, included difficulties in completing regional/warehouse specialization and
unreliability in data sharing.

An Example

Phase F is closely related to Phase E. In this phase, Teri works with MedAMore's governance body to
sort the projects identified in Phase E into priority order that include not only the cost and benefits
(identified in Phase E), but also the risk factors.
In Phase G, Teri takes the prioritized list of projects and creates architectural specifications for the
implementation projects. These specifications will include acceptance criteria and lists of risks and
issues.
The final phase is H. In this phase, Teri modifies the architectural change-management process with
any new artifacts created in this last iteration and with new information that becomes available.
Teri is then ready to start the cycle again. One of the goals from the first cycle should be information
transfer, so that Teri's services are required less and less as more and more iterations of the cycle are
completed.
Much of the results of the TOGAF process will be determined as much by the Teri/MedAMore
relationship as it will by the TOGAF specification itself. TOGAF is meant to be highly adaptable, and
details for the various architectural artifacts is sparse. As one book on TOGAF says:
TOGAF is not wholly specific with respect to generated documents; in fact, it provides very little in the
way of prescriptive document templatesmerely guidelines for inputs and outputs. [23]
The TOGAF specification is also flexible with respect to the phases. As the specification itself says:
One of the tasks before applying the ADM is to review its components for applicability, and then tailor
them as appropriate to the circumstances of the individual enterprise. This activity might well produce
an "enterprise-specific" ADM.
TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the
needs of the situation. So, it should be no surprise if two different TOGAF-certified consultants end up
using two very different processeseven when working with the same organization.
TOGAF is even more flexible about the actual generated architecture. In fact, TOGAF is, to a surprising
degree, "architecture-agnostic". The final architecture might be good, bad, or indifferent. TOGAF merely
describes how to generate an enterprise architecture, not necessarily how to generate a good
enterprise architecture. For this, you are dependent on the experience of your staff and/or TOGAF
consultant. People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely disappointed
(as they will be with any of the methodologies).