TOGAF9.

1 in Pictures

Preliminary

Architecture
Vision
Architecture
Change
Management

Implementation
Governance

Business
Architecture

Requirements
Management

Information
Systems
Architecture

Technology
Architecture

Migration
Planning
Opportunities
& Solutions

www.orbussoftware.com

Stage

The TOGAF ADM Cycle

The ADM is about understanding existing architectures and working out the
best way to change and improve them.
Never used without some adaptation, the ADM is more like a cookbook of
recommendations, ideas and checklists than a set way of doing things.

Preliminary

Stage

Opportunities & Solutions: Here we move away

from a wholly architectural perspective to figure out
how youre going to deliver, fund and resource the
changes.

Architecture
Vision

Architecture
Change
Management

Stage

Preliminary: Although out of the main circle, you

need to keep referring back to it to assess effectiveness
of both the EA team and its initiatives. This stage is
about the on-going improvement of EA capabilities.
Architecture Vision: This isnt a one-off before
everything else - architecture visions emerge slowly.
And EA is unique in having a holistic view of all
stakeholders, complexity and change, and this is
constantly evolving. Communication is the key.

Think of it in three chunks and bear in mind that in a large enterprise, there
may be quite a few projects all using different phases of the ADM.

Find ways to make the changes,

and then make it happen

Set up an EA team and make sure it

can do its work

Business
Architecture

Business Architecture: Its important to be

independent from technology - planned or current.
Focus on business capabilities, process, and products,
and relate all analysis to business from an architectural
perspective.

Migration Planning: The detailed planning here is

more the province of project managers than architects,
but get involved to make sure commitment is in line
with the architecture vision.
Implementation Governance: Along with
the policing role of monitoring each project
and solution, this plase needs a delicate political
sensitivity to remind people of the long term vision
and persuade them not to compromise.

Implementation
Governance

Architecture Change Management: When projects

and solutions are unable to meet original expectations
- due to cuts in spending, changes in priority or lack of
funding and resources - you need to revisit the other
phases to address the consequences.
Requirements Management: At the heart of the
EA role, this is where a good EA can manage diverse
stakeholder concerns and create an integrated view
of how the architecture will evolve. All work products
created or used in the other phases are managed here!

Get a good picture of the

architecture: Now and in the future

Requirements
Management

Information
Systems
Architecture

Information System Architcture: ISA breaks down

into data and applications. It doesnt matter which one
you start with - its likely that youll have to adjust both
as the bigger picture emerges.
Technology Architecture: Focus here is on
architecture of IT platforms, especially hardware
and communications. Its important to separate the
different concerns of business, information systems
and technology stakeholders.

Technology
Architecture

Migration
Planning
Opportunities
& Solutions

www.orbussoftware.com

Outputs

The Preliminary Phase

Preliminary

This phase prepares the way for the initiation of the ADM. The outputs from
the steps conducted are the foundation from which the ADM is worked.
Almost all of the documentation produced in the Preliminary Phase
will be used as inputs to the other phases and/or will be
Architecture
updated in each phase.
Change

Specifically, the Preliminary Phase is where definitions are established for:

- What the enterprise is

- Key drivers and elements in the organizational context

- Requirements for architecture work

- Architecture principles

- The framework to be used

- The relationships between management frameworks

- Evaluating the enterprise architecture maturity

Architecture
Vision
Business
Architecture

Management

Architecture
Governance Framework
Organizational Model for
Enterprise Architecture

Inputs

Requirements
Management

Implementation
Governance

Information
Systems
Architecture

Technology
Architecture

Migration
Planning

Opportunities &
Solutions

Tailored Architecture
Framework

Inputs are gathered from many resources both internal and external. Ideally, they are obtained from
previous architecture work stored as artifacts and building blocks in a repository, but they can also
be pulled from industry standards.

Executives

- Organizational Model for Enterprise Architecture

- B
 oard strategies and board business plans, business
strategy, etc

Stakeholders

- Major frameworks
- Partnership and contract agreements

