A Quick Look on TOGAF

A Quick Look on TOGAF

By: Agung Ariwibowo

ABSTRACT

One of the reasons of implementing enterprise architecture is to create balance between business and
IT for the needs of organizations. The enterprise architecture implementation is always related to how
an enterprise plans and designs the enterprise architecture. To do so, they need a methodology, a
framework that is complete and easy to use, and TOGAF is the one to come in mind. It is complete,
but not many understand how to use well. So we will take a look at TOGAF which is actually one of
the best architecture frameworks available.

Keywords: enterprise architecture, TOGAF, methodology, architecture framework

1. INTRODUCTION TOGAF 7 (“Technical Edition”) was

The field of enterprise architecture essentially
started in 1987 with the publication in the IBM
System Journal of an article titled, “A
framework for information system
architecture,” by J.A. Zachman. In that paper,
Zachman laid out both the challenge and the
vision of enterprise architecture that would
guide the field for the next 20 years. The
challenge was to manage the complexity of
increasingly distributed systems. Zachman
said that the cost involved and the success of
the business depending increasingly on its
information systems require a disciplined
approach to the management of those systems.
Zachman became a major influence to the
Department of Defense of the United States
Government to create enterprise architecture.
This EA was known as the Technical
Architecture Framework for Information
Management (TAFIM). TAFIM was
introduced in 1994.
In 1995 the first version of TOGAF was
presented, which was based on the TAFIM.
The US Department of Defense gave The
Open Group explicit permission and
encouragement to create TOGAF by building
on the TAFIM.
published in December 2001. TOGAF 8
(“Enterprise Edition”) was first published in
December 2002 and republished in updated
form as TOGAF 8.1 in December 2003, which
was updated in November 2006 as TOGAF
8.1.1. The latest version is TOGAF 9,
launched on 2 February 2009. As an
evolutionary development from TOGAF 8,
TOGAF 9 includes many new features
including
• Increased rigor including a formal Meta
Model that links the artifacts of TOGAF
together
• Elimination of unnecessary differences
• More examples and templates
Additional guidelines and techniques include
• A formal business-driven approach to
architecture scoping and segmentation
• Business capability-based planning
• Guidance on how to use TOGAF to
develop Security Architecture and SOAs
2. TOGAF ENTERPRISE
ARCHITECTURE DOMAINS
TOGAF is based on four pillars, called
architecture domains:

1
 A Quick Look on TOGAF

• Business Architecture – Describes the

processes the business uses to meet its
goals. It defines the business strategy,
governance, organization, and key
business processes of the organization.
ganization.
• Applications Architecture – Describes
how specific applications are designed
and how they interact with each other,
other
and their relationships to the core
business processes of the organization.
• Data Architecture – Describes how the
enterprise data assets are organized and
accessed,, as well as the data structure
and the associated data management
resources.
• Technology Architecture – Describes
the hardware, software,, middleware,
network,, communications, processing,
and standards that support applications
applica
and their interactions. Figure 1 TOGAF Architecture Development Cycle

Phases within the ADM are as follows:

3. ARCHITECTURE DEVELOPMENT • The Preliminary Phase

METHOD
TOGAF describes itself as a framework, but
the most important part of TOGAF is the t directive for a new enterprise
Architecture Development Method, better
known as TOGAF ADM.. The TOGAF ADM
provides a tested and repeatable process
pro for
developing architectures. The ADM includes
establishing an architecture framework,
developing architecture content, transitioning,
and governing the realization of architectures.
All of these activities,, as seen on Figure 1, 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.
The TOGAF ADM is a flexible method since
it can be tailored
ilored to suit the changes of needs
during the design phase.
The preliminary
reliminary phase ddescribes the
preparation and initiation
initiat activities
required to prepare to meet et the business
architecture, including the definition of
an Organization-Specific
Specific Architecture
framework and the definition of
principles.
• Phase A: Architecture Vision
This phase describes
ibes the initial phase of
an architecture development cycle. It
includes information about defining the
scope, identifying the stakeholders,
creating the Architecture Vision, and
obtaining approvals. In this phase, there
are questions which are used to get the
ideal architecture.
• Phase B: Business Architecture
This phase describes
escribes the development of
a Business Architecture to support an
agreed Architecture Vision. In this
phase, many modeling notations such as
BPMN, IDEF, and UML can be used to
build the models needed.

2

