TOGAF ADM Tutorial

 TOGAF ADM Tutorial

 Why TOGAF
 What is TOGAF ADM?
 TOGAF and ArchiMate
 TOGAF ADM Lifecycle - Iteration
 TOGAF ADM
 Summary
 Related Links
TOGAF®, The Open Group standard, is a proven enterprise architecture
methodology and framework used by the world's leading organizations to
improve business efficiency. It's the most prominent and reliable enterprise
architecture standard, ensuring consistent standards, methods, and
communication among enterprise architecture professionals. Enterprise
architecture professionals fluent in TOGAF standards enjoy greater industry
credibility, job effectiveness, and career opportunities. TOGAF helps
practitioners avoid being locked into proprietary methods, utilize resources
more efficiently and effectively, and realize a greater return on investment.
Why TOGAF?
The IT architecture needs to closely reflect the business goals of the
organization. Indeed, specific techniques (business scenarios) should be used
to ensure that the business goals are properly understood by the IT architect,
and reflected in the IT architecture developed using TOGAF.
Here are the reasons that we should adopt TOGAF ADM for architecture
development:
 A comprehensive general method
 Complementary to, not competing with, other frameworks
 Widely adopted in the market
 Tailorable to meet an organization and industry needs
 Available under a free perpetual license
 Vendor, tool and technology neutral open standard
 Avoids re-inventing the wheel
 Business IT alignment
 Based in best practices
 Possible to participate in the evolution of the framework

What is TOGAF Architecture Development Method

(ADM)?
The Architecture Development Method (ADM) is applied to develop an
enterprise architecture which will meet the business and information
technology needs of an organization. The TOGAF ADM is the result of
continuous contributions from a large number of architecture practitioners for
serving the following purposes:
 It describes a method for developing and managing the lifecycle of an
enterprise architecture, and forms the core of TOGAF.
  It may be tailored to the organization's needs and is then employed to
manage the execution of architecture planning activities.
TOGAF and ArchiMate
ArchiMate is a modeling standard introduced by the Open Group. It provides a
rich set of modeling notations and concepts that supports modeling Enterprise
Architectures consistently within and across domains.
Since both TOGAF and ArchiMate are standards maintained by the Open Group
and they both are used in enterprise architecture development, many people
are confused between them, asking questions like "what's the difference
between TOGAF and ArchiMate?", "TOGAF vs ArchiMate?", etc. The TOGAF
framework and the ArchiMate modeling language are both maintained by The
Open Group. The TOGAF 9.1 and ArchiMate 2.1 or above work well together
and are compatible and complementary for EA development. While TOGAF
ADM is an EA framework that can be used to develop and implement
enterprise systems, processes, and structures, ArchiMate can be served as a
visual modeling language that can be used to create EA descriptions.
It is important to reiterate that the ArchiMate standard is a modeling language
and not a framework. The ArchiMate language is widely used for developing
visual EA models, usually in conjunction with the TOGAF ADM. Moreover, the
TOGAF and ArchiMate standards can put together to provide a set of
viewpoints that can be applied for modeling the different architectures.
The ArchiMate language consists of the ArchiMate core language, which
includes the Business, Application, and Technology Layers, along with elements
to model the strategy and motivation underlying an architecture, as well as its
implementation and migration.
The figure below shows a simplified mapping of how the ArchiMate language
can be used in relation to the phases of the TOGAF Architecture Development
Method (ADM).
ArchiMate Core
The code ArchiMate layers enables modeling of the architecture domains
defined by TOGAF.
The Business, Application, and Technology Layers support the description of
the Business, Information Systems, and Technology Architecture domains
defined by the TOGAF framework, as well as their interrelationships.

Strategy and Motivation Extension

The strategy & motivation extension enables the modeling of stakeholders,
drivers for change, business goals, principles and requirements.
The strategy and motivation elements in the ArchiMate language can be used
to support the Requirements Management, Preliminary, and Architecture
Vision phases of the TOGAF ADM, which establish the high level business
goals, architecture principles, and initial business requirements. They are also
relevant to the Architecture Change Management phase of the TOGAF ADM,
since the phase deals with changing requirements.

Implementation and Migration Extension

The implementation and migration extension enables the modeling of project
portfolio management, gap analysis and transition and migration planning.
The implementation and migration elements of the ArchiMate language
support the implementation and migration of architectures through the
Opportunities and Solutions, Migration Planning, and Implementation
Governance phases of the TOGAF ADM.
TOGAF ADM Lifecycle - Iteration
The ADM supports the concept of iteration at three levels:
Cycling around the ADM: The ADM is presented in a circular manner
indicating that the completion of one phase of architecture work directly feeds
into subsequent phases of architecture work.
Iterating between phases: TOGAF describes the concept of iterating across
phases (e.g., returning to Business Architecture on completion of Technology
Architecture).
Cycling around a single phase: TOGAF supports repeated execution of the
activities within a single ADM phase as a technique for elaborating architectural
content.
TOGAF ADM
During application of the ADM process, a number of outputs are produced
based on some inputs and steps according to the phase objective provided by
the ADM.
For example:
 process flows
 architectural requirements
 project plans
 project compliance assessments
 etc.