Architecture
Board

Architecture Metamodel

Request for
Architecture Work

- Architecture capability

- Governance and legal frameworks

Architecture Repository

Architecture
Landscape

Principles
1. Business
2. Data
3. Application
4. Technology

Reference
Library

Standards
Information
Base

Governance Log
Architecture Capability

Steps
Preliminary Phase steps center on identifying organizations involved, how the enterprise is governed, finding the right people to conduct the
transition from current to target architectures, firmly define principles by which all aspects of the transition can be judged, integrating TOGAF
into the corporate environment, and selecting the right tools for the right job.

Scope Enterprise
Organizations

Define Principles

Confirm Governance
and Support

Implement
Architecture Tools

www.orbussoftware.com

Establish
Architecture Team

Tailor Frameworks

Outputs

Phase A - Architecture Vision

Preliminary

This is where we start to get a definition of the future architectures

as a Vision, as a Statement of Work, and as a draft Architecture
Definition Document.

Starts with receipt of a Request for Architecture Work.

Later Phases expand these initial outputs to produce the

detailed plan for delivering the proposed changes.

Its objectives are:

- To develop a high-level vision of the capabilities and business value delivered
by the proposed enterprise architecture

- To gain approval for a Statement of Architecture Work that defines the
program of works to develop and deploy the proposed architecture.

Architecture
Vision

Architecture
Change
Management

Requirements
Management

Implementation
Governance

Architecture Vision

Business
Architecture

Information
Systems
Architecture

including a problem
description, key requirements,
summary views and objectives

Inputs

Technology
Architecture

Migration
Planning

The key input is the Request for Architecture Work, together with everything necessary to outline an
effective vision and proposed future architectures.

Reference Materials

Approved Statement of
Architecture Work

including an overview of the

Architecture Vision and a
project description, scope, plan
and schedule

Architectural Inputs

Any useful architecture reference

materials (often from external
sources)

Non-Architectural Inputs
The Request for Architecture Work,
plus related business principles,
goals and drivers

Opportunities
& Solutions

T
 he Organizational model for EA,
including which organizations are
impacted by the changes, maturity
analysis, roles and responsibilities, and
governance and support strategy
T
 ailored Architecture Framework,
covering the tailored method,
content, principles and tools
P
 opulated Architecture Repository,
including any existing documentation

A Capability Assessment

A Communication Plan

 raft Architecture
D
Definition Document

including version 0.1 of

baseline and target business,
data, application and
technology architectures

Updated principles,
goals, drivers, and
architecture framework

Steps

This Phase is vital for outlining a resolution to Stakeholder concerns in architectural terms as an architecture vision and value
propositions and securing Stakeholder commitment and approval. All steps are important, but key steps are shown in purple!

Establish the
Architecture Project

Identify Stakeholders,
Concerns and
Business
Requirements

Develop
Architecture Vision

Evaluate Business
Capabilities

Define Target
Architecture Value
Propositions and KPI

Assess Readiness
for Business
Transformation
Identify Business
Transformation
Risks and
Mitigation Activities

www.orbussoftware.com

10

Define Scope
Develop Statement of
Architecture Work and
Secure Approval

Confirm and Elaborate

Architecture Principles

Phase B, C & D - Common Elements

Inputs
Reference Materials External to the Enterprise:

Reference Materials

Although Phases B, C and D deal with different architecture domains, the basic structure for each
Phase is very similar.

Steps

- Application principles

Select Reference Models, Viewpoints, and Tools

- Determine Overall Modeling Process

- Identity Required Service Granularity Level, Boundaries, and Contracts

- Identify Required Catalogs of [Business, Data, Application, Technology]
Building Blocks

- Identify Required Matrices

- Identify Required Diagrams

- Identify Types of Requirement to be Collected

- Select Services

- Data principles

- Technology principles

4
7

Define Candidate
Roadmap
Components
Finalize the
Architectures

5
8

Resolve Impacts across

the Architecture
Landscape

3
6

Opportunities
& Solutions

Organizational Model for EA

