TOGAF 9 Methodology Ver1 0

Summarised Approach - 2010

Architecture Approach

Architecture Development

Preliminary

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

1.Organisational

Context

2.Identify

Stakeholders

3. Stakeholder

Involvement

4. Work Requirements

5. Identify Scope

6. Architecture

Footprint

7. Architectural

Framework

8. Governance

Framework

9. Supporting Tools

10. Architecture

Principles

Objectives

Approach

WHERE•The Enterprise

WHAT•Define Organisational Context

WHY•Requirements for Architecture Work

WHO•Architectural Principles

HOW•Management Frameworks

Approach

Interoperability and

Relationships between

Management Frameworks

Management Frameworks

Determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures.

Determines how a company manages its change initiatives.

Describes how a company runs its day-to-day operations, including IT.

Formalizes the way that business systems are delivered in accordance with the structures developed in the IT architecture

Inputs

Input

Architectural Inputs

1. Existing Frameworks

2. Existing Principles

3. Organisational Model

Reference Materials

External to the

Enterprise

1. TOGAF

2. Other Frameworks

Non-Architectural Inputs

1. IT Strategy

2. Governance

Frameworks, etc,

Steps

Implement

Architecture Tools

Select and Tailor

Architecture Framework(s)

Identify and Establish Architecture

Principles

Define and Establish Enterprise Architecture Team and

Organisation

Confirm Governance and Support Frameworks

Scope the Enterprise Organisations Impacted

Output

Organisational Model for Enterprise Architecture

1

Tailored Architecture Framework

2

Architecture Repository

3

Restatement

4

Request for Architecture Work

Governance Framework

Inclusive of additional information

Inclusive of additional information

Populated with framework content

Business principles, goals, and drivers

56

Architecture Vision

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

1.

Recognition

and

Endorsement2.

Define and

Organise

3.

Validate

Business

KPI’s

4.

Scope and

Prioritise

Baseline

5.

Define

Stakeholders

and their

concerns6.

Key Business

Requirements

7.

Articulate

Architecture

Vision

8.

Create

Comprehensi

ve Plan

9.

Formal

Approval to

Proceed

10.

Impact of

Parallel

Architectures

Objectives

Approach

General

•What is in, and What is outside the scope of the architecture effort

•Constraints informed by the business principles and architecture

principles

Architecture

Vision

•Architecture Vision describes how the new capability will meet the

business goals and strategic objectives and address the

stakeholder concerns when implemented.

Business

Scenarios

•Identifying and articulating the business requirements implied in

new business capability to address key business drivers, and the

implied architecture requirements.

Inputs

Input


1. Organisational Model

for EA

2. Tailored Architecture

Framework

3. Populated Architecture

Repository

Reference Materials

External to the

Enterprise

1. Architecture

Reference Materials


1. Request for

Architecture Work

2. Business principles,

goals, and drivers

Steps

SAW

Business

transformation

Target Architecture

and KPIs

Develop Architecture Vision

Architecture principles, including

business principles

Define scope

Assess readiness for business transformation

Evaluate business capabilities

Business goals, drivers, and constraints

Identify stakeholders, concerns, and business requirements

Establish the Architecture Project

Output

Approved Statement of Architecture Work

1

Refined Statements

2

Tailored Architecture Framework

3

Architecture Vision

4

Communications Plan

Architecture Repository

Scope, Plan, Roles, Risks, Assessment, Business Case and KPI’s

Business Principles, Goals, Drivers

Tailored architecture method, and content.Configured and deployed tools

Stakeholder RequirementsBaseline and Target Business, Technology, Data, Application Architecture

56

Additional Content

Business Architecture

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Baseline

Business

Architecture

2.

Target Business

Architecture

3.

Gap Analysis

4.

Architecture

Viewpoints

5.

Tools and

Techniques

Approach

General

•The Business Strategy typically defines What to achieve – Business Architecture’s role is to define How

to get there

Baseline

Description

•The analysis of the current state often has to be done bottom-up, particularly where little or no

architecture assets exist

•The goal should be to re-use existing material as much as possible

Business

Modelling

•Business models should be logical extensions of the business scenarios from the Architecture Vision,

so that the architecture can be mapped from the high-level business requirements down to the more

detailed ones

Architecture

Repository

•Generic business models relevant to the organization’s industry sector

•Business models relevant to common high-level business domains

•Enter prise-specific building blocks

•Applicable standards

Inputs

Input


•Organisational Model for EA

•Tailored Architecture Framework

•Populated Architecture

Repository

•Approved SAW

•Enterprise Continuum

•Architecture Repository

•Architecture Vision

Reference Materials

External to the Enterprise

•Architecture Reference

Materials


• Request for Architecture Work

