Togaf 9 Adm Introduction - Eng

8/13/2019 Togaf 9 Adm Introduction - Eng

1/21

Gteborg Stockholm www.biner.se

Vasaplatsen 2, 5tr Tel +46 31 743 07 80 United Spaces, Tel +46 8 22 90 10411 34 Gteborg Fax +46 31 743 07 81 Vasagatan 11, 1tr Tel +46 31 743 07 81

111 20 Stockholm

TOGAF9 and The Open Group

are registered trademarks of The Open

Group (opengroup.org).
http://www.biner.se/http://www.biner.se/http://www.biner.se/


2/21

TOGAF9 andThe Open Group is a registered trademark of the The Open Group (www.opengroup.org). 2 av 21

Summary

Companies and organizations are becoming increasingly dependent on being able to rapidly

change and develop their business models to compete in the international marketplace. Many

have discovered that they can take advantage of Enterprise Architecture (EA) to leverage more out

of their investments. The Open Group Architecture Framework (TOGAF) is a global standard for EA

that links business and IT, clarifies complex relationships, reduces costs, and facilitates change.

TOGAF provides businesses and organizations with a systematic and time-effective approach that

reduces the risk of overlooking important elements when planning and facilitating the devel-

opment of IT business systems.

The core of TOGAF is the Architecture Development Method (ADM), which is used to describe the

different architectures found in both business and IT. The ADM is a practical and business-driven

methodology that any organization can adapt and tailor for their Enterprise Architecture needs.

A key purpose of TOGAF is to ensure that the right projects are initiated and that their imple-

mentations are aligned in delivering value for both business and IT. The ADM makes it easy to

start the process of change within a defined area of an enterprise and then via a step by step

methodology use the same techiniques in other parts of the organization.


3/21


Contents

Summary ........................................................................................................................................................................................... 21 Introduction to TOGAF 9 ................ ................ ................ ................ ................ ................ ................ ................ ................. . 42 Concepts within TOGAF ................ ................ ................. ................ ................ ................ ................ ................ ................ .... 62.1 Which types of architectures are handled by the TOGAF? .........................................................62.2 A short introduction to Building Blocks .......................................................................................72.3 TOGAF ADM ...................................................................................................................................83 The ADM Phases .............. ................ ................ ................ ................ ................ ................ ................ ................ ................ ..... 93.1 The Preliminary Phase ................................................................................................................ 103.2 Phase A: Architecture Vision ...................................................................................................... 11

3.3 Phase B: Business Architecture ................................................................................................... 12

3.4 Phase C: Information Systems Architecture .............................................................................. 13

3.5 Phase D: Technology Architecture ............................................................................................. 153.6 Phase E: Opportunities and Solutions ....................................................................................... 16

3.7 Phase F: Migration Planning ...................................................................................................... 17

3.8 Phase G: Implementation Governance ...................................................................................... 18

3.9 Phase H: Architecture Change Management ............................................................................ 19

4 Glossary and abbreviations ............... ................ ................ ................ ................ ................ ................ ................ ............ 205 Selection of source references .................................................................................................................................... 206 Biner Consulting ............... ................ ................ ................ ................ ................ ................ ................ ................ ................ .. 21


4/21


1 Introduction to TOGAF 9TOGAF is a framework and a method for driving business transformation within an organization.

The concept of Enterprise Architecture (EA) connects the company's or organization's need for

business change with support from its IT systems. TOGAF facilitates and streamlines the process

of EA. With a well engineered Enterprise Architecture, you have a solid platform for future change

and development. The framework includes tools to initiate, manage and develop architectures.

TOGAF is based on an iterative process model that is developed from practical experience and

supported by a set of reusable architectural components. The first version of the framework was

first released in 1995 it has since been revised several times and the latest version of TOGAF 9

was released in February 2009.

The framework is developed by The Open Group, which is an international consortium of inde-

pendent suppliers. The work of The Open Group is based on its 200 members who represent all

business sectors. Some examples of member companies include, Capgemini, Fujitsu, HP, IBM,

NEC, U.S. Department of Defense, NASA and Sun Microsystems.

The framework provides the optimum environment for architects and managers to implement

change. TOGAF does this by:

providing a process for working with architecture

ensuring that all methodologies and frameworks within a business can work togetherdescribing dynamic systems in terms of architecture and solution building blocks