Tailored Architecture Framework
- Architecture principles

Information
Systems
Architecture

Technology
Architecture

Migration
Planning

Architectural Inputs

Perform Gap
Analysis

Business
Architecture

Requirements
Management

Implementation
Governance

Request for Architecture Work

Business principles, business goals,
and business drivers
Capability Assessment
Communications Plan

- The Technology Architecture shows how it enables the logical and physical
data components and the Architecture Vision

Develop Target
Architecture
Description

Architecture
Change
Management

Non-Architectural Inputs

- The Information Systems Architecture describes how it will enable the Business
Architecture and the Architecture Vision

Develop Baseline
Architecture
Description

Architecture
Vision

P
 roduct information on
candidate products

Each domain has to:

- Develop the Target Architectures in a way that addresses the Request for Architecture
Work and stakeholder concerns.

- Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Targert Architectures

- The Business Architecture describes how the enterprise needs to operate to achieve the
business goals, and respond to the strategic drivers set out in the Architecture Vision

Preliminary

Architecture domains
described by TOGAF Key
Business Architecture

 pproved statement of Architecture Work

A
Enterprise Continuum
Architecture Vision
Architecture Repository
Draft Architecture Definition Document
Draft Architecture Requirements Specification
Domain Architecture components of an
Architecture Roadmap

Information System
Architecture
Data Architecture
Application Architecture
Technology Architecture

Outputs
Refined and updated versions of the Architecture Vision phase deliverables, where applicable

Conduct Formal
Stakeholder Review

Draft Architecture
Definition Document

Create Architecture
Definition Document

Draft Architecture
Requirements Specification

www.orbussoftware.com

Domain Architecture
components of an
Architecture Roadmap

Phase E - Opportunities and

Solutions

Outputs
Here we have a consolidated view of all four architecture
domains, and the first outline of how we are going to
implement the architecture requirements which will
become more detailed & be confirmed in Phase F

Phase E covers the process to:

- Generate the initial complete version of the Architecture Roadmap, based on:

- The Gap Analysis

- Candidate Architecture Roadmap components from Phases B, C, and D

- Determine whether an incremental approach is required - and if so, to identify
Transition Architectures that will deliver continuous business value

Refined Architecture
Vision

Requirements
Management

Information
Systems
Architecture

Technology
Architecture

Migration
Planning

Draft Architecture
Requirements Specification

T
 he Organizational model for EA, Governance
Model & Framework, Tailored Architecture
Framework, Architecture Repository
S tatement of Architecture Work &
Architecture Vision
D
 raft Architecture Definition Document
(including baseline & target architectures)
Draft Architecture Requirements Specification
C
 andidate Architecture Roadmap
components from Phases B, C & D

The Request for Architecture

Work, Capability Assessment,
Communications Plan, & Planning
Methodologies

Business
Architecture

Opportunities
& Solutions

Architectural Inputs

Non-Architectural Inputs

Implementation
Governance

Draft Architecture
Definition Document

The key inputs are from the Architecture Definition Phases (B, C & D), which are then
consolidated and matched to investment opportunities & solution products

Architecture reference materials &

product information

Architecture
Vision
Architecture
Change
Management

Inputs
Reference Materials

Preliminary

Architecture Roadmap

Capability Assessments

including Work
Package Portfolio,
Transition Architectures,
& Implementation
Recommendations

Implementation &
Migration Plan (version 0.1)

Steps

Phase E is about architecture delivery. It amalgamates the gaps between Target & Baseline Architectures in all architecture domains, & groups changes into work packages to build a
best-fit roadmap based on stakeholder requirements, the enterprise's business transformation readiness, identified opportunities & solutions and implementation constraints.

Identify Key Business Drivers

Constraining Sequence of
Implementation

2
5

Review Gap Analysis from Phase D

Perform Architecture Assessment
and Gap Analysis

3
6

Brainstorm Technical Requirements

from Functional Perspective
Identify Major Work Packages
or Projects

www.orbussoftware.com

Brainstorm Co-existence and