• Business principles, goals, and

drivers

•Capability Assessment

•Communication Plan

Steps

Create

Architecture

Definition

Document

Finalize the

Business

Architecture

Conduct for mal stakeholder

review

Resolve impacts across the Architecture

Landscape

Define roadmap components

Perform gap analysis

Develop Target Business Architecture Description

Develop Baseline Business Architecture Description

Select reference models, viewpoints, and tools

Output

Architecture Vision Updates

1

Draft Architecture Definition Document

2

Draft Architecture Requirements Specifications

3

Business Architecture Components

4

SAW, Validate Business principles, drivers, Architecture Principles

Baseline, Target and Views for Business Architecture

Gap Analysis, Technical Requirements, Updated Business Requirements

Of an Architecture Roadmap

Information Systems

Architecture

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1. Target Architectures

a. Data System

Domain

b. Application

System Domain

ApproachDevelopment

•Combination of Data and Application

Architecture

Implementation

• implementation approach is top-down

design and bottom-up

implementation

Inputs

Input





•Approved SAW




•Data and Application Principles

•Draft Architecture Document

Reference Materials

External to the

Enterprise

•Architecture

Reference Materials

Non-Architectural

Inputs

• Request for Architecture

Work

• Capability Assessment


StepsApplication Architecture

Data Architecture

Output


1


2


3

Information System Architecture Components

4

Statement of Architecture Work (SAW)

Baseline, Target and Views for Application and Data Architectures

Gap Analysis Results, Technical Requirements, Updated Business Requirements


Data Architecture

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Data Sources

understandable by

Stakeholders

2.

Data Sources that

are complete and

consistent

3.

Data Sources that

are stable

Approach

Key Considerations

for Data Architecture

• Data Management

• Data Migration

• Data Governance

Architecture

Repository

• generic data models relevant to the

organization’s industry ‘‘vertical’’ sector

Inputs

Input





•SAW




•Data Principles


•Draft Arch. Req. Spec

•Bus Arch. Road Map

Reference Materials

External to the

Enterprise

•Architecture

Reference

Materials

Non-Architectural

Inputs

• Request for

Architecture Work



Steps

Definition

Document

Finalize the Data

Architecture


review


Landscape



Develop Target Data Architecture Description

Develop Baseline Data Architecture Description


Output


1


2


3

Data Architecture Components

4

Statement of Architecture Work (SAW), Validated Data Principles

Baseline, Target and Views for Data Architectures



Application Architecture

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Define the

application

system to

process data

and support

business

2.

Define what

application

systems are

relevant to the

organisation

3.

Logical groups

of Capabilities

that manage

data objects

4.

Technology

agnostic

5.

applications

that are stable

and relatively

unchanging

Approach

Architecture

Repository

•Generic business models relevant to the

organization’s industry sector

Inputs

Input





•Approved SAW




•Application Principles


•Draft Architecture Req. Spec.

•Bus and Data Components

Reference Materials

External to the

Enterprise

•Architecture

Reference Materials

Non-Architectural

Inputs


Work



Steps

Create

Architecture

Definition

Document

Finalize the

Application

Architecture


review


Landscape



Develop Target Application Architecture Description

Develop Baseline Application Architecture Description


Output


1


2


3

Application Architecture Components

4


Baseline, Target and Views for Application Architectures



Technology Architecture

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

To map

Application

Components into

Technology

Components

2.

Strong links to

implementation

and migration

planning

3.

Logical groups of

Capabilities that

manage data

objects

4.

Supports costs

assessments for

particular

migration

scenarios

ApproachArchitecture

Repository

•Existing IT services as documented in the IT repository

•TOGAF Reference Model

•Generic Technology Models

•Technology Models relevant to Common Systems Architecture

Inputs

Input





•Approved SAW




•Technology Principles



•Bus, Application and Data Components

Reference Materials

External to the

Enterprise

•Architecture

Reference Materials

Non-Architectural

Inputs


Work



Steps

Definition

Document

Finalize the

Technology

Architecture


review


Landscape



Develop Target Technology Architecture Description

Develop Baseline Technology Architecture Description


Output


1


2


3

Technology Architecture Components

4


Baseline, Target and Views for Application Architectures

Gap Analysis Results, Outputs from Phase B and C, Updated Technology Requirements


Opportunities and Solutions

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Review Business

Objectives and

Consolidate Gaps

2.

Review and

confirm the

enterprise

current

parameters

3.

Derive Transition

Architectures for

continuous value

4.

Consensus on

Implementation

and Migration

Strategy

Approach

Target Architecture

Implementation

•Concentrates on how to deliver the Architecture

•Logical Grouping within a IT Portfolio

•Assess the organization’s business transformation readiness