preparing the entire development cycle of a business project from the current state, through

temporary states, to the desired state

coordinating a conceptual model for the entire organization

ensuring that all stakeholders' perspectives are taken into account

providing a list of recommended standards

TOGAF can be used as a stand-alone framework or as a complement to other frameworks and

methodologies. TOGAF integrates well with other frameworks that are focused on a specific

industry (eg authorities, telecommunication, manufacturing, defense or finance) or practices

such as EFQM, TQM, Lean, Six Sigma, RUP, COBIT, SOA, Coso, ITIL and others.

The foundation of TOGAF is the Architecture Development Method Method (ADM), which is

used to develop formal descriptions of the specific business and operational needs. It is a practic-

al approach used to develop an Enterprise Architecture that is adapted for each organization.

The figure below shows the different phases of the ADM.

The ADM is a business-driven approach to develop architectures for the different domains (busi-

ness, information, application and technology) within any organization, while ensuring that the


5/21


related complex requirements are handled properly. This method can be used to analyze an en-

tire organization or a specific area within an organization. The term Enterprise in the term En-

terprise Architecturerefers therefore the area of scope selected for the work.

One of the key purposes of the ADM is to make sure that the right projects are started at the

right time according to a roadmap that covers both operational changes and changes in the

supporting IT systems. This plan should have been reviewed and approved by both business and

IT beforehand. By using TOGAF organizations can improve their working methods in various

management and governance functions:

performance management

risk management

IT governanceproject and program management

quality management

mergers and acquisitions


6/21


2 Concepts within TOGAF2.1 Which types of architectures are handled by the TOGAF?TOGAF 9 Architecture manages four interactive areas, which represent business, information,

applications and technologies. These four architectural domains are generally accepted as part of

an overall Enterprise Architecture and are managed in the ADM-cycle phases B, C and D.

Phase BBusiness Architecture

Business plans, strategies, organization and core processes.

Phase C Information Systems ArchitectureA structure for the organization's logical and physical information/data model.

Phase C

Application Architecture

The representation of the individual systems to be used, or that are to be used, their

interdependencies and their relationships to the business processes that use them.

Phase D

Technology Architecture

The software and hardware that is installed, or needs to be, to deliver application

services to the business.


7/21


2.2 A short introduction to Building BlocksBuilding Blocks in TOGAF

TOGAF utilizes reusable components called building blocks. Building blocks are "Lego bricks

that are used to create a solution or a description of architecture for an organization. In TOGAF

there are two types of building blocks, architectural building blocks and solution building blocks.

A particular feature, such as customer database, is an example of an architectural building block.

Finished products or customer-specific solutions are classified as solution building blocks.

Both these types of building blocks simplify the analysis of TOGAF-based projects and facilitate

communication between stakeholders. Another use for building blocks is that they help create

better integrated solutions between new and existing systems.

Architecture Building Blocks (ABB)

Architecture Building Blocks (ABB) describe the fundamental functionalities of an enterprise,

along with their characteristics and their relationships to other building blocks. Their connection

to the organizational units should also be clearly described. Architecture Building Blocks

represent the architecture requirements of the four architecture domains. Architecture Building

Blocks should guide and support the development of solution building blocks.

Solution Building Blocks (SBB)

Solution Building Blocks (SBB) are groupings and packages of functionalities that meet the needs

of the business. They define what product or component will be realized. A solution building

block describes the interfaces that need to be implemented. They can in turn consist of one or

more solution building blocks. A good building block should include a description of various

design decisions, such as why a specific physical architecture will be used. They should consist of

standardized components that are reusable and interchangeable.


8/21


2.3 TOGAF ADMTOGAFs Architecture Development Method consists of nine phases (preliminary phase and phas-es A H) related to the architectural domains of business, information and systems, and tech-

nology.

The ADM should be used iteratively between the phases and within phases. Throughout the

ADM cycle the results produced by it are verified against the original requirements, both those

for the whole cycle and those for a specific phase. Each phase uses the deliverable from previous

phases. In addition, other frameworks and models can be used in conjunction with ADM.

The ADM supports iterations at three levels

Iterating through the entire wheel. The

circular presentation of the ADM indicates

that the end of one phase is directly linked

to the start of the next phase.

Iterate between phases, you can, for exam-

ple, after the completion of Phase F return