Interoperability Requirements

Outputs

Phase F - Migration Planning

Preliminary

Outputs show dependencies, costs, and benefits of the various

migration projects in the final version of the Implementation and
Migration Plan.

Phase F is where we create an Implementation and Migration Plan

in co-operation with portfolio and project managers.

- Finalize the Architecture Roadmap

- Finalize the supporting Implementation and Migration Plan, making sure that
it is coordinated with the enterprise change management approach and the
overall change portfolio

- Ensure the value and cost of work packages and Transition Architectures is
understood by stakeholders

The architecture development cycle is completed here,

with lessons learned enabling continuous improvement
to the EA process.

Architecture
Change
Management

Implementation
Governance

Implementation and
Migration Plan (Version 1.0)

Inputs

Architectural Inputs

Any useful architecture reference

materials (often from external
sources)

Non-Architectural Inputs
The Request for Architecture
Work, Capability Assessment and
Communications Plan

Requirements
Management

Information
Systems
Architecture

Technology
Architecture
Opportunities
& Solutions

Reusable Architecture
Building Blocks

Finalized Architecture
Definition Document

T
 he Organizational Model for EA;
Governance models and frameworks;
Tailored Architecture Framework;
Statement of Architecture Work and
Architecture Vision
P
 opulated Architecture Repository,
including reusable building blocks
D
 raft Architecture Definition Document
and Architecture Requirements
Specification
Architecture Roadmap and
Implementation and Migration Plan (v0.1)

Business
Architecture

Migration
Planning

including the Implementation and

Migration Strategy, and the Project
and portfolio breakdown of the
implementation

The key inputs are the incomplete Architecture Roadmap and Implementation and Migration Plan
from Phase E

Reference Materials

Architecture
Vision

including any Finalized Transition

Architectures

Finalized Architecture
Requirements Specification

Finalized Architecture
Roadmap

Request for Architecture

Work (for a new iteration
of the ADM)
Possible Change Requests
for Architecture Capability
from lessons learned

Steps

The level of detail addressed in Phase F will depend on the scope and goals of the overall architecture effort. All steps are important, but key steps are shown in purple!

Confirm Management
Framework Interactions for
the Implementation and
Migration Plan

Assign a Business Value to

Each Work Package

Generate the
Implementation and
Migration Plan

Estimate Resource Requirements,

Project Timings, and
Availability/Delivery Vehicle

Prioritize the Migration

Projects through the Conduct
of a Cost/Benefit Assessment

and Risk Validation

Complete the Architecture

Development Cycle and
Document Lessons Learned

www.orbussoftware.com

Confirm Architecture Roadmap

and Update Architecture
Definition Document

Outputs

Phase G - Implementation Governance

Outputs show dependencies, costs, and benefits of the various

migration projects in the final version of the Implementation and
Migration Plan.

Phase G is where all the information for successful management of the

various implementation projects is brought together. In parallel is the
execution of the development process, where the actual development
happens. Here we:

- Ensure conformance with the Target Architecture by implementation projects

- Perform appropriate Architecture Governance functions for the solution and
any implementation-driven architecture Change Requests

The architecture development cycle is completed here,

with lessons learned enabling continuous improvement
to the EA process.

Phase G establishes the connection between architecture and implementation organization, through the
Architecture Contract.

The Request for Architecture Work

and Capability Assessment

Compliance Assessments
and Change Requests

Business
Architecture

Requirements
Management

Opportunities
& Solutions

Request for Architecture

Work (for a new iteration
of the ADM)
Post-implementation update
of Architecture Vision and
Architecture Definition
Document

Business and IT operating

models for the implemented
solution

Steps

A key aspect of Phase G is ensuring compliance with the defined architecture(s), not only by the implementation projects,
but also by other ongoing projects. All steps are important, but key steps are shown in purple!

Confirm Scope and Priorities for

Deployment with Development
Management

2
5

Identify Deployment Resources

and Skills
Implement Business and
IT Operations

Information
Systems
Architecture