•Identify all implementation constraints

Enterprise Strategic

Change Perspective

•Opportunities and solutions is done in a top-down fashion or is approached in a

tactical opportunistic way

•Phased deliver y working towards the Target Architecture

Consolidation and

Integration

•Architecture artefacts (especially the gap analysis results) are consolidated and their

inter-dependencies closely assessed to derive an initial critical path

•A high-level Implementation and Migration Strategy is developed

Transition

Architectures

•Transition Architectures consist of a set of co-ordinated and well-defined building

blocks grouped into work packages that define the scope of deliver y vehicles

•Transition Architecture delivers discrete business value based upon the overall

enterprise capabilities

Inputs

Input



•Governance Models & Frameworks



•SAW






•Change Requests

Reference Materials

External to the

Enterprise

•Architecture Reference

Materials

•Product Information

Non-Architectural

Inputs

•Request for Architecture

Work



•Planning Methodologies

Steps

Portfolio

and Project

charters

Transition

Architectures

work packages

Implementation and Migration

Strategy

Confirm readiness and risk for business

transformation

Refine and validate dependencies

Consolidate and reconcile interoperability requirements

Review IT requirements from a functional perspective

Review and consolidate gap analysis results from Phases B to D

Determine business constraints for implementation

Deter mine/confirm key corporate change attributes

Output

Updates of Architecture Vision and other architectures

1

Consolidate and Validated Architecture Road Map

2

Capability Assessment

3

Transition Architecture

4

(SAW), Draft Architecture Definition Doc

Enterprise Architecture Maturity Profile, Transformation Readiness Report

Consolidated Gaps, Risk Register, Impact Analysis, Dependency analysis Report, Implementation Factor and Deduction Matrix

Implementation and Migration Plan

5

including the high-level Implementation and Migration Strategy

Migration Planning

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Coordination

with

Management

Frameworks

2.

Assigning

Business Value

and conduct

cost/business

analysis

3.

Finalise

Architecture

Vision and

Definition

Documents

4.

Confirm

Transition

Architectures

5.

Create, evolve

and monitor

implementation

and migration

plan

Approach

Implementation and

Migration Plan

•Creation of plan in cooperation with project and portfolio managers

Prioritised Projects

•Assessing the dependencies, costs, and benefits of the various migration projects.

•Prioritized list of projects will for m the basis of the detailed Implementation and

Migration Plan

Enterprise

Management

Frameworks

•Co-ordination to ensure that business value is delivered and that the resources are

made available to complete the necessary work.

•Agencies outside of the enterprise architecture world are aware of the scope

Architecture

Evolution Cycle

•Ensure that the architecture stays relevant, and lessons learned should be documented

to enable continuous process improvement

Inputs

Input






•SAW






•Change Requests

•Transition Architecture


•Implementation and Migration Plan

Reference

Materials

External to the

Enterprise

•Architecture

Reference

Materials

Non-

Architectural

Inputs

•Request for

Architecture Work

•Capability

Assessment


Steps

architecture

evolution cycle

Generate the Architecture

Implementation Roadmap

Confirm Transition Architecture

increments/phases

conduct of a cost/benefit assessment and risk

validation

Estimate resource requirements, project timings, and

availability/deliver y vehicle

Assign a business value to each project

Confirm management framework interactions for Implementation and Migration Plan

Output

Implementation and Migration Plan

1

Finalised Architecture Definition Document

2

Finalised Architecture Requirement Specification

3

Finalised Architecture Roadmap

4

Finalised Transition Architecture

5

Re-Usable Architecture Building Blocks

6

Request for Architecture Work

7

Architecture Contracts for Implementation projects

8

Implementation Governance Model

9

Change Request arising for Lessons Learned

10

Implementation Governance

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Recommenda

tions for each

implementati

on project

2.

Govern

Architecture

Contract

3.

Appropriate

Governance

Functions

4.

Ensure

Conformance

with defined

architecture

5.

Successful

Deployment

6.

Ensure

Conformance

with

deployed

solution

7.

Mobilise

Supporting

Operations

Approach

Implementation

Programme

•Establish an implementation program that will enable the deliver y of the

Transition Architectures agreed for implementation during the Migration

Planning phase

Phased Deployment

Schedule

•Adopt a phased deployment schedule that reflects the business priorities

embodied in the Architecture Roadmap

Organisation Standard

•Follow the organization’s standard for corporate, IT, and architecture

governance

Management

Approach

•Use the organization’s established portfolio/program management

approach, where this exists

Operations Framework

•Define an operations framework to ensure the effective long life of the

deployed solution

Inputs

Input






•SAW



•Architecture Vision and Contract



•Change Requests




Reference

Materials

External to the

Enterprise

•Architecture

Reference