to Phase E.

Iterate within a phase, you can use this

technique to deepen the analysis of a sin-gle phase.

Preparations for developing the architec-

ture are concentrated in the Preliminary

Phase and Phase A. In Phases B to D work

focuses on requirements gathering, mod-

eling and analysis. In phase E the focus is

on how the possible solutions, projects and

initiatives will work together. Phase F to

Phase H, connect the planning, manage-

ment and implementation of the identified

projects, solutions and changes.


9/21


3 The ADM Phases

One the following pages there is a summarized description of the details of the Architecture

Development Method. To facilitate the presentation the phases of the ADM cycle have been

placed horizontally as seen above.

Each phase is described using the same pattern: the inputs required to initiate that phase, what

activities are to be performed during the phase, the results that should be achieved, and finally,

examples of artifacts that should be created. All work in the respective phase is based on the

requirements scope of the enterprise under analysis.


10/21


3.1 The Preliminary Phase

Summary

The preliminary phase prepares the business to undertake and receive a successful TOGAF-based

project. This applies in particular to identifying the current business/IT frameworks, creating the

management structures for change control and governance of EA/business development, and

coordinating the different types of principles.

Inputs

Overall architectural principles

EA principles

Activities

Outputs

Current architecture principles and guidelines

Mapping of existing frameworks and reusable components

Request for Architecture Work

Organization model for the EA work

Custom EA framework

Initial library (repository) for EA artifacts

Framework for managing the EA

Architecture Building Blocks

Guidelines

1

Scope which areasof the enterprisethe iteration willeffect

2

Define and establishthe EA team andorganization

3

Identify and estab-lish architectureprinciples

4

Select and tailor anarchitecture frame-work

5

Implement an archi-tecture toolset

6

Verify and selectwhich architecturalprinciples will besupported

7

Develop the archi-tecture vision

8

Define the businessvalue the architec-ture will deliver

9

Define the metricsthat will be used toevaluate the archi-tecture


11/21


3.2 Phase A:Architecture Vision

Summary

Phase A establishes the project and starts an iteration of the ADM cycle for architectural devel-

opment. The organization should be fully prepared for a TOGAF-based project to be imple-

mented successfully. The focus is on describing the change so that it is possible to communicate it

to customers and those who will carry out the work.

The phase will be conducted every time an architectural change occurs. An architectural change

often happens when a new business initiative/project is started.

Inputs

The deliverables from the Preliminary Phase

Activities

OutputsCommunications Plan

Refined architecture principles Approved statement of architecture work

Preliminary application architecture Architecture Building Blocks

Preliminary technology architecture Project plan for architecture work

A0

Establish the archi-tecture project

A1

Identify stakehold-ers, concerns, and

business require-ments

A2

Define and elabo-rate business goals,

business drivers, andconstraints

A3

Select and tailor anarchitecture frame-

work

A4

Evaluate the busi-ness capabilities of

the organization

A5

Define the scope forthe architecturalwork

A6

Verify and selectwhich architecturalprinciples will besupported

A7

Develop the archi-tecture vision

A8

Define the businessvalue the architec-ture will deliver

A9

Define target archi-tectures valueproposition andKPIs

A10

Identify the businesstransformation risks

A11

Develop the state-ment of architec-ture work

A12

Develop the archi-tecture project plan,communication plan


12/21


3.3 Phase B:Business Architecture

Summary

In phase B, the business architecture that supports the new architecture vision is developed. It is

important that the new (target) architecture is compared with the current (existing) architecture

to identify the differences.

The phase will be implemented at least once per complete cycle of the ADM for a specific

project/task. Normally the phase is iterated through between phases B to F.

Input

Deliverables from Phase A

Activities

Outputs

Analysis of stakeholder concerns

Customized views of the architecture to show different perspectives to different stakehold-ers

Detailed current state and target state architectures for the business domain

Gap analysis between current state and target state

A work plan ("roadmap") which includes business architecture components


The specification for the business architecture

B0

Select reference models,

views, and tools

B1

Develop current state

business architecturedescription

B2

Develop target state busi-

ness architecture descrip-tion

B3

Perform gap analysis

B4

Define roadmap compo-

nents

B5

Conduct formal stake-

holder review

B6

Resolve impacts across the

architectural landscape

B7

Create architectural speci-

fication and architecturaldefinition documents