Technology
Architecture

Migration
Planning

including the implemented system,

populated architecture repository,
compliance recommendations &
dispensations, recommendations
on service delivery requirements &
performance metrics, Service Level
Agreements (SLAs)

T
 he Organizational Model for EA;
Tailored Architecture Framework; Request
for Architecture Work; Statement of
Architecture Work and Architecture Vision
Populated Architecture Repository,
including reusable building blocks
Architecture Definition Document and
Architecture Requirements Specification
Architecture Roadmap and
Implementation and Migration Plan
Architecture Contract and Implementation
Governance Model

Non-Architectural Inputs

Architecture
Change
Management

Architecture-Compliant
Solutions Deployed

Architectural Inputs

Any useful architecture reference

materials (often from external
sources)

Architecture
Vision

Implementation
Governance

Architecture Contract (signed)

Inputs

Reference Materials

Preliminary

3
6

Guide Development of
Solution Deployment
Perform Post-Implementation Review
and Close the Implementation

www.orbussoftware.com

Perform Enterprise Architecture

Compliance Reviews

Phase H - A
 rchitecture
Change Management

Outputs
When the Foundation Architecture needs to be re-aligned with strategy,
substantial change is required to components, standards or guidelines
for their use that have a significant end-user impact (e.g. regulatory
changes), then a refreshment cycle (partial or complete
Architecture
re-architecting) is required, and a new Request for Architecture
Change
Management
Work must be issued (to move to another cycle).

Phase H ensures that the architecture achieves its original target

business value, by managing changes to the architecture in a cohesive
and architected way. Here we ensure that:

- We maintain and follow the architecture lifecycle

- We work within the Architecture Governance Framework

- The Enterprise Architecture Capability meets current requirements

Changes are classified as Simplification, Incremental,

or Re-Architecting.
Implementation
Governance

Inputs

Architecture updates and

changes to architecture
framework and principles

Phase H is closely related to the architecture governance processes,and to management of the

Architecture Contract between the EA function and business users of the enterprise

Reference Materials

T
 he Organizational Model for EA;
Tailored Architecture Framework; Request
for Architecture Work; Statement of
Architecture Work and Architecture Vision
Populated Architecture Repository,
including reusable building blocks
Architecture Definition Document and
Architecture Requirements Specification
Architecture Roadmap and
Implementation and Migration Plan
Architecture Contract and
Implementation Governance Model
Change Requests for business and
technology changes and from lessons
learned; Compliance Assessments

Non-Architectural Inputs
The Request for Architecture Work

Architecture
Vision
Business
Architecture

Requirements
Management

Opportunities
& Solutions

New Request for

Architecture Work, to move
to another cycle
(for major changes)

Statement of Architecture
Work, Architecture Contract

Compliance Assessments
(updated if necessary)

Steps

The architecture change process determines how changes are to be managed, what techniques are applied, and what methodologies used. It also identifies
which phases of the ADM are impacted by changes e.g. changes that affect only migration may be of no interest to architecture development phases.

Establish Value
Realization Process

Deploy Monitoring
Tools

3
Manage
Governance Process

Manage Risks

4
Activate the Process to
Implement Change

www.orbussoftware.com

Provide Analysis for

Architecture Change
Management

Information
Systems
Architecture

Technology
Architecture

Migration
Planning

(for maintenance changes)

Architectural Inputs

Any useful architecture reference

materials (often from external
sources)

Preliminary

Develop Change
Requirements to Meet
Performance Targets

Architecture Requirements
Management

Inputs

The Requirements Repository holds information from multiple ADM cycles.

The Architecture Requirements Specification and Requirements Impact
Assessment hold information for a specific project.

The Requirements Management circle at the centre of the ADM graphic reminds us
that ADM is continuously driven by the requirements management process. In this
phase we:

- Ensure that Requirements Management process is sustained and operates
for all ADM phases

- Manage architecture requirements identified during any execution of the
ADM cycle or a phase

- Ensure that relevant architecture requirements are available for use by each
phase