Materials

Non-

Architectural

Inputs

•Request for

Architecture Work

•Capability

Assessment


Steps

post-implementation

review

Implement business and IT

operations

Perform enter prise architecture compliance

reviews

Guide development of solutions deployment

Identify deployment resources and skills

Confirm scope and priorities for deployment with development management

Output

Architecture Contract

1

Compliance Assessment

2

Change Requests

3

Architecture –compliant solutions deployed

4

Architecture Change

Management

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Baseline Fit-

for-purpose

2.

Assess

Performance

and Make

recommendati

ons

3.

Assess

Changes

4.

Architecture

Change

Management

Process

5.

Maximise

Business Value

6.

Operate

Governance

Framework

Approach

Drivers for Change

•Strategic, top-down directed change to enhance or create new capability (capital)

•Bottom-up changes to correct or enhance capability (operations and maintenance) for

infrastructure under operations management

•Experiences with the previously delivered project increments

EA Change

Management

Process

•Simplification change: A simplification change can normally be handled via change

management techniques.

•Incremental change: An incremental change may be capable of being handled via change

management techniques

•Re-architecting change: A re-architecting change requires putting the whole architecture

through the architecture development cycle again

Guidelines for

Maintenance vs. Re-

Design

•If the change impacts two stakeholders or more, then it is likely to require an architecture

redesign and re-entry to the ADM.

•If the change impacts only one stakeholder, then it is more likely to be a candidate for

change management

•If the change can be allowed under a dispensation, then it is more likely to be a candidate

for change management.

Inputs

Input






•SAW



•Architecture Vision and Contract



•Change Requests




Reference

Materials

External to the

Enterprise

•Architecture

Reference

Materials

Non-

Architectural

Inputs

•Request for

Architecture Work

•Capability

Assessment


Steps

Activate process

Manage governance

process

Develop change requirements to meet

performance targets

Provide analysis for architecture change

management

Manage risks

Deploy monitoring tools

Establish value realization process

Output

Architecture Updates

1

Changes to Architecture Framework and Principles

2

New Request for Architecture Work

3

Statement of Architecture Work

4

Updated Architecture Contract

5

Updated Compliance Assessments

6

Requirements Management

1. Objectives

2. Approach

4. Steps 3. Inputs

5. Outputs

Objectives

1.

Define an EA Process:

requirements are

identified

2.


requirements are

stored

3.


requirements are

synched with ADM

Phases

Approach

General

•Dynamic process whereby requirements for enterprise

architecture and subsequent changes to those

requirements are identified

•Process for managing requirements throughout the

overall ADM.

Resources

•Business Scenarios

•Volere Requirements Specification

•Requirements Tools

Inputs

Input

Statement of

Architecture

Work

A populated

Architecture

Repository

Tailored

Architecture

Framework

Requirements Impact

Assessment Architecture Vision

Architecture RequirementsTailored

Architecture Framework

Steps

Requirements Management Steps ADM Phase Steps

Step 1 Identify/document requirements — use business scenarios, or an analogous technique

Step 2 Baseline requirements:a. Determine priorities arising from

current phase of ADMb. Confirm stakeholder buy-in to

resultant prioritiesc. Record requirements priorities and

place in requirements repository

Step 3 Monitor baseline requirements

Step 4 Identify changed requirements:a. Remove or re-assess prioritiesb. Add requirements and reassess prioritiesc. Modify existing requirements

Step 5 Identify changed requirements andrecord priorities:

Step 6 a. Assess impact of changed requirements on current (active) phase

b. Assess impact of changed requirements on previous phases

c. Determine whether to implement change, or defer to later ADM cycle; if decision is to implement, assess timescale for change management implementation

d. Issue Requirements Impact Statement, Version n+1

Step 7 Implement requirements arising fromPhase H

Steps

Requirements Management Steps ADM Phase Steps

Step 8 Update the requirements repository with information relating to the changes requested, including stakeholder views affected

Step 9 Implement change in the current phase

Step 10 Assess and revise gap analysis for past phasesThe gap analysis in the ADM Phases B through D identifies the gaps between Baseline and Target Architectures.Certain types of gap can give rise to gap requirements.The ADM describes two kinds of gap:

•Something that is present in the baseline, but not in the target (i.e., eliminated — by accident or design)• Something not in the baseline, but present in the target (i.e., new)

Output

Requirements Impact Assessment

1

Updated Architecture Requirements Specification

2

TOGAF Version 9, The Open Group Architecture Framework (TOGAF), 2009

If you have one last breath use it to say...

TOGAF 9 Methodology Ver1 0

Documents

business scenarios

architecture goals

business transformation

business proceedkpis8

business strategy

enterprise business

architecture workexternal

architecture project