13/21


3.4 Phase C: Information Systems Architecture

Summary

In Phase C the organization's IT systems are documented in the form of the main information

types and the applications that use those data types. This work comprises of two main steps:

1. Document the data architecture's current state and target state2. Develop the application architecture's current state and target state

These steps can be performed sequentially or in parallel. The phase will be implemented at least

once per complete cycle of the ADM for a specific project/task. Normally the phase is iterated

through between phases B to F.

Inputs

Deliverables from the previous phases

Activities

Step 1: Data Architecture

C0

Select reference models,

views, and tools

C1

Develop current state data

architecture description

C2

Develop target state data

architecture description

C3


C4

Define roadmap compo-

nents

C5

Finalize data architecture

C6

Create architectural defini-

tion document


14/21


Step 2: Application Architecture

Outputs

Detailed current state and target state for the data architecture domain

Detailed current state and target state for the application architecture domain

Gap analysis between current state and target state

Analysis of the stakeholders concerns

Custom views of architectures for the various stakeholders

Guidelines for data and application architecture

Architectural components in a workplan

Standards

The specification for the architecture


Solution Building Blocks

C20

Select reference models,views, and tools

C21

Develop current stateapplication architecturedescription

C22

Develop target state appli-cation architecture de-scription

C23


C24

Define roadmap compo-nents

C25

Conduct formal stake-holder review

C26

Finalize application archi-tecture

C27

Create architectural defini-tion document


15/21


3.5 Phase D: Technology Architecture

Summary

In phase D the IT systems within the organization are documented in the form of current/target

configurations of hardware, software and communication technologies.

The focus is on developing and verifying the technology architecture in relation to the target

state for data and application architectures which has been found in previous phases. The phase

will be implemented at least once per complete cycle of the ADM for a specific project/task.

Normally the phase is iterated through between phases B to F.

Inputs


Activities

Outputs

Detailed current state and target state fortechnology architecture

The specification for the architecture

Gap analysis between current state and

target state


Analysis of the stakeholders concerns Solution Building Blocks

Customized views of architectures to fit

stakeholders

Use of standards

Guidelines for the technology architecture Work plan for architecture work

D0

Select reference models,views, and tools

D1

Develop current statetechnology architecturedescription

D2

Develop target state tech-nology architecture de-scription

D3


D4

Define roadmap compo-nents

D5

Conduct formal stake-holder review

D6

Finalize technology archi-tecture

D7

Create architectural defini-tion document


16/21


3.6 Phase E:Opportunities and Solutions

Summary

Phase E is the first phase that has direct contact with the implementation of the architecture. It is

here where we select and organize the reusable building blocks that will be used to create the

desired solutions. The solution architecture is then iteratively delivered to the business. An ex-

ample of this are solution building blocks that are iteratively improved and refined as more

phases are carried out in the ADM.


project/task. Normally the phase is iterated through between phases B to F.

Inputs


Activities

Outputs

Business Architecture

Data Architecture

Application Architecture

Technology Architecture

Models for transition architectures

Evaluation of capabilities

Recommendations for the use of stan-

dards

Implementation and Migration Plan


Solution Building Blocks

E0Determine and confirmkey corporate changeattributes

E1Determine business con-straints for implementa-tion

E2Review and consolidateGAP analysis from previousphases

E3Review IT requirementsfrom a functional perspec-tive

E4

Consolidate and reconcileinteroperability require-ments

E5

Refine and validate de-pendencies

E6

Confirm readiness and riskfor business transforma-tion

E7

Formulate high level im-plementation and migra-tion strategy

E8

Identify and group major

work packages

E9

Identify transition archi-

tectures

E10

Create portfolio and

project charters and up-

date architectures


17/21



111 20 Stockholm

3.7 Phase F:Migration Planning

Summary

Phase F describes how with the help of a detailed work plan, the implementation and migration

will take place to move from the current state architecture to the target architecture. This work

includes coordinating the plan with other governance practices/processes, organizational com-

ponents and individual stakeholders.


project/task.

Inputs


Activities

Outputs

Updated technology architecture Architectural specification document

Implementation governance model Requests for Architecture Work

Work plan & models for transition architectures Architecture Building Blocks

Evaluation of capabilities Solution Building Blocks

Implementation and Migration Plan Change requests

Architecture definition document

F0