Architecture Requirements
Specification
A
 populated Architecture
Repository
Organizational Model for
Enterprise Architecture
Tailored Architecture Framework
Statement of Architecture Work
Architecture Vision
Architecture requirements,
populating an Architecture
Requirements Specification
Requirements Impact Assessment

Steps

Requirements Management itself does not dispose of, address, or prioritize any
requirements, which is done in the relevant phase of the ADM. It is merely the process
for managing requirements throughout the overall ADM. Hence the split between
steps below:

Requirements Management Steps

1

Baseline requirements

Identify changed requirements

and record priorities

Monitor baseline requirements

Update the Requirements
Repository with information relating
to the changes requested, including
stakeholder views affected

ADM Phase Steps

1
3
5

Identify / Document
Requirements
Assess impact of changed
requirements and determine
whether to implement change
Implement change in the
current Phase

4
6

Architecture
Change
Management

Implementation
Governance

Business
Architecture

Requirements
Management

Information
Systems
Architecture

Technology
Architecture

Migration
Planning
Opportunities
& Solutions

Outputs
The Requirements Repository will be updated as part of the Requirements Management phase and
should contain all requirements information.

Identify changed requirements

Requirements Impact
Assessment
Architecture Requirements
Specification, if necessary

Implement changes arising from

Phase H
Assess and revise gap analysis
from past Phases

Architecture
Vision

Architecture requirements are invariably subject to change because

architecture deals with uncertainty and change. Dealing with changes in
requirements is crucial -the grey area between what stakeholders aspire to
and what can be delivered as a solution.

Preliminary

When new requirements arise, or existing ones are changed, a Requirements Impact Statement is
generated identifying phases of the ADM that need to be revisited. The statement goes through
various iterations until the final version, which includes the full implications of the requirements (e.g.,
costs, timescales, and business metrics). Once requirements for the current ADM cycle have been
finalized, the Architecture Requirements Specification should be updated.

www.orbussoftware.com

Business Scenarios

TOGAF 9.1: Guidelines and Techniques

Applying
the ADM
at Different
Enterprise
Levels

Applying
Iteration to
the ADM

CapabilityBased Planning

Guidelines

Architecture
Principles

Architecture
Patterns

Techniques

Business
Transformaon
Readiness
Assessment

Business
Scenarios

Environment

Objectives

Architecture
Vision

Computor Actors

Roles and
Responsibilities

Human Actors

Refine

Capabilities of the enterprise.

Technology
Architecture

Process
Capability Increment 3
Capability Increment 2
Capability Increment 1
Capability Increment 0

Research and
Development

Material

Architecture Partitioning
Break into bite-size chunks:
Enterprise Scope

Architecture Domains

Level of Detail

Project Schedules

Suppliers
Regulatory
Bodies

External

Scope
Baseline
Architecture
Time

Target
Architecture
Architecture Vision (Phase A)

Architecture Definition #1

www.orbussoftware.com

Transition
Architecture
3

Transition
Architecture
4

Transition
Architecture
5

Transition
Architecture
6

(Phases B, C & D)

Transition
Architecture
2

Architecture
Depth
(Content)

Architecture Definition #2

Transition
Architecture
1

Data Owners

Business Domain
Experts

Information
Systems
Architecture

Opportunities
& Solutions

Information
Management

Data/Voice
Communications
Technical Specialist

Infrastructure
Management
Product Specialist

Application
Management
Business Process/
Functional Experts

Service Desk

System
Operations

IT Service
Management
Executives

Line Management
Line Management

HR

Requirements
Management

Implementation
Governance

People

(Phases B, C & D)

Executives

Procurement

Project
Organization

QA/Standards
Group

End User
Organization

CxO

Corporate Functions

Program
Management
Office

Business
Architecture

Migration
Planning

Win support from stakeholders.

Enterprise
Security

Architecture
Change
Management

Capability Based Planning

Interoperability
Gap Analysis
Requirements Migration
Planning
Techniques

Stakeholder Analysis

Problem