In order to collate and present these major work products in a consistent and
structured manner, TOGAF defines a structural model, in which to place them.

ADM Input and Output

TOGAF provides a number of input and output deliverables from each phases:
 These are suggestions and need not be followed exactly
 Each deliverable produced should be versioned to indicate when a
change has occurred
 The version numbering shown is also a suggestion and need not be
followed

Deliverables
A work product that is contractually specified and in turn formally reviewed,
agreed, and signed off by the stakeholders. It will typically be archived at
completion of a project, or transitioned into an Architecture Repository as a
reference model

ADM Preliminary Phase

The preparation and initiation activities required to create an Architecture
Capability including customization of TOGAF and definition of Architecture
Output Deliverables:
 Architecture principles
 Architecture repository
  Business principles, business goals, and business drivers
 Organization model for enterprise architecture
 Request for architecture work
 Tailored architecture framework

ADM Phase A: Architecture Vision

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
Output Deliverables:
 Architecture principles
 Architecture roadmap
 Architecture vision
 Business principles, business goals, and business drivers
 Capability assessment
 Communications plan
 Statement of architecture work
 Tailored architecture framework

ADM Phase B: Business Architecture

Business Architecture: the development of a Business Architecture to support
the agreed Architecture Vision
Output Deliverables:
 Architecture definition document
 Architecture principles
 Architecture requirements specification
 Architecture roadmap
 Business principles, business goals, and business drivers
 Statement of architecture work

ADM Phase C: Information Systems Architecture

Information Systems Architectures: the development of Information Systems
Architectures to support the agreed Architecture Vision
 Architecture definition document
 Architecture principles
 Architecture requirements specification
 Architecture roadmap
  Statement of architecture work

ADM Phase D: Technology Architecture

Technology Architecture: the development of the Technology Architecture to
support the agreed Architecture Vision
Output Deliverables:
 Architecture definition document
 Architecture principles
 Architecture requirements specification
 Architecture roadmap
 Statement of architecture work

ADM Phase E: Opportunities & Solutions

Opportunities & Solutions conducts initial implementation planning and the
identification of delivery vehicles for the architecture defined in the previous
phases
Output Deliverables:
 Architecture definition document
 Architecture requirements specification
 Architecture roadmap
 Architecture vision
 Capability assessment
 Implementation and migration plan
 Statement of architecture work

ADM Phase F: Migration Planning

Migration Planning addresses how to move from the Baseline to the Target
Architectures by finalizing a detailed Implementation and Migration Plan
 Architecture building blocks
 Architecture definition document
 Architecture requirements specification
 Architecture roadmap
 Change request Implementation and migration plan
 Implementations governance plan
 Request for architecture work
 Statement of architecture work

ADM Phase G: Implementation Governance

Implementation Governance provides an architectural oversight of the
implementation
Output Deliverables:
 Change request
 Compliance assessment
 Solution building blocks
 Statement of architecture work

ADM Phase H: Architecture Change Management

Architecture Change Management establishes procedures for managing
change to the new architecture Requirements Management examines the
process of managing architecture requirements throughout the ADM
Summary
The ADM is a comprehensive general method
 It recommends a sequence for various phases and steps involved in
developing an architecture
 It is an iterative method
 It draws on the other parts of TOGAF for assets and processes
 It can be used with other deliverables from other frameworks

Here is the overview of the TOGAF ADM for each of the development phase as
shown in the following Figure:
TOGAF ADM Phase Phase Objective

Preliminary Prepares the organization for a successful architecture project

Sets the scope, constraints and expectations for the project. Valid
A. Architecture Vision
context and create the Statement of Architecture Work
B. Business Architecture Develop Business Architecture. Develop baseline as-is and target
 the gaps.
C. Information Systems Develop Information Systems Architectures. Develop baseline as-
Architectures and analyze the gaps.
Develop Technology Architecture. Develop baseline as-is and targ
D. Technology Architecture
analyze the gaps.
E. Opportunities and
Identify major implementation projects
Solutions
F. Migration Planning Analyze the costs, benefits and risks. Produce an implementation
G. Implementation
Ensure that the implementation projects conforms to the architec
Governance
H. Architecture Change Ensure that the architecture responds to the needs of the enterpr
Management arise
Requirements Management Every stage of the project should be based on and validate busine
Related Links

1. More about TOGAF ADM Guide-through

2. More about Just-in-Time TOGAF Templates
3. More about ArchiMate tools
4. Try Visual Paradigm FREE