• Phase C: Information Systems
Architectures
This phase describes the development of
Information Systems Architectures for
an architecture project, including the
development of Data and Application
Architectures. Data architecture focuses
on how data are used for the needs of
business, processes, and service
function. Techniques to be used are ER-
Diagram, Class Diagram, and Object
Diagram.
The application architecture is more
focused on how the requirements of
application planned using the
Application Portfolio Catalog. It also
emphasize on the application models to
be designed. Techniques that can be
used are Application Communication
Diagram, Application and User
Location Diagram, etc.
• Phase D: Technology Architecture
This phase describes the development of
the Technology Architecture for an
architecture project. Techniques that can
be used on this phase are Environment
and Location Diagram, Network
Computing Diagram, etc.
• Phase E: Opportunities & Solutions
This phase conducts initial
implementation planning and the
identification of delivery vehicles for the
architecture defined in the previous
phases. To model this phase on the
design, we can use the Project Context
Diagram and the Benefit Diagram.
• Phase F: Migration Planning
This phase addresses the formulation of
a set of detailed sequence of transition
architectures with a supporting
Implementation and Migration Plan.
Usually, the modeling on this phase uses
valuation and decision matrices for the
organization needs for the
implementation of a system.
• Phase G: Implementation Governance
This phase provides an architectural
oversight of the implementation. The
3
A Quick Look on TOGAF
mapping on this phase can be integrated
with other management framework such
as COBITS from IT Governance
Institute (ITGI).
• Phase H: Architecture Change
Management
This phase establishes procedures for
managing change to the new
architecture, as well as decides if
another cycle of architecture
development will be done.
• Requirements Management
This is actually a phase that is done on
every phases, it examines the process of
managing architecture requirements
throughout the ADM.
Each of the phases mentioned above have their
own content metamodel, which defines a set of
entities that allow architectural concepts to be
captured, stored, filtered, queried, and
represented in a way that supports consistency,
completeness, and traceability. The detailed
representation of the content metamodel can
be seen on Figure 2.
Furthermore, the content metamodel has
viewpoints associated with them. These
viewpoints come in form of catalogs, matrices,
and diagrams, which is used in order to aid in
re-use and consistency. Their purpose is
mainly to identify stakeholders concerns. The
viewpoints associated with the content
metamodel can be seen on Figure 3.
You may realize that not all of the phases in
TOGAF Architecture Development Cycle
included in the content metamodel and the
viewpoints associated with it. In the content
metamodel, architecture change management
and requirement management are not
included. And in the associated viewpoints,
requirement management is included, but the
migration planning, implementation
governance, and architecture change
management phases are not included. The
information system architecture phase is even
divided into data and application architecture.
 A Quick Look on TOGAF

Figure 2 Detailed Representation of the Content Metamodel

Figure 3 Viewpoints Associated with the Core Content Metamodel and Extension

4
 A Quick Look on TOGAF

The viewpoints associated with the content • Opportunities and Solutions:

metamodel on each phase are called artifacts, - Project Context Diagram
and as can be seen on figure 3, they are as - Benefits Diagram
follows: • Requirements Management:
- Requirements Catalog
• Preliminary:
- Principles Catalog
4. ENTERPRISE CONTINUUM
• Architecture Vision:
- Stakeholder Map Matrix It is usually impossible to create a single
- Value Chain Diagram unified architecture that meets all requirements
- Solution Concept Diagram of all stakeholders for all time. Therefore, the
• Business Architecture: enterprise architect will need to deal not just
- Organizational/Actor Catalog with a single enterprise architecture, but with
- Role Catalog many related enterprise architectures.
- Business Service/Function Catalog
- Business Interaction Matrix Each architecture will have a different purpose
- Actor/Role Matrix and architectures will relate to one another.
- Business Footprint Diagram Effectively bounding the scope of an
- Business Service/Information architecture is therefore a critical success
Diagram factor in allowing architects to break down a
- Functional Decomposition Diagram complex problem space into manageable
- Product Lifecycle Diagram components that can be individually
• Information Systems (Data addressed.
Architecture):
The Enterprise Continuum is a view of the
- Data Entity/Data Component Diagram
Architecture Repository that provides methods
- Data Entity/Business Function
for classifying architecture and solution
Diagram
artifacts, both internal and external to the
- System/Data Matrix
Architecture Repository, as they evolve from
- Class Diagram
generic Foundation Architectures to
- Data Dissemination Diagram
Organization-Specific Architectures.
• Information Systems (Application
Architecture): The Enterprise Continuum is an important aid
- Application Portfolio Catalog to communication and understanding, both
- Interface Catalog within individual enterprises, and between
- System/Organization Matrix customer enterprises and vendor organizations.
- Role/ System Matrix Without an understanding of "where in the
- System/Function Matrix continuum you are", people discussing
- Application Interaction Matrix architecture can often talk at cross-purposes
- Application Communication Diagram because they are referencing different points in
- Application and User Location the continuum at the same time, without
Diagram realizing it.
- System Use-Case Diagram
• Technology Architecture: The Enterprise Continuum not only represent
- Technology Standards Catalog an aid to communication, it represents an aid
- Technology Portfolio Catalog to organizing re-usable architecture and
- System/Technology Matrix solution assets. The Enterprise Continuum in
- Environments and Locations Diagram general can be seen on Figure 4.