Stakeholder
Management

Risk
Management

Using TOGAF
to Define &
Govern SOAS

Security
Architecture
and the ADM

Method within a method to identify and articulate business requirements.

Architecture Development

Adapting the ADM Process

Preliminary

Architecture
Realization

Architecture
Realization

Architecture
Realization

Architecture
Realization

Architecture
Realization

Architecture
Realization

Content MetaModel - Broken Down

TOGAF 9.1: Content and Continuum

Preliminary

Entitles and their Interactions

Select and customize...

Architecture Principles, Vision, Requirements and Roadmap

Principle

Content Framework - Description of Architectural Work Products

Constraint

Assumption

Requirement

Constraint

Assumption

Requirement

Principle

Deliverables, artifacts, building blocks and relationships

contains

Driver

owns
perform
task in

its motivated by

Role

Driver

contains

Re-Usable Building Blocks

Catalogs
Matrices
Diagrams

Artifacts
Which are

Business Architecture

Architecture Deliverables

Catalogs
Matrices
Diagrams

Describing

Building Blocks

Goal

resolves
generates

Objective

consumes

Event

Drivers

Goals

Data Entity

is processed by

encapulates

Organization

Organization Units
Business Services,
Contracts, Service
Qualitites

Locations

Process, Events,
Controls, Products

Foundation
Architectures

Logical Application
Components

Logical Technology
Components

Functions

Physical Data
Components

Physical Application
Components

Physical Technology
Components

Views and Viewpoints

Architecture
Contracts

Standards

Platform Service

Platform Service

Opportunities
& Solutions

realizes
Physical Technology
Component

realizes

Physical
Technology
Component

Application Architecture

contains

Technology Architecture

contains

Common
Systems
Architectures

Industry
Architectures

Guides

Foundation
Solutions

Common
Systems
Solutions

Industry
Solutions

Organization
Specific
Solutions

Support

Architecture Continuum
Search Progressively more General Architectures and Solutions for Candidate Components

Implementation Governance
Guidelines

Solutions Continuum
Organization
Specific
Architectures

Technology Architecture

Logical Data
Components

Work Packages

is supplied by

Architecture Continuum

Actors, Roles

Opportunities, Solutions, and Migration Planning

Capabilities

Stakeholders

Platform Services

Architecture Realization

Physical
Application
Component

Logical Technology
Component

Enterprise Continuum

Information System
Services

Function

encapulates

Logical
Application Comp

Information
System Service

realizes
Infra. Consolidation Ext.
Physical Application
Component

Infra. Consolidation Ext.

Information
System Service

Technology
Architecture

Migration
Planning

provides platform for

realizes
Services Ext.

Logical Application implements

Component

Logical Data
Component

Physical Data
Component

implements
Logical Application
Component

Logical Data
Component

Data Architecture

Data Entities

Measures

meets
Business Service

Data Entity

Gaps

Information Systems Architecture

Objectives

Contract

is goverened and
measured by

orchestrates

resolves

Physical Data
Component

Architecture Vision

Assumptions

Business Architecture
Motivation

Contract

meets
Service Quality

A Classification Framework

Architecture Requirements

Constraints

Service Quality

is bounded by

Measure

Data Modeling Ext.

Information
Systems
Architecture

Governance Ext.

Process

is resolved by

is tracked against

Architecture Requirements

Requirements

Process

generates

Event

consumes

Requirements
Management

participates in

is tracked against

supplies

Implementation
Governance

Control

orchestrates
is realized by

Location

Architecture Principles, Vision and Requirements

Business Principles,
Objectives, and Drivers

Control

is guided by

Process Modeling Ext.

contains

Location

Content Meta-Model - D
 escription of Building Blocks
and Relationships
Technology Strategy

Process Modeling Ext.

Function

Objective

contains

Business Strategy

Function

interacts with
Actor

is extended by

Architecture
Principles

produces

performs

Actor

Infra. Consolidation Ext.

Architecture Deliverables

Preliminary

Product

Product

is realized through

consumes
provides