Establish what the Imple-mentation and Migration

Plan should include

F1

Assign a business value toeach project

F2

Estimate resource re-quirements, project tim-

ings, and availability ve-hicles

F3

Prioritize the migrationprojects through

cost/benefit analysis

F4

Confirm transition archi-tecture increments andphases and update plans

F5

Create architecture im-plementation roadmapand migration plan

F6

Establish the architectureevolution cycle and docu-ment lessons learned


18/21



111 20 Stockholm

3.8 Phase G: Implementation Governance

Summary

Phase G controls how the architecture is implemented in the programs and projects. This gover-

nance organization will ensure that the projects comply with the requirements of the architec-

ture standards, guidelines, and principles. This is formalized in architecture contracts.

One way to be transparent in governance is to deliver a project architecture (both current and

target architecture) to projects.

Inputs


Activities

Outputs

Architecture contracts

Compliance assessments

Change requests

Architecture repository

Architecture compliance recommendations and dispensations

Impact of recommendations to the implemented architecture

Metrics

Architecture Vision for the next iteration of the ADM cycle

G0

Confirm scope and priorities for

deployment

G1

Identify deployment skills and re-

sources

G3

Guide development and solutions

deployment

G3

Perform EA compliance reviews

G4

Implement business and IT opera-tions

G5

Perform post implementation reviewand close the implementation


19/21


3.9 Phase H:Architecture Change Management

Summary

Phase H contains the processes for change management and is used to ensure that the architec-

ture serves both the business needs and maximizes the value of architecture for the business.

The work is focused on the analysis of the architecture in development and/or the architecture

being deployed. The analysis aims to identify improvement opportunities that would not be rec-

ognized in projects or organizational development.

The phase will be conducted at least once per cycle around the ADM.

Inputs


Activities

Outputs

Architecture updates

Architecture contract

Compliance assessments

Change requests

New reference for the development of architecture

H0

Establish ValueRealizationProcesses

H1

Deploy monitoringtools

H2

Manage risks

H3

Manage governanceprocess

H4

Activate process toimplement change


20/21


4 Glossary and abbreviationsWord/Abbreviation Description/Meaning

ADM Architecture Development Method

EA Enterprise Architecture

ABB Architecture Building Block

SBB Solution Building Block

Gap-analysisGap-analysis is a common name to identify, define and address the dif-

ference between an existing and a desired situation.

KPI Key Performance Indicator

CapabilityAbility of an organization, person, process, an application or IT service

to perform a particular task

5 Selection of source referencesName Source

TOGAF http://www.opengroup.org/architecture/togaf9-doc/arch/

Architecture and Solu-

tion Building Blocks

http://www.opengroup.org/architecture/togaf9-

doc/arch/chap37.html

The Open Group http://www.opengroup.org
http://www.opengroup.org/architecture/togaf9-doc/arch/http://www.opengroup.org/architecture/togaf9-doc/arch/chap37.htmlhttp://www.opengroup.org/architecture/togaf9-doc/arch/chap37.htmlhttp://www.opengroup.org/http://www.opengroup.org/http://www.opengroup.org/http://www.opengroup.org/architecture/togaf9-doc/arch/chap37.htmlhttp://www.opengroup.org/architecture/togaf9-doc/arch/chap37.htmlhttp://www.opengroup.org/architecture/togaf9-doc/arch/


21/21

6 Biner ConsultingBiner Consulting is a consulting company focusing on developing and changing businesses andorganizations (Business Transformation). We are specialists in the application of Enterprise Archi-tecture and change and project management to ensure and drive successful change initiativeswith our customers.

Biner Consulting operates in Europe and has offices in Stockholm and Gothenburg.

Biner Consulting provides accredited training, internationally recognized certifications, and con-sulting services in TOGAF 9.

For more information please seehttp://www.biner.se.

Gteborg

www.biner.se

Vasaplatsen 2, 5tr

411 34 Gteborg

Tel +46 31 743 07 80

Fax +46 31 743 07 81

Stockholm

www.biner.se

United Spaces, Vasagatan 11, 1tr

111 20 Stockholm

Tel +46 8 22 90 10

Tel +46 31 743 07 81
http://www.biner.se/http://www.biner.se/

Togaf 9 Adm Introduction - Eng

Documents

Transcript of Togaf 9 Adm Introduction - Eng