5
 A Quick Look on TOGAF

Figure 4 Enterprise Continuum

Figure 5 Relationships between Architecture and Solution Continua

6

The Enterprise Continuum is partitioned into
three distinct continua as follows:
• The Enterprise Continuum is the outermost
continuum and classifies assets related to the
context of the overall enterprise architecture.
The Enterprise Continuum classes of assets
may influence architectures, but are not
directly used during the ADM architecture
development. The Enterprise Continuum
classifies contextual assets used to develop
architectures, such as policies, standards,
strategic initiatives, organizational structures,
and enterprise-level capabilities. The
Enterprise Continuum can also classify
solutions. Finally, the Enterprise Continuum
contains two specializations, namely the
Architecture and Solutions Continua.
• The Architecture Continuum offers a
consistent way to define and understand the
generic rules, representations, and
relationships in an architecture, including
traceability and derivation relationships (e.g.,
to show that an Organization-Specific
Architecture is based on an industry or generic
standard). The Architecture Continuum
represents a structuring of Architecture
Building Blocks (ABBs) which are re-usable
architecture assets. ABBs evolve through their
development lifecycle from abstract and
generic entities to fully expressed
Organization-Specific Architecture assets. The
Architecture Continuum assets will be used to
guide and select the elements in the Solutions
Continuum. The Architecture Continuum
shows the relationships among foundational
frameworks (such as TOGAF), common
system architectures (such as the III-RM),
industry architectures, and enterprise
architectures. The Architecture Continuum is a
useful tool to discover commonality and
eliminate unnecessary redundancy.
• The Solutions Continuum provides a
consistent way to describe and understand the
implementation of the assets defined in the
Architecture Continuum. The Solutions
Continuum defines what is available in the
7
A Quick Look on TOGAF
organizational environment as re-usable
Solution Building Blocks (SBBs). The
solutions are the results of agreements
between customers and business partners that
implement the rules and relationships defined
in the architecture space. The Solutions
Continuum addresses the commonalities and
differences among the products, systems, and
services of implemented systems.
The Architecture and Solutions Continua have
relationships in form of guidance, direction,
and support. For example, the Foundation
Architectures defined in Architecture Continua
guide the creation or selection of Foundation
Solutions defined in Solution Continua. The
Foundation Solutions also support the
Foundation Architecture by helping to realize
the architecture defined in the Architecture
Continuum. The similar relationship also
exists between the other elements of the
Enterprise Continuum. These relationships can
be seen on Figure 5.
5. CLOSURE
The TOGAF is a complete architecture
framework. It can provide a thorough
enterprise architecture analysis and design,
which now become an important factor in an
organization success, especially one that
depends on IT.
The main TOGAF topics are the TOGAF
Enterprise Architecture domains, the TOGAF
ADM, and the Enterprise Continuum. The
TOGAF Architecture domains are the four
pillars that become the base of TOGAF.
TOGAF ADM might be the most important
part of TOGAF itself. It provides a tested and
repeatable process for developing
architectures. The Enterprise Continuum is a
view of the Architecture Repository that
provides methods for classifying architecture
and solution artifacts, thus helps in
communication and organizing re-useable
architecture and solution assets.
 A Quick Look on TOGAF

Even though TOGAF is a complete framework

and may even be the best framework available,
to create good enterprise architectures,
organization will still need skilled architect. It
is not just a matter of choosing the best
framework.

6. ACKNOWLEDGEMENT

Writer would thank CIMBNiaga Karawaci for

providing the necessary material and resources
to write this document, since it would not be
possible without the help provided by
CIMBNiaga Karawaci.

REFERENCES

Open Group. (2009). TOGAF V9 Sample Catalogs

Matrices Diagrams v2. TOGAF Standard
Courseware V9 Edition.

Open Group. (2010). The Open Group Architecture

Framework
http://www.opengroup.org/architecture/togaf9-
doc/arch/. Accessed on July 21, 2010.

Sessions, R. (2007). Comparison of the Top Four

Enterprise Architecture Methodologies.
ObjectWatch, Inc.

Yunis, R., Surendro, K. (2009). Perancangan

Model Enterprise Architecture dengan TOGAF
Architecture Development Method. Seminar
Nasional Aplikasi Teknologi Informasi 2009
(SNATI 2009). ISSN: 1907-5022.