Other Deliverables

Business
Architecture

All object types can be nested,

and have decomposition
relationships with themselves

Goal

Measure

Building Blocks

Capability

Architecture
Change
Management

Process Modeling Ext.

accesses

Role

motivates

Governance Ext.

Describing

Architecture
Vision

Capability

Work Package

produces

creates

Architecture Repository

Work Package

Gap

Organization Unit

Motivation Ext.

Architecture Deliverables

Gap

delivers

Associated
with a Objects

Architecture Continuum

Specifications
Foundation
Architectures

Common
Systems
Architectures

Industry
Architectures

Organization
Specific
Architectures

Solutions Continuum

Foundation
Solutions

Common
Systems
Solutions

Viewpoints

View

View

View

Salesperson

Electrician

Builder

Adapt Architectures and Solutions to Needs of Organization

Stakeholder

www.orbussoftware.com

Industry
Solutions

Organization
Specific
Solutions

Architecture Capability Framework

TOGAF 9.1: Models and Architecture

Structure Definition

How to establish an Enterprise Architecture function

Who organizes
What skills and roles

Technical Reference Model (TRM)

Training
Improves

Network Services

Skills

Operating System Services

Posses

Application Platform

Operating System Services

Improves

Roles and
Responsibilities
Requires
(both generic
Knowledge
and specific
Requires to a particular
project)
Posses

Architecture Professionals

Assigned

Application Platform Interface

Network Services
Communication Infrastructure Interface

Infra Apps

Communication Infrastructure

Management Utilities
Brokering Applications

Security

Compliance Levels
Compliance of projects

Application Format
Information Consumer
Applications

Management Policy
Information Provider
Applications

Development Tools

Qualities
Preformance SLAs

Irrelevant

Compliant

Consistent

Fully Conformant

Stewardship

Alignment

Guidance
Enterprise Architects
Domain
Architects

Diffusion
Conformance

Alignment

Chief Architect

Deploy
Service
Management

Implementation Change
Projects

Enterprise Continuum
Architectures

Processes

SLAs/OLAs
Operational
Systems

Re-using building blocks and

complying with standards

Skills Framework

Roles

Enterprise
Architecture
Business

Program/
Project
Manager

IT Designer

Building Block Design

CIO/CTO

Architecture
Board

Opportunities
& Solutions

Business
Operations

Architecture Views and

Viewpoints Design

Creation and monitoring of architectural components

Implementation
Program
Management
Office

Technology
Architecture

Migration
Planning

Define roles, skills and experience

Essential part of architecture governance Measure staff development right fit
Formulate IT compliance strategy

Governance

Develop

Projects/Portfolios

Information
Systems
Architecture

Architecture Repository

Model for business applications and infrastructure applications

Mobility

Projects/
portfolios
governed
against their Contract
contracts

Requirements
Management

Implementation
Governance

Enterprise Continuum (used to classify inputs to and outputs from the Repository)

Bus Apps

Measuring success

Project/Portfolio
Governance

Populating the
Repository

Integrated Information Infrastructure Reference Model (III-RM)

Qualities

Setting priority and focus

Skilled Resource Pool

Communication Infrastructure Interfaces

Graphics and Images

Data Management

Data Interchange

User Interface

International Operations

Local and Directory

Transaction Processing

Security

Software Engineering

System and Network

Management

Direct

Communication Infrastructure

Application Platform Interface

Business
Architecture

Setting
priority
and focus

Qualities

Delivering
aligned
solutions

Qualities

Architecture
Change
Management

Governance Bodies

Participates in

Top Down View

Participates in

Side View
Business Applications

Architecture
Vision

Business Capability for Architecture (Operating at a level of maturity)

A model and taxonomy of generic platform services

Infrastructure Applications

Preliminary

Authority
Structures

Benefits Analysis

Solutions

Regulatory
Requirements

Solutions Modeling

Business Interworking
Compliant

Organizational
Standards

Non-Conformant

Systems Behavior
Project Management
1

www.orbussoftware.com