TOGAF 9.

2
Vocabulary, Lifecycle,
Implementation and Practice

Ahmed Abd El Aziz

V9.2 Edition Copyright © 2009-2018
[email protected] All rights reserved
+20 100 177 8765 Originally Published by The Open Group, 2018
Updated by ILKD, 2020
0700820-02 L6σBB Not for distribution outside trainees
Module 1
Introduction
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

Introduction of audiences and instructors

Setting audience expectations

Introducing course logistics

Explaining the objectives, structure and contents of the course

3
Who We Are?

Name

Title

Organization

Experience

Expectations

4
Logistics

5
About this Course

This is a modular course

The course as a whole has set of

objectives

Each module has its own set of

objectives serving the course
objectives

6
Course Objectives

Introduce basic concepts of enterprise architecture and the TOGAF® 9

Be familiar with TAGAF® 9 features and methodology

Introduce TOGAF® 9 usage in real work

Prepare for TOGAF® 9 certification

7
Module 2
Management Overview
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To provide a management overview of the TOGAF® Standard and its

ecosystem

 The Open Group

 The Architecture Forum
 Why Enterprise Architecture?
 Why a framework?
 The TOGAF® Standard, Version 9.2
 The TOGAF® Library

9
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

10
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

11
About The Open Group

The Open Group is a global consortium that enables the achievement of

business objectives through technology standards

Its diverse membership of more than 580 organizations includes customers,

systems and solutions suppliers, tool vendors, integrators, academics, and
consultants across multiple industries.
The Open Group Vision

Boundaryless Information Flow™

 achieved through global interoperability
 in a secure, reliable and timely manner

“Boundaryless does not mean there are no boundaries – it means that

boundaries are permeable to enable business.”

13
The Open Group Mission

The mission is to driving the creation

of Boundaryless Information Flow™
achieved by:

Working with customers, suppliers,

consortia and standards bodies for

Requirements, policies, best

practices, interoperability,
specifications and open source
technologies, certification
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

15
Architecture Forum – Mission

The mission is to advance the vision of Boundaryless Information Flow

It initiates and manages project for:

 Providing broad and deep leadership to the EA community
 Validating, publishing, fostering, and maintaining best practices for EA
 Developing, organizing, researching, and publishing thought leaders in
EA

16
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

17
What is an Enterprise?

A collection of organizations that share a common set of goals

 Government agency
 Part of a corporation
 Corporation

Large corporations may comprise multiple enterprises

May be an “extended enterprise” including partners, suppliers and

customers

18
What is an Architecture?

An Architecture is the fundamental

concepts or properties of a system in
its environment embodied in:

 its elements,
 their relationships to each other
and the environment,
 and the principles governing its
design and evolution.

Adapted from ISO/IEC/IEEE 42010:2011

What is Enterprise Architecture?

Enterprise Architecture is:

 The organizing logic for
business processes and IT
infrastructure reflecting the
integration and standardization
requirements of the firm’s
operating model.[1]
 A conceptual blueprint that
defines the structure and
operation of an organization.
The intent of an Enterprise
Architecture is to determine how
an organization can most
[1] MIT Center for Information Systems Research effectively achieve its current
[2] SearchCIO.com
and future objectives. [2]
What is Enterprise Architecture?
Architecture Types

Business
Architecture

Application Data
Architecture Architecture

Technology
Architecture

22
Why Enterprise Architecture?

Digital Transformation is a key to business success

Good information management  competitive advantage

Current IT systems suffer from

 Fragmented, duplicated
 Poorly understood
 Not responsive to change

Investment in Information Technology

 Focussed on system maintenance
 Tactical developments rather than a strategic plan

23
Why Enterprise Architecture?

24
Why Enterprise Architecture?

Two key reasons why you need an Enterprise Architecture:

 A means to achieve competitive advantage

 Enables managed innovation within the enterprise

25
Pressure to develop Enterprise Architecture

Laws and regulations

More extended enterprises

More co-operative IT operations

Greater publicity to failures

Increase in litigation

Audit requirements

26
Business Benefits of Enterprise Architecture

Achieve business strategy

Faster time to market
More consistent business processes and information
More reliability and security, less risk
More efficient business operation
More efficient IT operation
Better ROI
Reduced risk
Faster, simpler, and cheaper procurement

Source: “Why Enterprise Architecture Matters?”, The Open Group White Paper, W076

27
Digital Transformation Example
The Importance of Governance

Good decision making (governance)

 Good EA

Governance Framework has:

 Clear authority structure

 The right participants

29
What do we mean by Governance?

The way in which decisions are made

 Who is responsible?

 Who is involved?

 Who is accountable?

30
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

31
What is an Architecture Framework?

TOGAF Standard Definition: Architecture Framework

 A conceptual structure used to develop, implement, govern, and sustain
an architecture

The framework has:

 A method to design EA in terms of BBs
 A set of tools
 A common vocabulary
 A list of recommended standards
 A list of recommended products to implement the BBs

32
The Value of a Framework

Provides a practical starting point with a set of reusable resources

Avoids the initial panic for EA projects

Provides a systematic approach based on best practices

Contains a Baseline set of resources for reuse

33
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

34
TOGAF Origins

A customer initiative

A framework, not an architecture

 A generic framework for developing architectures to meet different

business needs

 Not a “one-size-fits-all” architecture

Originally based on TAFIM (U.S. DoD)

35
Member (End User) Driven

• Customer members demand architecture standards …

• Customer members select TAFIM as preferred starting point…
• DoD Information Systems Agency (DISA) donate TAFIM as base
• TOGAF 1st Edition
• TOGAF 7 Technical Edition
• TOGAF 8.1.1
‘93 ‘94 • TOGAF 9 Enterprise Edition
‘96
‘01
‘02 • TOGAF
‘03
‘06
‘09
9.1
‘11
• The Interoperable Enterprise ‘13
‘15 ‘17
Business Scenario ‘18
first published Certifications >25k TOGAF Standard,
Certifications > 50k Version 9.2
TOGAF 8 Enterprise Edition TOGAF Library
First TOGAF Certification Certifications >70k
Program Launched

36
TOGAF Long-term Goals

 An industry standard, generic Enterprise Architecture method….

 ….usable on its own or in conjunction with frameworks having products
relevant/specific to particular sectors.

• Several frameworks have mind share:

o Zachman, DODAF, MODAF, FEAF, TEAF, …

 Almost all focus on products, not method

 The TOGAF method and…. (not the TOGAF method or….)

38
Structure of the Standard
Architecture Content Architecture Capability
ADM Framework Framework

ADM Guidelines
Enterprise Continuum
& Techniques

39
The TOGAF Standard, Version 9.2
Table of Contents

Part I - Introduction
Preface, Executive Overview, Core Concepts, Definitions
Part II – Architecture Development Method
Introduction to ADM
ADM Phase Narratives
Part III – ADM Guidelines and Techniques
Guidelines for Adapting the ADM Process
Techniques for Architecture Development
Part IV – Architecture Content Framework
Content Metamodel
Architectural Artifacts
Architecture Deliverables
Building Blocks
Part V – Enterprise Continuum and Tools
Enterprise Continuum
Architecture Partitioning
Architecture Repository
Tools for Architecture Development
Part VI – Architecture Capability Framework
Architecture Board
Architecture Compliance
Architecture Contracts
Architecture Governance
Architecture Maturity Models
Architecture Skills Framework

40
TOGAF Components

 Architecture Development Method (ADM)

 ADM Guidelines and Techniques
 Architecture Content Framework
 The Enterprise Continuum
 The Architecture Capability Framework

 The TOGAF Library

41
 Modular Structure
Content Framework
Extended Guidance
TOGAF Capability Framework Architectural Styles
Additional ADM detail

Informs the Sets targets, KPIs,

capability Architecture Capability budgets for
Framework (Part VI) architecture roles
Ensures Realization
Drives need for Architecture
of Business Vision Capability maturity

Business needs feed Architecture Development Delivers new

into method Method (Part II) business solutions

ADM Guidelines &

Business Vision Refines Business
Techniques (Part III)
and Drivers Understanding Capabilities
TOGAF ADM &
Architecture Content Content Framework
Framework (Part IV)

Enterprise Continuum &

Tools (Part V)
Informs the Business Operational changes cause
TOGAF Reference Materials updates
of the current state
(TOGAF Library)
TOGAF Enterprise
Continuum & Tools
Architecture Development Method

A comprehensive Vendor, tool and

general method technology neutral
open standard
Complementary to, not
competing with, other Avoids re-inventing the
frameworks wheel

Widely adopted in the

market Business IT alignment

Tailorable to meet an
organization and Based in best practices
industry needs
Possible to participate in the
Available under a free evolution of the framework
perpetual license
43
ADM – Basic Principles

An iterative method, over the whole

process, between phases and within
phases

Each iteration has its own scope,

level of detail and time frame
ADM – Basic Principles

Every phase is validated against and

validates the current requirements of
the business
Preliminary Phase

This phase includes the preparation

and initiation activities to create an
Architecture Capability
 Understand business
environment
 High level management
commitment
 Agreement on scope
 Establish principles
 Establish governance structure
 Customization of the TOGAF
framework

46
Phase A: Architecture Vision

Initiates one iteration of the

architecture process
 Sets scope, constraints,
expectations

Creates the Architecture Vision

Validates business context

Creates the Statement of

Architecture work

47
Phase B: Business Architecture

The organization business

 Organization structure
 Business goals and objectives
 Business elements (e.g.
processes, people, functions,
services …)
 Their relationships,
 The governing principles

Shows how the organization meets

its business goals

48
Phase C: Information Systems Architectures

The Information Systems

Architecture including development
Data and Application:

 The IS elements (e.g. data and

applications)

 Their relationships,

 The governing principles

49
Data or Applications first?

May be developed in either order, or

in parallel

 Theory suggests Data first

 Practical considerations lead to

Application first

There will need to be some iteration

to ensure consistency

50
Phase D: Technology Architecture

The IT or infrastructure system

 The technology elements (e.g.

hardware, software and
communications)

 Their relationships,

 The governing principles

51
Phase E: Opportunities and Solutions

 Perform initial implementation

planning
 Identify the major
implementation projects
 Define Transition Architectures
 Decide on approach
o Make v Buy v Re-Use
o Outsource
o COTS
o Open Source
 Assess priorities
 Identify dependencies

52
Phase F: Migration Planning

For work packages and projects

identified in Phase E perform

 Cost/benefit analysis

 Risk assessment

Finalize a detailed Implementation

and Migration Plan

53
Phase G: Implementation Governance

Monitor and control the

implementation

Defines implementation constraints

Govern and manage an Architecture

contract

Produce a Business Value

Realization

54
Phase H: Architecture Change Management

Provide change management

process

Ensure flexibility and responsive to

changes in technology or business
environment

Monitors the business and capacity

management

55
What are the benefits of TOGAF?
Agenda

The Open Group

The Architecture Forum

Why Enterprise Architecture?

Why a Framework?

The TOGAF® Standard, Version 9.2

The TOGAF® Library

57
The TOGAF® Library

https://publications.opengroup.org/togaf-library
TOGAF Library – Overview

A portfolio of guidance material to support practical application of the

TOGAF standard

It contains guidelines, templates, patterns and other forms of reference

material

Over 80 documents (as of April 2018)

TOGAF Library – Structure

Section 1: Foundation Documents

Section 2: Generic Guidance and Techniques

Section 3: Industry-Specific Guidance and Techniques

Section 4: Organization-Specific Guidance and Techniques

Summary

The TOGAF® Standard is…

 An effective, industry standard framework and method for Enterprise
Architecture.
 Complementary to, not competing with, other enterprise frameworks

 A repository of best practice

o It “demystifies” architecture development

 Vendor, tool, and technology neutral

 A framework and method for achieving the “Boundaryless Information

Flow” vision

61
Workshop

Prepare initial high level description

of an Enterprise
 Name
 Business domain
 Main units in scope
 Vision (current and future states)

This description will be the base for

the coming workshops

You may work in groups or

individuals
Module 3
The TOGAF Framework
Components
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To highlight and introduce the main components and key concepts of the
TOGAF framework
 The Architecture Development Method (ADM)
 ADM Guidelines and Techniques
 Architecture Content Framework
• Deliverables, artifacts, building blocks
 The Enterprise Continuum
• The Architecture Repository
 The Architecture Capability Framework
• Establishing an EA Capability

 The TOGAF Library

64
Key Components of the TOGAF Framework
Architecture Content Architecture Capability
ADM Framework Framework

ADM Guidelines
Enterprise Continuum
& Techniques

65
The TOGAF Standard, Version 9.2
Table of Contents

Part I - Introduction
Preface, Executive Overview, Core Concepts, Definitions
Part II – Architecture Development Method
Introduction to ADM
ADM Phase Narratives
Part III – ADM Guidelines and Techniques
Guidelines for Adapting the ADM Process
Techniques for Architecture Development
Part IV – Architecture Content Framework
Content Metamodel
Architectural Artifacts
Architecture Deliverables
Building Blocks
Part V – Enterprise Continuum and Tools
Enterprise Continuum
Architecture Partitioning
Architecture Repository
Tools for Architecture Development
Part VI – Architecture Capability Framework
Architecture Board
Architecture Compliance
Architecture Contracts
Architecture Governance
Architecture Maturity Models
Architecture Skills Framework

66
The Architecture Development Method

Core of TOGAF

Addresses business requirements

Iterative

Set of views to address complex

requirements

Each phase includes objectives,

approach, inputs, steps and outputs

67
ADM Guidelines and Techniques

A set of guidelines and techniques to support the application of the ADM

The guidelines help to adapt the ADM to deal with different scenarios,
including different process styles (e.g. the use of iteration) and also specific
requirements (e.g. security).

The techniques support specific tasks within the ADM (e.g. defining
principles, business scenarios, gap analysis, migration planning, risk
management, etc).

68
Example Guideline – Applying Iteration to the ADM
Example Guideline –
Applying the ADM Across the Architecture Landscape
Example Technique – Categories of Stakeholder

71
Architecture Content Framework

Models architectural Deliverables,

Artifacts and the ABBs

Ensures consistency, completeness

and integration of ADM outputs

It provides an open standard for

architecture description

Has a detailed metamodel

Deliverables, Artifacts and Building Blocks

73
Full Content Metamodel with Relationships
The Enterprise Continuum

75
Architecture Repository
Capability Framework
Establishing the Architecture Capability as an
Operational Entity

The Architecture Capability Framework provides guidance on establishing

an operational enterprise architecture practice
It recommend they include capabilities such as:
 Financial Management
 Performance Management
 Service Management
 Risk Management
 Resource Management
 Communications and Stakeholder Management
 Quality Management
 Supplier Management
 Configuration Management
 Environment Management

78
The TOGAF Library

A reference library containing guidelines, templates, reference architectures,

patterns, etc., to accelerate the creation of new architectures for the
enterprise.
 https://publications.opengroup.org/togaf-library/

79
TOGAF Reference Models

This course includes coverage of two Reference Models provided in the

TOGAF Library

 The TOGAF Technical Reference Model (TRM)

• A Foundation Architecture

• A model and a taxonomy of generic platform services

 The Integrated Information Infrastructure Model (III-RM).

• A model for business applications and infrastructure applications

• Supports the Boundaryless Information Flow™ vision

80
High-Level TRM

81
Detailed TRM

82
Boundaryless Information Flow™

A trademark of The Open Group

Access to integrated information to support business

Combines multiple sources of information

Securely delivers the information

83
The Integrated Information Infrastructure Reference
Model (III-RM)

84
Test Yourself Question

Q: Which of the following is not considered one of the main parts of the
TOGAF standard?

A. Architecture Development Method

B. Enterprise Continuum

C. The TOGAF Library

D. TOGAF Resource Base

87
Module 4
Introduction to the
Architecture Development
Method (ADM)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to describe:

 The TOGAF ADM

 Its relationship to other parts of the TOGAF standard

 The phases of the ADM

 How and why to adapt the ADM

 How to scope an architecture activity

 The need for an integration framework

89
What is the TOGAF ADM?

 The core of TOGAF

 The result of contributions from many architecture practitioners

 A process for developing an EA

 Integrates all the elements within TOGAF

 Designed to address enterprise’s business and IT needs by providing:

• A set of views (business, data, application, technology)
• A set of recommended deliverables
• A method for managing requirements
• Guidelines on tools for EA development

90
Architecture Development Method – Process

The ADM is an iterative process:

 Over the whole process
 Between phases
 Within phases

For each iteration, re-consider:

 Scope
 Detail
 Schedules, milestones
Architecture Development Method – Process

Consider assets from:

 Previous iterations

 Marketplace, according to
availability, competence, and
value:
• Other frameworks
• Systems models
• Vertical Industry models
Relationship to other Parts of the TOGAF Standard

Architecture Capability Framework (Part

VI)

Architecture Development Method (Part II)

ADM Guidelines &

Techniques (Part III)

Architecture Content
Framework (Part IV)

Enterprise Continuum & Tools (Part V)

TOGAF Reference Materials

(TOGAF Library)

93
ADM Phases
Prepare the organization Scope, Constraints, and expectations
Architecture Vision
Provide change management mechanism Statement of Architecture Work
Ensure flexibility of the EA

Baseline Business Architecture

Target Business Architecture
Govern the implementation
Gap Analysis
Ensure the implementation
conforms to the architecture
Baseline IS Architecture
Target IS Architecture
Cost / Benefit analysis
Gap Analysis
Risk Assessment
Detailed Implementation Plan
Baseline Technology Architecture
Target Technology Architecture
Gap Analysis

Ensure that every stage of a TOGAF

project is based on and validates
business requirements Initial implementation plan
Identify major implementation projects 94
ADM Phase Steps Example

95
ADM Inputs and Outputs

The TOGAF standard defines a number of input and output deliverables for
each ADM phase

 These are suggestions and need not be followed exactly

 Output of an early phase may be modified in a later phase

 Version numbers are used to manage the output

 A convention is used to illustrate the evolution of deliverables

• 0.1 – a high level outline deliverable
• 1.0 – a formally reviewed detailed deliverable

96
Adapting the ADM

Generic methodology intended for variable:

 Geographies

 Vertical sectors

 Industry types

Usable with deliverables of other frameworks such as Zachman, DODAF, …

It is usual to modify or extend the ADM to suit specific needs

97
Governing the ADM

The ADM itself must be managed and governed

The Architecture Board is responsible for ADM governance

Governance needs a controlled environment

98
Governance Repository

Reference Data

Process Status

Audit Information

99
Reasons to constrain the Scope of Architectural
Activity

EA team authority

Stakeholder objectives and concerns

The availability of people, finance, and other resources

100
Scoping the Architecture Activity

There are four dimensions in which scope may be limited:

 Breadth

 Depth

 Time Period

 Architecture Domains

101
Architecture Integration

102
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 the TOGAF framework for assets and
processes

It can be used with other deliverables from other frameworks

103
Test Yourself Question

Q. The following statements describe the phases of the ADM, except ?

A. They are cyclical.

B. They are iterative.

C. Each phase refines the scope.

D. Each phase is mandatory.

E. The phases cycle through a range of architecture views.

104
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Part II: Architecture Development Method (ADM)

https://pubs.opengroup.org/architecture/togaf92-doc/arch/pt2.html
Module 5
Architecture Content
Framework
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives are to:

 Explain the purpose of the Architecture Content Framework

 Describe the main components of the Content Metamodel

 Describe the relationship between the Architecture Content Framework

and the TOGAF ADM

107
Introduction

Provides a detailed model of architectural work products

Improve the consistency of the TOGAF outputs

108
Benefits of the Architecture Content Framework

Ensures consistency, completeness and integration of ADM outputs

Provides an open standard for architecture description

109
Overview

The Framework has 3 categories for describing work products:

 Deliverables

 Artifacts

 Building blocks

110
Deliverables, Artifacts and Building Blocks

Deliverables Artifacts
 Formal products  Fine grained products that
 Contractually specified describe an architecture from a
 Outputs from a project specific viewpoint
 A deliverable can contain many  For example: use-case
artifacts specifications, architectural
requirements, network diagrams,
etc.
Building blocks  Classified as:
 Components that can be • Catalogs (lists of things),
combined with other building • matrices (showing relationships
blocks to deliver architectures between things) or
and solutions • diagrams (pictures of things).
 Artifacts make up the content of
the Architecture Repository

111
Relationship between Deliverables, Artifacts and
Building blocks

112
Example – Architecture Definition Document

113
Architectural Artifacts

Artifacts are products that are created when developing an architecture.

An artifact is distinct from a deliverable, which is a contracted output from a

project.

Usually deliverables contain many artifacts and each artifact may exist in
many deliverables.

114
Content Metamodel

The framework is based on a standard content metamodel that defines all

the types of BBs showing their descriptions and relationships

The content model consists of a core and extensions.

Catalogs, matrices and diagrams are used to present the architectural

information

115
Content Metamodel Overview

116
Mapping the Framework and the ADM

117
Content Framework and the TOGAF ADM

ADM inputs and outputs are stored in the structure provided by the
Architecture Content Framework

The content framework is a companion to the ADM

The ADM describes what needs to be done and the content framework
describes what it should look like

118
Summary

The Architecture Content Framework presents outputs in a consistent and

structured way.

 It has 3 categories of work products: deliverables, artifacts and building

blocks.

The content metamodel consists of a core and some extensions.

Catalogs, matrices and diagrams are used to present the architectural
information.

There is a mapping from the Architecture content framework to the TOGAF

ADM phases

119
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Part IV: Architecture Content Framework

https://pubs.opengroup.org/architecture/togaf92-doc/arch/pt4.html
Workshop

Which of the following is a catalog,

matrix or diagram?
Module 6
TOGAF Content
Metamodel
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to describe:

 What a metamodel is and why it is needed

 Key concepts of the Core Metamodel

 The division of the metamodel into Core and Extensions

 Key concepts of the Core Metamodel Entities

 The components of the TOGAF Content Metamodel

123
What is a metamodel?

A metamodel is a precise definition of the constructs and rules needed for

creating models

 Source: www.metamodel.com

A model that describes how and with what the architecture will be described
in a structured way.

 Source: TOGAF Standard, Version 9.2, Chapter 3 Definitions

124
Why a metamodel?

125
Benefits of the Metamodel

Formalizes the definition of an Enterprise Architecture

Formalizes the relationship between objects

Enables EA tool mapping

126
Formal and Informal Modeling

Formal modeling is usually used with technical people

Informal modeling is usually used with executives and non-technical people

because it is:

 More appropriate

 Easy to communicate

127
Core Content Metamodel Concepts

A TOGAF architecture is based on

 Catalogs defining building blocks

 Matrices specifying the relationships between building blocks

 Diagrams presenting building blocks

The metamodel is structured into Core and Extension content

128
Core and Extension Content

In order to support many scenarios the metamodel has been partitioned into
core and extension content

The core provides a minimum set of content

 Should be always used
 Should not be altered

The extension content allows for more specific or more in-depth modeling
 Extensions are optional and should be selected during the Preliminarily
Phase according to the areas of interest needing more focus
 Extensions may be tailored

129
TOGAF Content Metamodel and its Extensions

130
Core Metamodel Entities

 Actor: A person, organization, or system that is outside the

consideration of the architecture model, but interacts with it.
 Application Component: An encapsulation of application functionality
that is aligned to implementation structuring.
 Business Capability: A particular ability that a business may possess
or exchange to achieve a specific purpose
 Business Service: Supports business capabilities through an explicitly
defined interface and is explicitly governed by an organization.
 Course of Action: Direction and focus provided by strategic goals and
objectives, often to deliver the value proposition characterized in the
business model

131
Core Metamodel Entities (Cont’d)

 Data Entity: An encapsulation of data that is recognized by a business

domain expert as a discrete concept. Data entities can be tied to
applications, repositories, and services and may be structured according
to implementation considerations.
 Function: Delivers business capabilities closely aligned to an
organization, but not explicitly governed by the organization.
 Information System Service: The automated elements of a business
service. An information system service may deliver or support all of one
or more business services.
 Organization Unit: A self-contained unit of resources with line
management responsibility, goals, objectives, and measures.
Organization units may include external parties and business partner
organizations.
 Role: An actor assumes a role to perform a task.

132
Core Metamodel Entities (Cont’d)

 Technology Component: An encapsulation of technology infrastructure

that represents a class of technology product or specific technology
product.
 Technology Service: A technical capability required to provide enabling
infrastructure that supports the delivery of applications.
 Value Stream: a representation of an end-to-end collection of value-
adding activities that create an overall result for a customer, stakeholder,
or end-user

133
Core Entities and their Relationships

134
Stakeholder Needs

Executive CxO

Programme
Management Office

Line
Management

Executive

Application
HR Line Management
Management

Infrastructure Procurement
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications

Stakeholder Types

QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project

135
The Content Metamodel

The framework is based on a standard content metamodel that defines all

the types of BBs showing their descriptions and relationships

 The metamodel considers stakeholder concerns

 The metamodel provides guidance to tool implementers

136
Content Metamodel (Simplified)

137
Content Metamodel (Detailed)

138
Core Content Metamodel

139
TOGAF Standard, Version 9.2 Core Artifacts

140
Full Content Metamodel
Full Content Metamodel with Relationships

Slide 142
Full Content Metamodel Artifacts
Metamodel Extensions

144
Governance Extension

145
Governance Extension

Use:

 Transform in governance due to

IT change, restructuring …

 Service requirements differ from

service to service

146
Governance Extension

Scope:
 Measures objectives and
services
 Apply contracts to service
communication or interactions
with users and systems
 Define re-usable service
qualities used in contracts

Additional diagrams to be
created:
 Enterprise Manageability
diagram
147
Services Extension

148
Services Extension

Use:

Avoid miscommunication between IT

and business

149
Services Extension

Scope:

 Creation of IS services as an
extension of business service

Additional diagrams to be
created:

 Business Use-Case Diagram

 Organization Decomposition
Diagram

150
Process Modeling Extension

151
Process Modeling Extension

Use:

 Process critical enterprise

 Meet specific requirements (e.g.

regulatory compliance) to store
control steps

 Pay specific attention to state

and events

152
Process Modeling Extension

Scope:
 Creation of events as triggers for
processes
 Creation of controls of logic and
governance for the process
 Creation of products (outputs) of a
process
 Creation of event diagrams to track
triggers and state changes across
the organization

Additional diagrams to be created:

 Process Flow diagrams
 Event diagrams

153
Data Extension

154
Data Extension

Use:

Significant complexity and risk

around the location, encapsulation,
and management of or access to
data

155
Data Extension

Scope:
 Creation of logical data
components
 Creation of physical data (e.g.
databases, registries, repositories,
schemas …)
 Creation of data lifecycle, data
security, and data migration
diagrams to show data concerns in
more detail

Additional diagrams to be created: :

 Data Security diagram
 Data Migration diagram
 Data Lifecycle diagram

156
Infrastructure Consolidation Extension

157
Infrastructure Consolidation Extension

Use:
 Many technology products are in
place with duplicate or
overlapping capability
 Many applications are in place
with duplicate or overlapping
functionality
 Geographically dispersed
applications without well
understood decision
 Applications will be consolidated
and/or migrated

158
Infrastructure Consolidation Extension

Scope: Additional diagrams to be

 Separating abstract applications created:
from actual applications  Process/System Realization
 Separating abstract technology diagram
components from actual  Software Engineering diagram
technology components  Application Migration diagram
 Creation of additional diagrams  Software Distribution diagram
focusing on the location of  Processing diagram
assets, compliance with
standards, structure of  Networked Computing/Hardware
applications, application diagram
migration, and infrastructure  Network and Communications
configuration diagram

159
Motivation Extension

160
Motivation Extension

Use:

 Motivation is not understood

 Drivers and objectives are

conflicting

 Service levels are unknown or

unclear

161
Motivation Extension

Scope:
 Creation of Drivers
 Creation of Goals
 Creation of Objectives
 Traceability from drivers, goals,
and objectives through to
services

Additional diagrams to be
created:
Goal/Objective/Service diagram

162
Summary

The TOGAF standard provides a rich metamodel

This provides a number of benefits:

 It supports both formal and informal modeling

 It formalizes the definition of an Enterprise Architecture

 It formalizes the relationship between objects

 It enables an EA tool mapping

163
Exercise

Determine which of the Metamodel extensions is most appropriate for the

following situations:

 Where organizations have conflicting objectives

 Where service levels are unknown

 Where many applications are in use with overlapping functionality

 Where management of information is complex

 Where business process has to support regulatory compliance

164
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 30. Content Metamodel

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap30.html
Practical Example – Archi Tool
Module 7
The Enterprise Continuum
and Tools
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To provide an introduction to the Enterprise Continuum.

 The purpose of the Enterprise Continuum

 The constituent pieces of the Enterprise Continuum

 To explain high-level issues with Tool Standardization

168
Definition of ‘Continuum’

Noun: a continuous extent of something, no part of which is

different from any other

Source: Wiktionary.org

169
The TOGAF Standard, Version 9.2 Components
Architecture Content Architecture Capability
ADM Framework Framework

ADM Guidelines
Enterprise Continuum
& Techniques

170
Overview

A model for structuring a virtual repository and methods for classifying

architecture and solution artifacts

The practical implementation of the Enterprise Continuum takes the form of

an Architecture Repository

Continued…

171
Overview (Cont’d)

Combination of Architecture Continuum and Solutions Continuum

Enables effective use of COTS

Improves engineering efficiency

Organizes reusable assets

It provides a common language:

 Within enterprises
 Between customer enterprises and vendors

172
Architecture Reuse

The Enterprise Continuum consists of all architecture assets: models,

patterns, architecture descriptions, etc.

External assets include:

 Generic reference models (eg TOGAF’s TRM, Zachmann…)
 IT-specific models (eg a web services architecture)
 Information Processing-specific models (eg e-Commerce, supply chain
management …)
 Vertical-Industry-specific models (eg TMF, ARTS, POSC…)

The architecture governance function decides which assets an enterprise

considers part of its own Enterprise Continuum

173
Enterprise Continuum: Constituents

174
The Architecture Continuum

Figure 1

Reuse

Logical Details
Horizontal Physical
General Vertical

Taxonomy Special
Specifications

175
The Solutions Continuum

Generic
COTS Specific
Custom Dev.

176
The Solutions Continuum:

Represents the implementations of the architectures at the corresponding

levels of the Architecture Continuum

Is a population of the architecture with SBBs, either purchased products or

built components

Forms a Solutions Inventory or Reuse Library

177
Relationships

The Architecture and Solutions Continuum are related by guidance,

direction, and support.

The Open Group Technical Reference model (TRM) is a Foundation

Architecture

The Open Group III-RM is a Common Systems Architecture

178
The Enterprise Continuum

179
Using the Continuum

Contains complete and work-in-progress solutions

Is a "framework-within-a-framework”

Has few internal assets, at first

Grows by adding reusable building blocks

180
Relationships

The Enterprise Continuum improves productivity through leverage

The Enterprise Continuum does not represent strictly chained relationships:

 enterprise architectures may have components from a Common

Systems Architecture

 enterprise solutions may contain a product or service

181
The need for Tools

Tools are needed to manage and control the artifacts within the Enterprise
Continuum

 To promote re-use

 To enable sharing of architecture information

 To facilitate easier maintenance of the architecture

 To ensure common terminology is used

 To provide stakeholders with relevant models

182
Tools can model the Enterprise Architecture

183
Issues in Tools Standardization

A single “one size fits all” tool versus multiple tools

Can a single tool address all needs, all maturity levels?

The Open Group is developing a TOGAF 9 Tools Certification program

184
Summary

The Enterprise Continuum is

 a model for structuring a virtual repository and methods for classifying

architecture and solution artifacts

 It enables the organization of reusable architecture and solution assets.

 It is also an aid to communication between all architects involved in

building and procuring an architecture by providing a common language
and terminology.

 This in turn enables efficiency in engineering and effective use of COTS

products.
Continued…

185
Summary

The Enterprise Continuum

provides an overall context for architectures and solutions and classifies
assets that apply across the entire scope of the enterprise.

The Architecture Continuum

provides a classification mechanism for assets that collectively define the
architecture at different levels of evolution from generic to specific.

The Solutions Continuum

provides the classification for assets to describe specific solutions for the
organization that can be implemented to achieve the intent of the
architecture. Continued…

186
Summary

Tools are needed to manage artifacts within the Enterprise Continuum

The TOGAF standard provides an introduction to Issues in Tools

Standardization

187
Test Yourself Question

Q. According to TOGAF, all the following statements apply to the Enterprise

Continuum, except ____________:

A. It is a virtual repository of all known architecture assets and artifacts in

the IT industry
B. It is a virtual repository of all architecture assets and artifacts which the
enterprise is considering in its own architecture project
C. It provides a taxonomy for classifying architecture assets
D. Its is an important aid to communication for architects on both the buy
and supply side
E. It helps to organize reusable and solution assets

188
Test Yourself Question

Q. According to TOGAF, all of the following are examples of ‘assets within

the IT Industry at large ’ from the Architecture Continuum, except
_________

A. A The TOGAF TRM

B. The Zachman Framework
C. IT-specific models, such as web services
D. The ARTS data model
E. Deliverables from previous architecture work

189
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Part V: Enterprise Continuum and Tools

https://pubs.opengroup.org/architecture/togaf92-doc/arch/pt5.html

Chapter 35. Enterprise Continuum

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap35.html
Module 8
Architecture Repository
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to describe:

 The purpose of the Architecture Repository

 Its constituent parts

 Its relationship to other parts of the TOGAF standard

192
Purpose

A formal taxonomy for different types of architectural assets

This is one part of a wider Enterprise Repository

193
Architecture Repository

194
 Architecture Repository

Describes the
architecture
framework in use Contains re-usable architecture
within the work products
Enterprise
Shows the state of
the operating
enterprise at
particular points in Defines the compliance criteria
time for work governed by architecture

An architectural
representation of Captures results of the
the SBBs supporting governance activity
the Architecture
Landscape
A view of all
authorized Describes the organisation, roles,
architecture skills and responsibilities of the
requirements EA practice 195
Architecture Landscape

Strategic Architectures:
 Long-term summary view of the entire enterprise.
 High level description oriented for executive level

Segment Architectures:
 Focus on areas within the enterprise (e.g. sectors or departments) in
more details
 Related to portfolio or program

Capability Architectures:
 Focus on specific capability in more details
 Related to work packages or projects

196
Reference Library

Holds models (e.g. TOGAF, CMMI, ITIL …), best practice, viewpoint library,
templates …

The architecture may not conform to its contents

Compliance with the standards is not assessed during governance

Sources come from:

 Standards bodies (if not used as standards)
 Product and service vendors
 Industry communities or forums
 Corporately defined templates (may come from CMMI, ISO, ITIL …)
 Best practice resulting from this project or other projects

197
Standards Information Base

Holds a set of specifications, to which architectures must conform.

Compliance with the standards is assessed during governance

Standards should be:

 Easily accessible

 Clear and unambiguous manner

198
Standards Information Base

Types of Standard
 Legal and Regulatory
 Industry
 Organizational

Standards Lifecycle
 Trial
 Active
 Deprecated
 Obsolete

199
Standards Classification

Business Standards: Applications Standards:

Shared business functions Application sharing
Role and actor definitions (e.g. NCF) Application communication and
Security and governance interoperation
Access, presentation, and style
Data Standards:
Coding and values for data Technology Standards;
Structures and formats for data Hardware products
Origin and ownership of data (e.g. Software products
IT4IT) Software development
Replication and access

200
Governance Log

Decision Log:
 Product selections
 Justification for major Compliance Assessments:
architectural features of projects
 Project overview
 Standards deviations
 Progress overview (timeline,
 Standards lifecycle changes status, issues, risks,
 Change Request evaluations dependencies, etc.)
and approvals  Completed architecture
 Re-use assessments checklists
 Standards compliance
assessment
 Recommended actions

201
Governance Log

Capability Assessments:
 Templates and reference models
for Capability Assessments
 Business Capability
Assessments Calendar (Schedule)
 IT capability, maturity, and
impact assessments Project Portfolio
 Architecture maturity  Name and Description
assessments  Scope
 Roles and responsibilities

Performance Measurement

202
Architecture Requirements Repository

Holds the architecture requirements on different levels

Used by all phases of the ADM

Managed by the Architecture Requirements phase of the ADM

203
Relationship to other Parts of the TOGAF Standard

The TOGAF ADM has reminders when to use assets from the Architecture
Repository

The Architecture Repository is a model for a physical instance of the

Enterprise Continuum

204
Summary

 The TOGAF standard provides a structural framework for a repository

 It is a logical information store for ADM outputs with the following repository
areas defined:
• Architecture Metamodel: describes the architecture framework in use within the
Enterprise
• Architecture Landscape: shows the state of the operating Enterprise at particular points
in time
• Reference Library: contains re-usable architecture work products
• Standards Information Base: defines the compliance criteria for work governed by
architecture
• Governance Log: captures results of governance activity
• Architecture Capability: describes the organisation, roles, skills and responsibilities of
the Enterprise Architecture practice
• Architecture Requirements Repository: provides a view of all authorized architecture
requirements which have been agreed with the Architecture Board
• Solutions Landscape: presents an architectural representation of the SBBs supporting
the Architecture Landscape which have been planned or deployed by the enterprise

205
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 37. Architecture Repository

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap37.html
Workshop

What is the best location for these

documents in the architecture
repository?
 Architecture board reports
 Applicable laws and regulations
 TOGAF
 Architecture definition
 List of applications to be
purchased
 Reference architecture models
 Architecture requirements
document
Module 9
Preliminary Phase
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Preliminary Phase:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

209
Preliminary Phase Objectives

Determine the desired Architecture Capability:

 Review the organizational context
 Identify and scope the elements of the enterprise organizations
 Identify the established frameworks, methods, and processes that
intersect with the Architecture Capability
 Establish a Capability Maturity target

Establish the Architecture Capability:

 Establish the Organizational Model for Enterprise Architecture
 Establish governance process and resources
 Select and implement EA tools
Continued…
 Define the Architecture Principles

210
Approach

 Define the Enterprise

• Scope the enterprise (which parts are affected by the EA)
• Understand the context (business model, main stakeholders and concerns, current
processes, current skills …)
 Identify key drivers
 Define the requirements (e.g. automation, DX …)
 Define the Architecture Principles
 Define the framework to be used
• Portfolio/program/project management
• Solution development
• Operations management
 Define the relationships between management frameworks
 Evaluate the EA maturity

211
Preliminary Phase: Main inputs

 The TOGAF Library

 Other architecture frameworks
 Business strategies and board
business plans, IT strategy
 Business principles, business
goals, and business drivers
 Major frameworks operating in the
business
 Governance and legal frameworks
 Any existing:
• Organizational model
• Architecture framework
• Architecture Principles
• Architecture Repository
Steps

6. Develop Strategy and Implementation Plans for

Tools and Techniques
5. Tailor TOGAF, and other Architecture Frameworks,
if any
4. Identify Architecture Principles

3. Define & Establish the Enterprise Architecture Team

2. Confirm Governance and Support Frameworks

1. Scope the Enterprise Organizations Impacted

1. Scope the enterprise organizations impacted

Identify core enterprise

Identify soft enterprise

Identify extended enterprise

Identify communities

Identify governance involved

214
2. Confirm governance and support frameworks

The major output of this phase is a framework for architecture governance.

Existing governance and support models will be assessed and probably

changed

Sponsors and stakeholders are consulted and they approve the governance
framework

215
3. Define the team and organization

 Determine existing enterprise and business capability

 Conduct an architecture/business change maturity assessment
 Identify gaps in existing work areas
 Allocate key roles and responsibilities for management and governance
 Write requests for change for existing projects
 Scope new EA work
 Determine constraints on EA work
 Review and agree with sponsors and board
 Assess budget requirements

216
4. Identify and establish Architecture Principles

Principles are rules and guidelines that say how an organization fulfils its
mission

Enterprise principles enable decision-making

Architecture principles include:

 Architecture process principles
 Architecture implementation principles

217
5. Tailor the TOGAF framework and, if any, other
Selected Architecture Frameworks

Terminology Tailoring: Enterprise Glossary may be established to unify

terminologies

Process Tailoring: Tailoring the ADM (e.g. re-order phases, merge phases,
cancel phases …) considering EA team experience existing processes

Content Tailoring: Tailoring Architecture Content Framework, Content

Metamodel (e.g. select extensions, reject relations …) and Enterprise
Continuum considering other frameworks

218
Content Tailoring

219
6. Develop Strategy and Implementation Plans for
Tools and Techniques

Tools range from simple modeling tools to sophisticate EA tools

Consider EA team experience, license, budget …

221
Preliminary Phase: Outputs

 Organizational model for

Enterprise Architecture
 Tailored Architecture
Framework, including
Architecture Principles
 Initial Architecture Repository
 Restatement of business
principles, goals and drivers
 Request for Architecture Work
 Architecture Governance
Framework
Summary

The main objective of the preliminary

phase is to prepare an organization
for a successful Enterprise
Architecture project by defining “how
we do architecture”

Continued…
 Summary
Preliminary Phase

Objectives Steps Inputs Outputs

Determine the Architecture Capability desired by the Scope the enterprise organizations The TOGAF Library Organizational Model for Enterprise
organization: impacted Other architecture framework(s) Architecture
 Review the organizational context for conducting Board strategies, business plans, business Tailored Architecture Framework, including
Enterprise Architecture Confirm governance and support strategy, IT Strategy, business Architecture Principles
 Identify and scope the elements of the enterprise frameworks principles, business goals, and Initial Architecture Repository
organizations affected by the Architecture Capability business drivers Restatement of, or reference to, business
 Identify the established frameworks, methods, and Define and establish the Enterprise Major frameworks operating in the principles, business goals, and
processes that intersect with the Architecture Architecture team and organization business business drivers
Capability Governance and legal frameworks Request for Architecture Work
 Establish Capability Maturity target Identify and establish Architecture Architecture capability Architecture Governance Framework
Principles Partnership and contract agreements
Establish the Architecture Capability: Existing organizational model for Enterprise
 Define and establish the Organizational Model for Tailor the TOGAF framework and, if any, Architecture
Enterprise Architecture other selected Architecture Existing architecture framework, if any,
 Define and establish the detailed process and Frameworks including:
resources for architecture governance  Architecture method
 Select and implement tools that support the Develop strategy and implementation plans  Architecture content
Architecture Capability for tools and techniques  Configured and deployed tools
 Define the Architecture Principles  Architecture Principles
 Architecture Repository

224
TOGAF Standard, Version 9.2 Artifacts

225
Test Yourself Question

Q. Which one of the following is completed during the Preliminary Phase of

the TOGAF ADM?

A. Architecture Principles
B. Gap Analysis
C. Impact Analysis
D. Statement of Architecture Work
E. Requirements Gathering

226
Test Yourself Question

Q. Which one of the following is a reason to adapt the ADM?

A. The use of TOGAF is being integrated with another framework.

B. The ADM is being used for a purpose other than Enterprise Architecture.
C. The enterprise is a large federated organization.
D. The IT Governance model needs to be tailored.
E. All the above.

227
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 5. Preliminary Phase

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap05.html
Workshop

Review the initial enterprise

description you identified before and
update it as necessary
Module 10
Architecture Principles
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to:

 Understand the architecture principles

 Understand how to write them

 Learn how to establish good set of principles

231
Architecture Principles

An initial output of the Preliminary Phase

A set of general rules and guidelines for the architecture being developed

The TOGAF standard contains guidelines for developing principles and a

detailed set of generic principles

Principles are generally established in two key domains:

 Enterprise principles provide a basis for decision-making throughout an
enterprise and dictate how the organization fulfills its mission
 Architecture principles are a set of principles that relate to architecture
work.

232
An Example Statement of Principles

Business Principles: Architecture Principles:

 Primacy of Principles  De-Skill
 Maximize Benefit to the Enterprise  One Source
 Compliance with the Law  Content Management
 Availability at Anytime from
Anywhere
 Business Continuity
 Citizenship
 Custodianship
 De-Customization
 Painless User Experience
 Self-Serve
 Sharing of Information
The need for Architecture Principles

They inform and support the way in which an organization sets about
fulfilling its mission

Often they are one element in a structured set of ideas that collectively
define and guide the organization, from values through to actions and
results

234
Defining Architecture Principles

Why
Provide a framework for decision making

Who
Developed by the Enterprise Architects
In conjunction with key stakeholders
 The Enterprise CIO
 Architecture Board
 Other key business stakeholders

235
Principles and the Metamodel

Information related to Principles can

be modeled, if the right information
is captured

The metamodel relates Principles

back to specific drivers, goals and
objectives

236
TOGAF Template for Principles

Name
 Represents the essence of the rule
 Easy to remember
 Should not mention specific technology platforms
 Should avoid ambiguous words (e.g. support, open, consider, avoid …)

Statement
 Must be clear
 Must be unambiguous

Continued…

237
TOGAF Template for Principles

Rationale
 Highlights the business benefits of adhering to the principle
 Describes the relationship to other principles (e.g. precedence, weight
…)

Implications
 Business and IT requirements for the principle
 The impact and consequences of the principle on the business

238
Example: Primacy of Principles

Statement Principles apply throughout the enterprise and override all

other considerations when decisions are made

Rationale The only way we can provide a recognized, consistent

and measurable level of operations is if all parts of the
enterprise abide by the principles when making decisions

Implications Without this principle, short-term consideration,

supposedly convenient exceptions, and inconsistencies
would rapidly undermine the management of information.
Information management initiatives will not be permitted to
begin until they are examined for compliance with the
principles.
A conflict with a principle will be resolved by changing the
conflicting initiative, which could delay or prevent the
initiative.

239
Example: Self-Serve

Statement Customers should be able to serve themselves

Rationale Applying this principle will improve customer satisfaction,

reduce administrative overhead, and potentially improve
revenue.

Implications There is an implication to improve ease-of-use and

minimize training needs; for example, members should be
able to update their contact details, etc. and be able to
buy additional membership products online.

240
Five Qualities of Principles

1.Understandable: they can be quickly grasped. Intent is clear and

unambiguous

2.Robust: precise to enable decisions and enable policies and standards to

be created

3.Complete: cover every situation perceived

4.Consistent: not contradicting

5.Stable: principles should not change frequently, although they can change
Recommended Number of Principles

Principles should be few in number

Recommended number of principles is 10 to 20

Summary

Principles are used for decision making

For each principle identify name, statement, rationale and implications

Principles should be understandable, robust, complete, consistent and

stable

Recommended number of principles range between 10 and 20

243
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 20. Architecture Principles

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap20.html
Practical Example – Architecture Principles
Workshop

identify the business, data,

application, and technology
principles for your enterprise
Module 11
Architecture Governance
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

This module will help you to understand:

 Architecture Governance
 The main components that make up an Architecture Governance
Framework
 The TOGAF Architecture Governance Framework
 Architecture Governance in Practice
 Why Architecture Governance is beneficial
 Guidelines for establishing an EA Capability

248
Introduction to Governance

Governance includes:

controlling the activities

ensuring compliance with standards and regulatory obligations

supporting management

ensuring accountability to stakeholders

249
Governance and the ADM

Governance should be established in the Preliminary Phase

 Usually an adaptation of existing governance and support models

The Architecture Board governs the ADM

Governance plays a key role in Phases G and H

250
Nature of Governance

Governance ensures business is conducted properly

It is less about overt control and strict adherence to rules

It is about effective and equitable usage of resources to ensure sustainability

of strategic objectives

251
Levels of Governance

The hierarchy of governance domains includes:

 Corporate Governance (outside of TOGAF scope)
 Technology Governance
 IT Governance
 Architecture Governance

Each domain may exist at multiple geographic levels:

 Global
 Regional
 Local

252
An IT Governance Framework - COBIT

253
TOGAF Architecture Governance Framework

Phase G of the TOGAF ADM is about Implementation Governance - the

realization of architecture through change projects

 Implementation governance is just one aspect of Architecture

Governance

The Architecture Governance Framework is generic and can be adapted to

an existing governance environment

254
Conceptual Structure

255
Organizational Structure

256
Architecture Board

The Board oversees implementation of the governance strategy

Board comprises of representative stakeholders at 2 levels:

 Local (domain experts, line responsibility)

 Global (organization-wide responsibility)

 Board has identifiable and articulated:

• Responsibilities and decision-making capabilities
• Remit and authority limits

257
Architecture Contracts

Joint agreements between development partners and sponsors on the

deliverables, qualify and fitness-for-purpose of an architecture

258
Architecture Contracts and the ADM

The Statement of Architecture Work created in Phase A

Architectures Domains (Business, Data, Application, Technology)

Phase G

Implementation projects

259
Architecture Compliance: Terminology

260
Architecture Compliance

Two processes are defined to ensure compliance of projects with the

Enterprise Architecture:

 Prepare Project Impact Assessments - project-specific views that

illustrate how the Enterprise Architecture impact a project

 Perform an Architecture Compliance Review

261
Architecture Compliance Review Process

262
Establishing an Architecture Capability

TOGAF provides guidelines to establish an EA capability

 Use of the ADM
 Treat is as an ongoing practice
 Address the four domain architectures
• Business Architecture: the architecture governance, architecture processes,
architecture organizational structure, architecture information requirements,
architecture products, etc.
• Data Architecture: the structure of the organization's Enterprise Continuum and
Architecture Repository
• Application Architecture: the functionality and/or applications services required to
enable the architecture practice
• Technology Architecture: infrastructure requirements and deployment in support of
the architecture applications and Enterprise Continuum

263
Summary

 Architecture governance is the practice and orientation by which

Enterprise Architectures and other architectures are managed and
controlled at an enterprise-wide level. It includes:
 Implementing a system of controls over the creation and monitoring of
all architecture components and activities, to ensure the effective
introduction, implementation, and evolution of architectures within the
organization.
 Implementing a system to ensure compliance with internal and external
standards and regulatory obligations.
 Establishing processes that support effective management of these
processes.
 Developing practices that ensure accountability to identified
stakeholders, inside and outside the organization.

264
Test Yourself Question

Which of the following are NOT included in Architecture Governance?

A. Implementing a system of controls over expenditure within the enterprise

B. Implementing a system of controls over the creation and monitoring of all
architecture components and activities
C. Implementing a system to ensure compliance with internal and external
standards and regulatory obligations
D. Establishing processes that support effective management of the
architecture governance process
E. Developing practices that ensure accountability to stakeholders

265
Test Yourself Question

Q. Which of the following is an example of an IT governance framework?

A. ITIL
B. Prince 2
C. COBIT
D. TOGAF
E. ATAM

266
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 44. Architecture Governance

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap44.html
Workshop

Establish the governance board to

govern the EA development of your
EA project
Module 12
Phase A:
Architecture Vision V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase A:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

270
Phase A Objectives

Develop a high-level aspirational vision of the capabilities and business

value to be delivered

Obtain approval for a Statement of Architecture Work

271
Approach

The architecture vision is an important selling tool

 Clarifying the purpose of the architecture
 Showing how it will be achieved
 High level view of the baseline and target architectures
 What is in and what is out the architecture effort

Emerging technologies help to catch opportunities

If business goals, drivers, constraints and principles are defined understand

them, otherwise establish them

272
Phase A: Inputs

Request for Architecture Work (see

next slide)

Business principles, business goals

and drivers

Organization Model for Enterprise

Architecture

Tailored Architecture Framework,

including Architecture Principles

Populated Architecture Repository

Request for Architecture Work

 Organization Sponsors  External constraints, business

 Organization’s mission constraints
statement  Current business system
 Business goals and changes description
 Strategic plans of the business  Current architecture/IT system
 Time limits description
 Changes in the business  Description of developing
environment organization
 Organizational constraints  Description of resources
developing organization has
 Budget information, financial available
constraints

274
Steps
11. Develop Statement of Architecture
Work; secure approval
10. Identify the business transformation risks
and mitigation activities
9. Define the Target Architecture value propositions
and KPIs
8. Develop Architecture Vision
7. Confirm and elaborate architecture principles, including
business principles
6. Define Scope

5. Assess readiness for business transformation

4. Evaluate capabilities

3. Confirm business goals, drivers, and constraints

2. Identify stakeholders, concerns, and business requirements

1. Establish the architecture project

Step 1: Establish the architecture project

The EA work is managed like a project

It must be recognized as a project in the organization

Better to follow existing project management approach in the organization

 External frameworks may also be used or merged with internal
frameworks

Obtain necessary support and commitment to the project

276
Step 2: Identify stakeholders, concerns, and business
requirements

Here we must identify:

 Candidate vision components and requirements
 Candidate scope boundaries for the engagement
 Stakeholder concerns, issues, and cultural factors
 The concerns and viewpoints that are relevant to this project
 The stakeholders that are involved with the project
 The key roles and responsibilities within the project

 Views and viewpoints need to be developed to satisfy stakeholder

requirements

This is reflected in the Stakeholder Map

277
Stakeholder Map

Stakeholder Key Concerns Class Catalogs, Matrices and

Diagrams
CxO The high-level drivers, goals and Keep Business Footprint diagram
objectives of the organization, and Satisfied Goal/Objective/Service diagram
how these are translated into an Organization Decomposition
effective process and IT architecture diagram
to advance the business

Program Prioritizing, funding, and aligning Keep Project Context diagram

Management change activity. An understanding of Satisfied Business Footprint diagram
Office project content and technical Application Communication
dependencies adds a further diagram
dimension of richness to portfolio
management and decision making. Functional Decomposition
diagram

HR The roles and Actors that support the Keep Organization Decomposition
functions, applications, and Informed diagram
technology of the organization. HR Organization/Actor catalog
are important stakeholders in Location catalog
ensuring that the correct roles and
actors are represented.

278
Step 3: Confirm business goals, drivers and
constraints

If they are already defined

 Make sure they are current

 Clarify ambiguity

Otherwise define and approve them

279
Step 4: Evaluate capabilities

Focus on:

 The EA capability itself (i.e. the capability to design, implement and

maintain EA)

 The existing and required enterprise capabilities

Document the results in a Capability Assessment

Consider the relationship between the capabilities and the value chain

280
Value Chain Diagram

Source: Wikipedia.org
281
Step 5: Assess readiness for business transformation

Determine and assess business transformation factors

The results are used to:

 shape the scope of the architecture,

 identify activities required within the architecture project

 identify risk areas to be addressed

282
Step 6: Define the Scope

Define:
 Breadth of coverage
 Level of detail
 The partitioning characteristics of the architecture
 Domains to be covered
 Schedule project milestones
 Identify Enterprise Continuum assets for use:
• Created from previous ADM cycles
• Existing reference frameworks, models, and so on…

Level of coverage may differ from baseline to target

 Baseline may be at a high level giving time to design the target in more
details

283
Step 7: Confirm and elaborate Architecture Principles,
including business principles

Principles are defined in the preliminarily phase

 Make sure they are current

 Clarify ambiguity

Otherwise define and approve them with the architecture board responsible
for governance

284
Step 8: Develop Architecture Vision

A high-level view of the Baseline and Target Architectures

Informal techniques are often used

High level business scenarios are useful here

Covers all domains in scope (i.e. BDAT)

Stored in the Architecture Repository

285
Solution Concept Diagram

A high-level representation of the solution envisaged

A pencil sketch of the expected solution at the outset of the engagement

286
Step 9: Define the Target Architecture value
propositions and KPIs

Develop the business case

Produce the value proposition for stakeholders

Assess and define the procurement requirements

Define the performance metrics

Assess the business risk

Incorporate the outputs in the Statement of Architecture Work

287
Step 10:Identify the business transformation risks and
mitigation activities

Identify, assess and mitigate the risks

Consider the initial and residual levels of risks

Incorporate the outputs in the Statement of Architecture Work

288
Step 11: Develop Statement of Architecture Work;
Secure approval

This acts as the EA project plan containing:

 New work products
 Existing work products to be changed
 Impact of change on other work products
 Architecture domains to develop
 Resource
 Estimation and schedule
 Performance metrics
 Communications Plan

Review and approve the SOW and obtain the sponsor signoff

Continued…
289
Statement of Architecture Work

 Title  Roles, responsibilities and

deliverables
 Architecture project request and
background  Acceptance criteria and
procedures
 Architecture project description
and scope  Architecture project plan and
schedule
 Overview of Architecture vision
 Approvals
 Change of scope procedures

290
Phase A: Outputs

 Approved Statement of
Architecture Work including:
 Refined statements of business
principles, goals, and drivers
 Architecture Principles including
business principles
 Capability Assessment
 Tailored Architecture Framework
 Architecture Vision
 Draft Architecture Definition
Document
 Communications Plan
 Additional content populating the
Architecture Repository
Summary

Phase A is about project

establishment

It initiates an iteration of the

architecture process

It sets the scope, constraints and

expectations for this iteration

It validates the business context

It creates the Statement of

Architecture Work
 Summary
Phase A: Architecture Vision

Objectives Steps Inputs Outputs

Develop a high-level aspirational vision Establish the architecture project Request for Architecture Work Approved Statement of Architecture Work
of the capabilities and business value Identify stakeholders, concerns, and Refined statements of business principles, business goals,
to be delivered as a result of the business requirements Business principles, business goals, and business and business drivers
proposed Enterprise Architecture Confirm and elaborate business drivers Architecture Principles
goals, business drivers, and Capability Assessment
Obtain approval for a Statement of constraints Organizational Model for Enterprise Architecture Tailored Architecture Framework
Architecture Evaluate business capabilities Architecture Vision, including:
Work that defines a program of works Assess readiness for business Tailored Architecture Framework, including tailored  Refined key high-level stakeholder requirements
to develop and deploy the architecture transformation architecture method, architecture content, Draft Architecture Definition Document, including (when in
outlined in the Architecture Vision Define scope Architecture Principles, configured and deployed tools scope):
Confirm and elaborate Architecture  Baseline Business Architecture (high-level)
Principles, including business Populated Architecture Repository; that is, existing  Baseline Data Architecture (high-level)
principles architecture documentation (framework description,  Baseline Application Architecture (high-level)
Develop Architecture Vision architecture descriptions, existing baseline  Baseline Technology Architecture (high-level)
Define the Target Architecture value descriptions, etc.)  Target Business Architecture (high-level)
propositions and KPIs  Target Data Architecture (high-level)
Identify business transformation risks  Target Application Architecture (high-level)
and mitigation activities  Target Technology Architecture (high-level)
Develop Statement of Architecture Communications Plan
Work; secure approval Additional content populating the Architecture Repository
TOGAF Standard, Version 9.2 Artifacts

294
Test Yourself Question

Q. Complete the following sentence: Phase A Architecture Vision is intended

to do all the following except:

A. Validate the business principles and goals of the organization

B. Ensure that the architecture principles are correct
C. Establish IT Governance
D. Clarify and correct ambiguities in the architecture principles
E. Define the specific architecture domains to be addressed

295
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 6. Phase A: Architecture Vision

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap06.html
Practical Example – Vision Document
Module 13
Stakeholder Management
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives are to:

 Explain how to apply the stakeholder management technique

 Understand the steps in developing a stakeholder map and how to use

the map

 Understand the benefits for creating views and relating those to

stakeholder and their concerns

299
Overview

Stakeholder Management is an important discipline that successful

architecture practitioners can use to win support from others

It should be used in Phase A to identify key players and updated throughout

each phase

Documented in the Communications Plan

300
Benefits

Early identification and involvement of the most powerful stakeholders and

getting their support

Can be used to anticipate likely reactions and develop a strategy to address

them

Can be used to identify conflicting or competing objectives amongst

stakeholders and develop strategies to manage

All of this is expected to lead project success

301
Stakeholders

Executive CxO

Programme
Management Office

Line
Management
Stakeholders are individuals, teams,
organizations, or classes thereof,
Executive
having an interest in a system.
They are people who have key roles
HR Line in, or concerns about, the system; Application
Management
Management
for example, users, developers, etc.
Infrastructure Procurement
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications

Stakeholder Types

QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project

302
Stakeholder Management

Executive CxO

Programme
Management Office

The Line
TOGAF standard provides a step by step
Management

approach:
Executive

Step 1: Identify Stakeholders

Step 2: Classify Stakeholder Positions Application
HR Line Management
Step 3:
Management Determine Stakeholder Management Approach
Step 4: Tailor Engagement Deliverables Procurement
Infrastructure
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications

Stakeholder Types

QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project

303
Step 1: Identify Stakeholders

 Who gains and who loses from this change?

 Who controls change management of processes?
 Who designs new systems?
 Who will make the decisions?
 Who procures IT systems and who decides what to buy?
 Who controls resources?
 Who has specialist skills the project needs?
 Who has influence?

 Consider formal and informal stakeholders

 Consider visible and invisible stakeholders

304
Categories of Stakeholder

305
 Step 2: Classify Stakeholder Positions

Classify and record positions in a Stakeholder Analysis Matrix

Stakeholder Stakeholder Ability to Current Required Current Required Required

Group Disrupt Understanding understanding commitment commitment support
the
change

CIO John H M H L M H
Smith

CFO Jeff M M M L M M
Brown

306
Step 3: Determine Stakeholder Management Approach

Work out stakeholder power, influence and interest, so as to focus the

engagement on the key individuals

These can then be mapped onto a power/interest matrix, which is used to

determine the strategy for engaging with them

307
Step 3: Determine Stakeholder Management Approach

308
Step 4: Tailor Engagement Deliverables

For each Stakeholder Group define:

 Viewpoints

 Views

 Matrices

309
Example: Stakeholder Map

STAKEHOLDER CLASS EXAMPLE ROLES KEY CONCERNS CLASS Catalogs, Matrices and Diagrams
GROUP
Corporate CxO CEO, CFO, CIO, The high level drivers, goals and KEEP Business Footprint diagram
Functions COO objectives of the organization, and how SATISFIED Goal/Objective/Service diagram
these are translated into an effective Organization Decomposition diagram
process and IT architecture to advance Business Capabilities catalog
the business. Capability/Organization matrix
Strategy/Capability Map
Corporate Program Project Portfolio Prioritizing, funding and aligning KEEP Requirements Catalog
Functions Management Managers change activity. An understanding of SATISFIED
Office project content and technical Business Footprint diagram
dependencies between projects adds a
further dimension of richness to Application
portfolio management decision making. Communication diagram

Functional
Decomposition diagram
Corporate Procurement Acquirers Understanding what building blocks KEY Technology Portfolio catalog
Functions of the architecture can be bought, and PLAYERS
what constraints (or rules) exist that are Technology Standards Catalog
relevant to the purchase. The acquirer
will shop with multiple vendors looking
for the best cost solution while adhering
to the constraints (or rules) applied by
the architecture, such as standards. The
key concern is to make purchasing
decisions that fit the architecture, and
thereby to reduce the risk of added costs
arising from non-compliant components.
Summary

Stakeholder Management is an important discipline that successful

architecture practitioners can use to win support from others

Identifies the most powerful stakeholders early and ensures their input is
used to shape the architecture

Explicitly identifies viewpoints to address stakeholder concerns

311
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 21. Stakeholder Management

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap21.html
Workshop

Create stakeholder map for your EA

project
Module 14
Architecture Views and
Viewpoints
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To understand the concepts of

Architecture Views and Architecture
Viewpoints

To understand the role of

Architecture Views

To introduce some TOGAF

resources

Source: www.pfosphene.com
315
Concepts and Definitions

System

Stakeholder

Concern

Architecture View

Architecture Viewpoint

316
System

A system is a combination of interacting elements organized to achieve one

or more stated purposes.

Source: IONA

Source: SGI

317
Stakeholders

Executive CxO

Programme
Management Office

Line
Management
Stakeholders are individuals, teams,
organizations, or classes thereof,
Executive
having an interest in a system.
They are people who have key roles
HR Line in, or concerns about, the system; Application
Management
Management
for example, users, developers, etc.
Infrastructure Procurement
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications

Stakeholder Types

QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project

318
Concerns

Executive CxO

Programme
Concerns are interests in a system Management Office

Line
Management
relevant to one or more of its
stakeholders. Concerns may
Executive pertain to any aspect of the
system’s functioning, development,
or operation, including Application
HR Line Management
Management performance, reliability, security,
distribution, and evolvability, and Infrastructure Procurement
Management
IT Service Business
Functional /
Business
may determine the acceptability of
Management Domain
Experts
Process
Experts the system Data /Voice
Communications

Stakeholder Types

QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project

319
Architecture View (synonym: View)

An Architecture View is a representation of a system from the perspective of

a related set of concerns.

 Example from building architecture

320
Architecture Viewpoint (synonym: Viewpoint)

An Architecture Viewpoint defines the perspective from which an

architecture view is taken.

 It defines how to construct and use an architecture view

321
Source: ISO/IEC/IEEE Std 40210-2011. Used with permission
Architecture Views and Viewpoints

Used in phases A to D

An architecture view is what you see

An architecture viewpoint is where you are looking from

Every architecture view has an associated architecture viewpoint that

describes it, at least implicitly.

Architecture viewpoints are generic, and can be stored in libraries for reuse.

An architecture view is always specific to the architecture for which it is

created.

323
What is an Architecture View?

A representation of an overall architecture with meaning to one or more

stakeholders in the system

For example: a building architect might create wiring diagrams, floor plans,
and elevations to describe different facets of a building to its different
stakeholders (electricians, owners, planning officials etc.)

An enterprise architect might create physical and security views of an IT

system

324
A Simple Example of an Architecture Viewpoint

Architecture Viewpoint Description

Element
Stakeholders Management Board, CEO
Concerns Show the top-level relationships between US/UK
geographical sites and business functions
Modeling Technique Nested boxes diagram.
technique
Outer boxes = locations;
Inner boxes = business functions.
Semantics of nesting = functions performed in the
locations.

325
A Simple Example of an Architecture View

Figure 1: Example View - The Open Group Business Domains

326
Developing Architecture Views in the ADM

The architect has a responsibility for ensuring:

 the completeness of the architecture

• does it address all the concerns of its stakeholders?

 the integrity of the architecture

• can the architecture views be connected to each other?

• can the conflicting concerns be reconciled?

• what trade-offs have been made (e.g. between security and performance)?

327
The Architecture View Creation Process

1. Refer to any existing libraries of viewpoints

2. Select key stakeholders

3. Analyze their concerns

4. Select appropriate architecture viewpoints

5. Generate views

328
Benefits

Less work for the architects (the viewpoints have already been defined and
so the views can be created faster)

Better comprehensibility for stakeholders (the viewpoints are already

familiar)

Greater confidence in the validity of the views (their viewpoints have a

known track record)

329
The Architecture View Creation Process
(Cont’d)

If no libraries of architecture viewpoints exist then:

1. Select key stakeholders
2. Analyze their concerns
3. Develop new architecture viewpoints
4. Generate views

Alternatively create an ad hoc architecture view and then consider whether a

generalized form of the implicit viewpoint should be defined explicitly and
saved.

330
Using TOGAF Artifacts

Catalogs

Matrices

Diagrams

331
Catalogs

Catalogs are lists of building blocks of a specific type, or of related types

For example

 Principles Catalog created in the Preliminary Phase

 Organization/Actor Catalog created in Phase B

 Driver/Goal/Objective Catalog

332
Matrices

Matrices show the relationships between building blocks of specific types

Matrices are used to represent list-based rather than graphical-based

relationships

For example

 The Stakeholder Map Matrix created in Phase A

333
Stakeholder Map Matrix

STAKEHOLDER KEY CONCERNS CLASS Catalogs, Matrices and Diagrams

CxO – CEO, CFO, The high level drivers, goals and objectives of the KEEP Business Footprint diagram
CIO, COO organization, and how these are translated into an SATISFIED
effective process and IT architecture to advance the Goal/Objective/Service diagram
business.
Organization Decomposition
diagram
Program Prioritizing, funding and aligning change activity. KEEP Requirements Catalog
Management An understanding of project content and technical SATISFIED
Office dependencies between projects adds a further dimension Business Footprint diagram
– Project of richness to portfolio management decision making.
Portfolio Application
Managers Communication diagram

Functional
Decomposition diagram
Procurement Understanding what building blocks of the architecture KEY Technology Portfolio catalog
- Acquirers can be bought, and what constraints (or rules) exist that PLAYERS
are relevant to the purchase. The acquirer will shop with Technology Standards Catalog
multiple vendors looking for the best cost solution while
adhering to the constraints (or rules) applied by the
architecture, such as standards. The key concern is to
make purchasing decisions that fit the architecture, and
thereby to reduce the risk of added costs arising from
non-compliant components.
Diagrams

Diagrams representing building blocks in a rich and visual way, especially

suited to stakeholder communication

For example

 Value Chain diagram created in Phase A

 Business footprint diagram created in Phase B

335
Example Business Footprint Diagram

336
TOGAF Standard, Version 9.2 Artifacts

337
Summary

In general, TOGAF embraces the concepts and definitions of ISO/IEC/IEEE

42010: 2011, specifically those that guide the development of an
architecture view and make the view actionable, such as:
 Selecting key stakeholders
 Analyzing their concerns and documenting them
 Understanding how to model and deal with those concerns

The language used to depict the architecture view is the architecture

viewpoint. Viewpoints provide architecture concepts from different
perspectives, including components, interfaces, and allocation of services
critical to the view.

338
Summary

When applying the TOGAF framework a number of tailoring steps should

occur:
 The architecture viewpoints provided should be customized to create a
set of architecture views that ensure all stakeholder concerns are met
 New architecture viewpoints and architecture views should be created to
address specific needs

339
Test Yourself Question

Q. Views and viewpoints are used by an architect to capture or model the

design of a system architecture. Which of the following statements is
true?

A A view is the perspective of an individual stakeholder

B Different stakeholders always share the same views
C Some views do not have associated viewpoints
D A viewpoint is the perspective of an individual stakeholder
E Views and viewpoints are rarely used in TOGAF

340
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 31. Architectural Artifacts

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap31.html
Practical Example – Architecture Views
Workshop

Identify 3 different viewpoints, their

associated stakeholders and their
associated views
Module 15
Business Transformation
Readiness Assessment
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The importance of business transformation readiness assent

 How to identify business transformation readiness factors

 How to assess business transformation readiness factors

Business Transformation Readiness Assessment

EA involves considerable change

The readiness of an organization to accept change must be assessed and

understood

This assessment is a key success factor in phases E and F

Initial assessment is done in phase A

This is a joint effort between corporate staff, lines of business and IT

planners.

346
Business Transformation Readiness Assessment
Steps

1. Determine the readiness factors

2. Present the readiness factors using maturity models (current,

intermediate and target)

3. Assess the readiness factors (urgency, readiness and difficulty)

4. Assess the risks for each readiness factor and identify mitigating actions

5. Work these actions into Phase E and F Implementation and Migration

Plan

347
Readiness Factors

 Vision  Accountability

 Desire, Willingness and Resolve  Workable Approach and

Execution Model
 Need
 IT Capacity to Execute
 Business Case
 Enterprise Capacity to Execute
 Funding
 Enterprise Ability to Implement
 Sponsorship and Leadership and Operate

 Governance

348
Assess the Readiness Factors

349
Readiness Factor Rating

350
Readiness Factor Risks & Actions

Assess each factor using Risk Management techniques

Identify a series of improvement actions

Incorporate into the Implementation and Migration Plan

351
Summary

Readiness of the enterprises for EA must be assessed

Carefully identify readiness factors

Identify the maturity levels of each factor

Assess each factor according to its maturity levels

Identify risks associated with readiness factors and mitigate them

Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 26. Business Transformation Readiness Assessment

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap26.html
Practical Example –
Business Transformation Readiness
Workshop

List the business transformation

readiness factors in your EA project

For one of your factors, identify:

 The maturity levels
 The current maturity level
 The target maturity level
Module 16
Risk Management
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand how to:

 Identify risks

 Analyze risks

 Mitigate risks

 Monitor risks
Risk Management

A technique used to mitigate risk when implementing an architecture project.

It is important to identify, classify, and mitigate these risks before starting so

that they can be tracked throughout the transformation effort.

358
Risk Management in the ADM

There are two levels of risk that should be considered:

 Initial Level of Risk: Risk categorization prior to determining and
implementing mitigating actions.
 Residual Level of Risk: Risk categorization after implementation of
mitigating actions

The process for risk management is:

 Risk classification
 Risk identification
 Initial risk assessment
 Risk mitigation and residual risk assessment
 Risk monitoring

359
Risk Management in the ADM

Risks are identified in Phase A as part of the initial Business Transformation

Readiness Assessment

Risks are maintained and monitored as governance artifacts in Phase G

New risks may be identified in Phase G (or at any other phase actually)

Another full or partial ADM cycle may be required to mitigate some risks

360
Initial risk assessment

Identify effect and frequency

Effect degrees could be: Frequency degrees could be:

 Catastrophic  Frequent
 Critical  Likely
 Marginal  Occasional
 Negligible  Seldom
 Unlikely

361
Risk Score or Risk Level

The assessments of effect and frequency are combined:

 Extremely High Risk (E)

 High Risk (H)

 Moderate Risk (M)

 Low Risk (L)

362
Risk Classification Scheme

363
Risk Identification and Mitigation Worksheet

364
Summary

Initial Risk is a risk categorization prior to determining and implementing

mitigating actions

Residual Risk is a risk categorization after implementation of mitigating

actions

Risk management steps are:

 Risk classification
 Risk identification
 Initial risk assessment
 Risk mitigation and residual risk assessment
 Risk monitoring
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 27. Risk Management

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap27.html
Practical Example – Risk Management
Module 17
Business Scenarios
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To understand how to apply the Business Scenarios technique

To understand where it is used in the TOGAF standard

369
Roadmap
Introduction

Key factors in the success of any enterprise architecture are:

 the extent to which it is linked to business requirements,

and

 its support for business objectives.

Business scenarios help us to identify and understand

the business requirements that the architecture
development must address.

371
What is a Business Scenario?

A business scenario describes:

 a business process, application or set of applications that can be

enabled by the architecture

 the business and technology environment;

 the people and computing components (the “actors”) who execute it;

 the desired outcome of proper execution.

372
Business Scenarios

The TOGAF Series Guide: Business Scenarios (G176) defines a method for
developing Business Scenarios

 It is positioned as a “method within a method”

373
Business Scenarios and the ADM

Used prominently in Phase A

(Architecture Vision) and iteratively
in Phase B (Business Architecture)

Business Requirements are referred

to throughout all phases of the ADM
What is a Good Business Scenario?

A good business scenario:

 Is representative of a significant business need or problem

 Enables vendors to understand the value of a developed solution to a

customer.

 Is “SMART”

375
SMART

Specific
defines what needs to be done to done in the business;
Measurable
has clear metrics for success;
Actionable
clearly segments the problem, and provides the basis for finding a solution;
Realistic
defines the bounds of technology capability and cost constraints;
Time-bound
gives a clear understanding of when a solution expires

376
The Benefits of Business Scenarios

Complete and clarify the requirements

Clarify the business value to solving the problem

Clarify the relevance of potential solutions

Early stakeholders engagement

377
Who Contributes to a Business Scenario?

The enterprise architect – but not alone

Business line management and other stakeholders

IT vendors

Typically involvement of management is greatest in the early stages

(problem definition) whereas the involvement of the architect is greatest in
later stages (solution description)

378
Developing a Business Scenario

1 - Identify, document and rank the

problem 1 - problem
2 - Identify the business and
technical environment 2 - environment

3 - Identify and document SMART

3 - objectives
objectives
4 - Identify the human actors
4 - human actors
5 - Identify computer actors
6 - Identify and document roles,
5 - computer actors
responsibilities and measures of
success per actor
6 - roles & responsibilities
7 - Check for “fitness for purpose”
and refine if necessary
7 - refine

379
Getting Business Scenarios Right

If customers know what they want

 We write it down

If customers do not know what they want

 We observe and probe to help discover what’s needed
 We help bring out critical business rules
 We focus on the “what” not the “how”

Business Scenarios are a technique, not an end in themselves

380
Some reminders

Business Scenarios are a part of (and enable) a larger process

Business Scenarios are just a technique, not an objective

Use them, don’t get lost in them

Workshop Follow up
Focus Focus

Brainstorm/ Documentation and Allocate

Requirements
Interview Model of Business
Validation
Requirements to
Scenario Appropriate Forum
Sessions

Business Scenarios Provide Coherence and Consistency 381

Resources

The Open Group Library (http://publications.opengroup.org)

 The TOGAF Series Guide: Business Scenarios

 Examples of completed Business Scenarios

382
Summary

Business scenarios help address one of the most common issues facing
businesses
 Aligning the IT with the business

Business scenarios help to identify and understand business needs

 And thereby derive business requirements

They are just a technique, not the goal

 They are part of the larger process of architecture development

383
Practical Example – AS IS Business Scenario
Practical Example – TO BE Business Scenario
Workshop

Identify the business scenario for the

most confusing part of your EA
project
Module 18
Phase B:
Business Architecture V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase B:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

388
Phase B Objectives

Develop the Target Business Architecture

Identify candidate Architecture Roadmap components based upon gaps

between Baseline and Target Business Architectures

389
Approach

 Knowledge of the Business Architecture is a prerequisite for Data,

Applications and Technology architectures
 Business Strategy defines what to achieve
 Business Architecture describes how to achieve it
 Check if some of the Business Architecture work is already done under
another discipline (e.g. business planning or enterprise planning)
 Scope depends on existing strategy and planning
 If there is no existing strategy or planning, identify any existing
architecture definitions, then verify and update
 In both cases, use business scenarios to identify key business
objectives and processes

390
Phase B: Inputs

 Request for Architecture Work

 Business principles, goals and
drivers
 Capability Assessment
 Communications Plan
 Organization Model for Enterprise
Architecture
 Tailored Architecture Framework
 Approved Statement of Architecture
Work
 Architecture Principles
 Enterprise Continuum
 Architecture Repository
 Architecture Vision
 Draft Architecture Definition
Document
Steps

9. Create Architecture Definition

Document
The order of the steps
should be adapted to 8. Finalize the Business Architecture
the situation.
7. Conduct formal stakeholder review
In particular you should 6. Resolve impacts across the Architecture
determine whether it is Landscape
appropriate to do the
Baseline Business 5. Define candidate roadmap components
Architecture or Target
4. Perform gap analysis
Business Architecture
development first
3. Develop Target Business Architecture Description

2. Develop Baseline Business Architecture Description

1. Select reference models, viewpoints, and tools

Step 1: Select Reference Models, Viewpoints, and
Tools

Select resources

Select viewpoints

Identify appropriate tools and techniques

Determine overall modelling process

Continued…

393
Mapping Value Streams to
Business Capabilities

394
Organization Mapping

A representation of the organizational structure

395
Additional Techniques

396
Step 1: Select Reference Models, Viewpoints, and
Tools

Identify Required Service Granularity Level, Boundaries, and Contracts

Identify Required Catalogs. Matrices, and Diagrams

 See next slide

Identify Types of Requirement to be Collected

397
TOGAF Standard, Version 9.2 Artifacts

Note:
Next module provides detailed
information on Phase B Catalogs,
Matrices and Diagrams

398
Step 2: Develop Baseline Business Architecture
Description

Describe the baseline business architecture in details necessary to design

the target business architecture

If possible, describe the baseline Business Architecture as building blocks

Use the models identified in step 1 to describe the baseline Business

Architecture

399
Step 3: Develop Target Business Architecture
Description

Describe the target business architecture in details necessary to support the

architecture vision

If possible, describe the target Business Architecture as building blocks

Use the models identified in step 1 to describe the target Business

Architecture

400
Step 4: Perform Gap Analysis

Identify gaps between the baseline and target architectures using Gap
Analysis technique

Continued…

401
Step 5: Define Candidate Roadmap Components

Business roadmap is required to prioritize activities over the coming phases

Business Architecture roadmap will be used as raw material to support

cross-discipline roadmap within the Opportunities & Solutions phase

402
Step 6: Resolve Impacts Across the Architecture
Landscape

Identify:

 The impact on any pre-existing architectures

 The impact of any recent changes on the Business Architecture

 The impact on other areas of the organization

 The impact of the Business Architecture on other projects

 The impact of other projects on the Business Architecture

403
Step 7: Conduct Formal Stakeholder Review

Compare the business architecture with the SOW

404
Step 8: Finalize the Business Architecture

Select standards for each of the ABBs

Fully document each ABB

Cross check the overall architecture against the business goals

Document final requirements traceability report

Identify reusable ABBs

405
Step 9: Create Architecture Definition Document

Document the rationale for all building block decisions

Prepare the business sections of the architecture definition document report.

Prepare business views using the identified modeling tools

Review the architecture definition document

406
Phase B: Outputs

 Statement of Architecture Work

 Validated business principles,
goals and drivers
 Refined and updated Business
Architecture Principles
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Business Architecture
components of an Architecture
Roadmap
Architecture Definition Document

 Scope  Rationale and justification for

 Goals, objectives, and architectural approach
constraints  Mapping to Architecture
 Architecture Principles Repository:
 Baseline Architecture • Mapping to Architecture Landscape
 Architecture models (for each
• Mapping to reference models
state to be modeled): • Mapping to standards
• Business Architecture models
• Re-use assessment
• Data Architecture models  Gap analysis
• Application Architecture models  Impact assessment
• Technology Architecture models  Transition Architecture

408
Architecture Definition Document – Business
Architecture Components

 Baseline Business Architecture, if • Business processes, including

appropriate – this is a description of measures and deliverables
the existing Business Architecture • Business roles, including development
and modification of skills requirements
 Target Business Architecture,
including: • Business data model
• Organization structure – identifying • Correlation of organization and
business locations and relating them to functions – relate business functions to
organizational units organizational units in the form of a
matrix report
• Business goals and objectives – for the
 Views corresponding to the
enterprise and each organizational unit
• Business functions – a detailed, selected viewpoints addressing key
stakeholder concerns
recursive step involving successive
decomposition of major functional
areas into sub-functions
• Business services – the services that
the enterprise and each enterprise unit
provides to its customers, both
internally and externally

409
Architecture Requirements Specification

 Success measures
 Architecture requirements
 Business service contracts
 Application service contracts
 Implementation guidelines
 Implementation specifications
 Implementation standards
 Interoperability requirements
 IT service management requirements
 Constraints
 Assumptions

410
Architecture Requirements Specification – Business
Architecture Components

Gap analysis results

Technical requirements

Updated business requirements

411
Summary

Phase B is about about development

of the Business Architecture:
 a holistic representation of
business capabilities, end-to-end
value delivery, information, and
organizational structure, along
with the relationships to
strategies, products, policies,
initiatives, and stakeholders.

It should show how the organization

meets its business goals.
 Summary
Phase B: Business Architecture

Objectives Steps Inputs Outputs

Develop the Target Business Select reference models, viewpoints, Request for Architecture Work Statement of Architecture Work, updated if
Architecture that describes how the and tools Business principles, business goals, and business drivers necessary
enterprise needs to operate to achieve Capability Assessment Validated business principles, business goals,
the business goals, and respond to the Develop Baseline Business Communications Plan and business drivers
strategic drivers set out in the Architecture Description Organizational Model for Enterprise Architecture Refined and updated Architecture Principles, if
Architecture Vision in a way that Tailored Architecture Framework applicable
addresses the Statement of Develop Target Business Architecture Approved Statement of Architecture Work Draft Architecture Definition Document
Architecture Work and stakeholder Description Architecture Principles, including business principles, when pre- containing content updates:
concerns existing  Baseline Business Architecture (detailed), if
Perform gap analysis Enterprise Continuum appropriate
Identify candidate Architecture Architecture Repository  Target Business Architecture (detailed with
Roadmap components based upon Define candidate roadmap Architecture Vision, including: Business Capabilities, Value Streams, and
gaps between the Baseline and Target components Refined key high-level stakeholder requirements Organization Map as core artifacts)
Business Architectures Draft Architecture Definition Document, including:  Views corresponding to selected viewpoints
Resolve impacts across the  Baseline Business Architecture (high-level) addressing key stakeholder concerns
Architecture Landscape  Baseline Data Architecture (high-level) Draft Architecture Requirements Specification
 Baseline Application Architecture (high-level) including content updates:
Conduct formal stakeholder review  Baseline Technology Architecture (high-level)  Gap analysis results
 Target Business Architecture (high-level)  Technical requirements
Finalize the Business Architecture  Target Data Architecture (high-level)  Updated business requirements
 Target Application Architecture (high-level) Business Architecture components of an
Create Architecture Definition  Target Technology Architecture (high-level) Architecture Roadmap
Document
Test Yourself Question

Q. Choose the correct ending for the following phrase:

“Business Architecture is the first architecture activity undertaken because
…”
A. It is often necessary to demonstrate the business value of the overall
architecture activity
B. It provides knowledge that is a prerequisite for undertaking architecture
work in the other domains (data, applications, technology)
C. It can be used to demonstrate the return on investment to key
stakeholders
D. It embodies the fundamental organization of a business and shows how
an organization meets its business goals
E. All of the above

414
Resource
Resource
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 7. Phase B: Business Architecture

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap07.html
Practical Example – AS IS Business Architecture
Practical Example – TO BE Business Architecture
Workshop

List the baseline and target:

 Capabilities
 Business units
 Roles
 Processes
 Business services

For your EA project

Module 19
Phase B: Business
Architecture – Catalogs,
Matrices and Diagrams
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The Catalogs, Matrices and Diagrams of Phase B, Business

Architecture

 What they consist of

 How they can be used

422
TOGAF Standard, Version 9.2 Artifacts

423
Catalogs, Matrices and Diagrams

Catalogs Diagrams
 Business Capabilities catalog  Business Model diagram (*)
 Value Stream catalog  Business Capability map
 Value Stream Stages catalog  Value Stream map
 Organization/Actor catalog  Organization map
 Driver/Goal/Objective catalog  Business Footprint diagram
 Role catalog  Business Service/Information diagram
 Business Service/Function catalog  Functional Decomposition diagram
 Location catalog  Product Lifecycle diagram
 Process/Event/Control/Product catalog  Goal/Objective/Service diagram
 Contract/Measure catalog  Use-Case diagram
 Organization Decomposition diagram
Matrices  Process Flow diagram
 Value Stream/Capability matrix  Event diagram
 Strategy/Capability matrix
 Capability/Organization matrix
 Business Interaction matrix The exact format of the
 Actor/Role matrix catalogs, matrices and
diagrams will depend on
the tools used
424
Catalogs

Catalog Purpose
Business A definitive listing of particular abilities that a business may possess or exchange
Capabilities to achieve a specific purpose.
Catalog

Value Stream A definitive listing of end-to-end collections of value-adding activities that create
Catalog an overall result for a customer, stakeholder, or end user.

Value Stream A definitive listing of end-to-end collections of the different stages for the value-
Stages Catalog adding activities that create an overall result for a customer, stakeholder, or end
user; it includes the following metamodel entities:
Business Capability
Value Stream
Catalogs

Catalog Purpose
Organization/ A definitive listing of all participants that interact with IT, including users and owners of IT systems.
It contains the following metamodel entities:
Actor
•Organization Unit, Actor Location (may be included in this catalog if an independent Location catalog is
Catalog not maintained)

Driver/Goal/ A cross-organizational reference of how an organization meets its drivers in practical terms through
goals, objectives, and (optionally) measures.
Objective It contains the following metamodel entities:
Catalog •Organization Unit, Driver, Goal, Objective, Measure (may optionally be included)

Role Catalog The purpose of the Role catalog is to provide a listing of all authorization levels or zones within an
enterprise. Frequently, application security or behavior is defined against locally understood concepts of
authorization that create complex and unexpected consequences when combined on the user desktop.
It contains the following metamodel entities:
•Role
Catalogs

Catalog Purpose
Business A functional decomposition in a form that can be filtered, reported on, and queried, as a supplement to
graphical Functional Decomposition diagrams.
Service / It contains the following metamodel entities:
Function •Organization Unit,Business Function, Business Service, Information System Service (may optionally be
Catalog included here)

Location A listing of all locations where an enterprise carries out business operations or houses architecturally
relevant assets, such as data centers or end-user computing equipment.
Catalog It contains the following metamodel entities:
•Location

Process/ The Process/Event/Control/Product catalog provides a hierarchy of processes, events that trigger
processes, outputs from processes, and controls applied to the execution of processes. This catalog
Event/ Control/ provides a supplement to any Process Flow diagrams that are created and allows an enterprise to filter,
Product report, and query across organizations and processes to identify scope, commonality, or impact.
It contains the following metamodel entities:
Catalog
•Process, Event, Control, Product
Catalogs

Catalog Purpose
Contract/ A listing of all agreed service contracts and (optionally) the measures attached to those
contracts. It forms the master list of service levels agreed to across the enterprise.
Measure
Catalog It contains the following metamodel entities:
•Business Service
•Information System Service (optionally)
•Contract
•Measure
Matrices

Capability/Organization matrix

Strategy/Capability matrix

Value Stream/Capability matrix

Business Interaction matrix

Actor/Role matrix

429
Capability/Organization Matrix

The purpose of this matrix is to show the organization elements that

implement each capability.

Business Capability Value Stream Organization Unit

Program Management Define Position Business Development

HR Management Interview Candidates Human Resources

Finance Management Communicate Position Finance

430
Strategy/Capability Matrix

The purpose of this matrix is to show the capabilities required to support

specific strategy statements

Strategy Statement Business Capabilities

Leverage brand names and Legal services, Marketing management,

strategically link businesses for Product development
synergy
Invest to accelerate growth of Finance Management, Mergers and
the company Acquisitions

431
Value Stream/Capability Matrix

The purpose of this matrix is to show the capabilities required to support

each stage of a value stream.

Value Stream Stage Business Capabilities

Define Position Program Management, HR Management

Communicate Position HR Management, Finance Management

Assess Responses HR Management

Interview Candidates HR Management, Agreement Management

Onboard Employee HR Management, Asset Management, Facilities

Management, Security Management,
Information Management
432
Business Interaction Matrix

The purpose of this matrix is to depict the relationship interactions between

organizations and business functions across the enterprise.

Providing Business Services

Consuming Business Services Engineering Procurement Manufacturing Sales and Distribution Customer Service
Engineering
Procurement
Contract for
Contract for supply of
Manufacturing supply of
sales forecasts
materials
Contract for
supply of Contract for
Sales and Distribution
product supply of product
specification
Contract for fulfillment of
Customer Service
customer orders

433
Actor/role Matrix

This matrix show which actors perform which roles, supporting definition of
security and skills requirements.
Infrastructure
Office of Steering Group Business Unit Strategy and Architecture
Implementation
CIO Actors Actors Actors Actors
Actors

Enterprise Infrastructure Architect

Business Unit Application Architect

Infrastructure Solution Architect

Architecture Configuration Mgr

Head of Strategy and Architecture
Business Unit Service Owner

External Vendors / Suppliers

Enterprise Design Authority

Technical Design Authority

Head of Implementation
Infrastructure Strategist

Infrastructure Designer
IT Management Forum
Enterprise Architect

Business Unit Head

Project Manager
IT Operations
R = Responsible for carrying out the role
A = Accountable for actors carrying out the role
C = Consulted in carrying out the role
I = Informed in carrying out the role CIO
Strategy Lifecycle Roles
Architecture Refresh I R A I C C R C C C I I R I C C
Architecture Roadmap I C A I R C C I C R I I R C C I C
Benefits Assessment I I I I I I I I I R R I C A
Change Management C I A I I I R I I I R R C
Framework Refresh C C C C C I C A I I I R C C I
Project Lifecycle Roles
Solution Architecture Vision I I I A I I C C I I R I C C R
Logical Solution Architecture A I I C C I I R I C C C R
Physical Solution Architecture A I I C C I I R I C R C R
Design Governance A I I C C I I R I C R C C
Architecture Configuration Management C I I R R R A

434
Diagrams

 Business Capability Map

 Value Stream Map
 Organization Map
 Business Footprint diagram
 Business Service/Information diagram
 Functional Decomposition diagram
 Product Lifecycle diagram
 Goal/Objective/Service diagram
 Use-Case diagram
 Organization Decomposition diagram
 Process Flow diagram
 Event diagram

435
Business Capability Map

A family of diagrams representing a definitive listing of the particular abilities

that a business may possess or exchange to achieve a specific purpose.

436
Value Stream Map

A family of diagrams representing a definitive listing of end-to-end

collections of value-adding activities that create an overall result for a
customer, stakeholder, or end user.

437
Mapping Value Streams to
Business Capabilities

438
Organization Map

A diagram showing the relationships between the primary entities that make
up the enterprise, its partners, and stakeholders

439
Business Footprint Diagram

Describes the links between business goals, organizational units, business

functions, and services, and maps these functions to the technical
components delivering the required capability.

Demonstrates only the key facts linking organization unit functions to

delivery services and is utilized as a communication platform for senior-level
(CxO) stakeholders

440
Example Business Footprint Diagram

441
Business Service/Information Diagram

Shows the information needed to support one or more business services.

Shows what data is consumed by or produced by a business service and

may also show the source of information.

Shows an initial representation of the information present within the

architecture and therefore forms a basis for elaboration and refinement
within Phase C (Data Architecture).

442
Example Business Service/Information Diagram

Complaint

Complaint Handling
Common Faults
Service

Customer Details

Complaint
Resolution Customer Details

Basic example

443
Example Business Service/Information Diagram

Complaint
Fault
Complaint Handling
Common Faults Management
Service
Service

Customer Details

Customer

Complaint
Resolution Customer Details

Lead
Management
Service

Extended example showing actors and

service interactions

444
Functional Decomposition Diagram

It shows on a single page the capabilities of an organization that are

relevant to the consideration of an architecture.

By examining the capabilities of an organization from a functional

perspective, it is possible to quickly develop models of what the organization
does without being dragged into extended debate on how the organization
does it.

445
Example Functional Decomposition Diagram

446
Product Lifecycle Diagram

This assists in understanding the lifecycles of key entities within the

enterprise.

Understanding product lifecycles is becoming increasingly important with

respect to environmental concerns, legislation, and regulation where
products must be tracked from manufacture to disposal.

Equally, organizations that create products that involve personal or sensitive

information must have a detailed understanding of the product lifecycle
during the development of Business Architecture in order to ensure rigor in
design of controls, processes, and procedures. Examples of this include
credit cards, debit cards, store/loyalty cards, smart cards, user identity
credentials (identity cards, passports, etc.).

447
Example Product Lifecycle Diagram

448
Goal/Objective/Service Diagram

This defines the ways in which a service contributes to the achievement of a

business vision or strategy.

Services are associated with the drivers, goals, objectives, and measures
that they support, allowing the enterprise to understand which services
contribute to similar aspects of business performance.

This also provides qualitative input on what constitutes high performance for
a particular service.

449
Example Goal/Objective/Service Diagram

Goal:Increase Role:CFO
Revenues

Role: Role:
VP Marketing VP Sales
Objective: Objective:
After Sales Creating new line
Market of cars by end of…

Function:
Sales and
Marketing
Service:
Marketing
Service: Pre-
owned vehicles-

Service:
Campaign

Service:
Sales

Service:
Pre-Sales

Service: Order
To Delivery
450
Business Use-case Diagram

This displays the relationships between consumers and providers of

business services.

Business services are consumed by actors or other business services and

the Business Use-Case diagram provides added richness in describing
business capability by illustrating how and when that capability is used.

They help to describe and validate the interaction between actors and their
roles to processes and functions.

As the architecture progresses, the use-case can evolve from the business
level to include data, application, and technology details. Architectural
business use-cases can also be re-used in systems design work.

451
Example Business Use-case Diagram

452
Organization Decomposition Diagram

This describes the links between actor, roles, and location within an
organization tree.

An organization map should provide a chain of command of owners and

decision-makers in the organization.

453
Example Organization Decomposition Diagram

454
Process Flow Diagram

This depicts all models and mappings related to the process metamodel
entity.

It shows sequential flow of control between activities and may utilize swim-
lane techniques to represent ownership and realization of process steps.

In addition to showing a sequence of activity, process flows can also be

used to detail the controls that apply to a process, the events that trigger or
result from completion of a process, and also the products that are
generated from process execution.

455
Example Process Flow Diagram

Start
Step 1 Step 2 Step 3 Step 4

Step 5 Step 6 Step 6 Step 6 STOP

456
Example Process Flow Diagram

Technical Support
Team
Sales Rep
Pricer Pricer

Start Step 2
Step 1 Step 3 Step 4

Custom app Email CRM

MS Word
MS Excel

Custom Bid
Approver Customer Rep Customer Rep
Customer Rep

Step 5 Step 6 Step 6 Step 6 STOP

IWF email Consolidation

Spreadsheet
Tool

Process Flow (w/Roles & Applications)

457
Events Diagram

This depicts the relationship between events and process.

Certain events - such as arrival of information (e.g. a customer’s sales

order) or a point in time (e.g. end of fiscal quarter) cause work and actions
to be undertaken within the business.

458
Example Events Diagram

Impacts/Generates
Triggers
Event Business
Process result

(e.g. End of Fiscal

Quarter) (e.g. 1Q results reported to
(e.g. Financial Reporting Government Agencies)
Process)

459
Example Events Matrix

EVENT PROCESS TRIGGERED BUSINESS RESULT(S)

Customer submits Sales order processing  Sales order captured in order

sales order  Create & save sales order book
 Generate acknowledgement
 Confirm receipt of customer order
 Begin order fulfillment activities

Customer submits Custom product configuration  Custom product configured

request for  Capture requirements from customer  Customer contract signed
custom product  Define custom specifications
 Price custom configuration
 Negotiate with customer
 Secure approval from customer regarding configuration and
price

End of quarter Financial reporting process  Financial report generated

Module 20
Building Blocks
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

To understand the concepts of Building Blocks within TOGAF

 Architecture Building Blocks

 Solution Building Blocks

To understand their role within application of the ADM

A comparison with Architecture Patterns

462
Building Block Characteristics

A package of functionality defined to meet the business needs across an

organization

A building block has a type that corresponds to the metamodel (e.g. actor,
application, data entity …)

A building block has published interfaces to access functionality

A building block may interoperate with other, inter-dependent building blocks

463
A Good Building Block

Considers implementation and usage and evolves to exploit technology and

standards

May be assembled from or a subassembly of other building blocks

Is reusable and replaceable

464
Building Blocks

Systems are built from collections of building blocks

ABBs group functionality

SBBs group real products

465
ABBs and SBBs

ABBs SBBs
Related to Architecture Continuum Solutions Continuum
ADM Phases A, B, C and D E
Functionality Products
Define
Requirements Components
Product
Aware of Technology
Vendor
ABBs direct and guide development of SBBs
Relationship
SBBs implement functionality defined in ABBs

466
Building Block Design

An architecture need only contain building blocks

Building blocks may implement one, more than one, or only part of a service
identified in the architecture

Building blocks should conform to standards

Consider the integration between BBs

BBs could be developed, purchased or reused

467
 Start with
abstract entities

A high level model of

candidate building blocks
 Start with
abstract entities Step 1: Select Reference Models,
Viewpoints and Tools
The TOGAF standard provides
example catalogs, matrices and
diagrams for use

Step 2: Develop Baseline

Architecture Description
Develop a high-level model of
existing building blocks, re-using
definitions from the Architecture
Repository where they are
available
 Start with Step 3: Develop Target
abstract entities Architecture Description
Develop view of required building blocks
through the creation of catalogs, matrices
and diagrams
Fully document each building block
Document rationale for building block
decisions
Identify the impacted building blocks
within the Architecture Repository, re-
using where appropriate
Where necessary, define new building
blocks
Select standards for each building block
Document mapping of building blocks to
Architecture Landscape
Identify building blocks for re-use, publish
as either standards or reference models
 Start with
Step 4: Perform Gap Analysis
abstract entities
Identify carried over, eliminated
and new building blocks
Identify gaps and determine
realization approach

Step 5: Define Candidate

Roadmap Components

Step 6: Resolve Impacts across

the Architecture Landscape
 Start with
abstract entities

In Phases B, C and D:
Building blocks within the
Business, Data, Applications and
Technology Architectures are
evolved to a common pattern of
steps

Building Block architecture

in ABB and SBB forms

Associate building blocks with work

packages that will address the gaps
Architecture Patterns

Pattern: defined as “an idea that has been useful in one practical context
and will probably be useful in others”

In the TOGAF standard, patterns are considered to be a technique for

putting building blocks into context; for example, to describe a re-usable
solution to a problem.

Building blocks are what you use: patterns can tell you how you use them,
when, why, and what trade-offs you have to make in doing so.

473
Examples of Building Architecture Patterns

474
Examples of EA Patterns

https://patterns.arcitura.com/cloud-computing-patterns
https://patterns.arcitura.com/soa-patterns

475
Test Yourself Question

Q. Which of the following statements describe generic building blocks?

 A building block is a package of functionality defined to meet the

business needs.
 A building block has published interfaces to access the functionality.
 A building block may be assembled from other building blocks.
 A building block may have multiple implementations.
 All of these

476
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 33. Building Blocks

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap33.html
Practical Example – Building Blocks
Module 21
Gap Analysis (technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to:

 Know where is the Gap Analysis in the ADM

 Understand how to analyze the gaps

Gap Analysis

Spot gaps between the Baseline Architecture and the Target Architecture

Gap Analysis is used in Phases B,C,D and E

481
Gap Analysis Example

482
Gap Analysis Example

483
Summary

Gap Analysis is used in Phases B,C,D and E

Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 23. Gap Analysis

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap23.html
Workshop

Perform Gap Analysis for one of the

following:
 Capabilities
 Processes
 Business services
Module 22
Interoperability
(technique)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The meaning and importance of interoperability

 How to define interoperability

 When to use interoperability in the ADM

Interoperability

Interoperability is ‘‘the ability to share information and services’’.

The TOGAF standard provides techniques for

 Defining interoperability

 Refining interoperability

 Determining interoperability requirements

The determination of interoperability occurs throughout the ADM cycle

489
Architecture Development Method

The nature and security

considerations Information and service
exchanges are defined in
business terms

Interoperability is In Data Architecture:

implemented logically. The content of information
exchanges
In Application Architecture:
The way applications to
share information

Actual solutions Appropriate technical

mechanisms
490
Examples

491
Interoperability requirements and solutions

Ensure absence of interoperability conflicts, especially in case of reusability

and COTs.

Changes to the business processes will be the most difficult.

The workflow between the various systems must also be taken into account.

Any change to the business interoperability requirements must be agreed by

the business architects and sponsors in a revised Statement of Architecture
Work.

492
Interoperability requirements and solutions

To find interoperability constraints consider:

 the Architecture Vision

 the Target Architecture

 the Implementation Factor Assessment and Deduction matrix

 the Consolidated Gaps, Solutions, and Dependencies matrix

493
Summary

Interoperability is ‘‘the ability to share information and services’’

Business and application interoperability requirements drive identification of

the data to be exchanged, the technical interoperability mechanism and the
actual interoperability solution

Interoperability is mainly considered in phases A to G

Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 25. Interoperability Requirements

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap25.html
Workshop

Represent the baseline

interoperability between the
business units of your EA project
Module 23
Phase C:
Information Systems
Architectures – Overview V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The aim of this module is to understand:

 The objectives of Phase C, Information Systems Architectures

 The Approach

This module is an introduction to the next two modules that look at the two
Information Systems Architectures

498
Phase C Objectives

Develop the Target Data / Application Architecture

Identify candidate Architecture Roadmap components based upon gaps

between the Baseline and Target Information Systems Architectures

499
Approach

Phase C involves Data and Applications Architecture, in either order

Advocates exist for both sequences

Continued…

500
Top-Down Design – Bottom-up Implementation

Design: Implementation:

 Business Architecture  Technology Architecture

 Data (or Applications)  Applications (or Data)

Architecture Architecture

 Applications (or Data)  Data (or Applications)

Architecture Architecture

 Technology Architecture  Business Architecture

501
Alternative Approach: Data-Driven Sequence
Implementation

First implement application systems that create data

Then applications that process the data

Finally, applications that archive data

502
Approach: Architecture Repository

Consider generic models relevant to an organization’s industry

Data Architecture Resources

Generic data models, for example the ARTS data models (Retail industry),
Energistics Data Exchange Standards (Petrotechnical industry)

Application Architecture Resources

Generic application models, for example from the TM Forum
(telecommunications industry), the OMG has a number of software models
for specific verticals (Healthcare, Transportation, Finance etc)

503
Considerations for Data Architecture

Data Management Data Migration

 System of record  Migration requirements like level
 Data standards of migration, weeding, cleansing,
 Which business unit/function format
utilizes which data entity  Establish enterprise-wide
 Data complexity, creation, common data definition
storage, transportation and
reporting Data Governance
 Data integration with customers  Structure
and suppliers  Management System
 people

504
Summary

The objective of Phase C is to

document the fundamental
organization of an organization’s IT
System
 Embodied in the major types of
information and the application
systems that process hem
 Their relationships to each other
and the environment
 The principles governing its
design and evolution
 It should document how the IT
systems meets the business
goals of the organization
Test Yourself Question

Q. Which of the following describes the order of steps in Phase C?

A. Data Architecture first

B. Applications Architecture first
C. Either Data Architecture or Applications Architectures first, as long as
both are done
D. Data Architecture and Applications Architecture must be carried out in
parallel
E. Either Data Architecture or Applications Architecture first, or both in
parallel depending on the project scope and the best fit with the Business
Architecture

506
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 8. Phase C: Information Systems Architectures

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap08.html
Module 24
Phase C:
Data Architecture V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand Phase C: Data Architecture:

 Objectives

 Inputs

 Steps

 Outputs

509
Data Architecture – Objectives

Develop the Target Data Architecture

Identify candidate Architecture Roadmap components based upon gaps

between the Baseline and Target Data Architectures

510
Phase C – Data: Inputs

 Request for Architecture Work

 Capability Assessment
 Communications Plan
 Organization model for
enterprise architecture
 Tailored Architecture Framework
 Data principles
 Statement of Architecture Work

Continued…
Phase C – Data: Inputs

 Architecture Vision
 Architecture Repository
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Business Architecture
components of an Architecture
Roadmap
Steps

The order of the steps 9. Create Architecture Definition

should be adapted to the Document
situation.
8. Finalize the Data Architecture
In particular you should
determine whether it is 7. Conduct formal stakeholder review
appropriate to do the
Baseline Data Architecture 6. Resolve impacts across the Architecture
or Target Data Architecture Landscape
development first 5. Define candidate roadmap components

4. Perform gap analysis

3. Develop Target Data Architecture Description

2. Develop Baseline Data Architecture Description

1. Select reference models, viewpoints, and tools

Step 1: Select reference models, viewpoints, and tools

 Review/generate and validate data principles

 Select Data Architecture resources
 Select relevant Data Architecture viewpoints
 Identify appropriate tools and techniques
 Determine Overall Modelling Process (e.g. DODAF, ARTS …)
 Address all stakeholders’ concerns
 Identify Required Catalogs, Metrics and Diagrams of Data Building
Blocks
 Identify Types of Requirements to be Collected

Continued…

514
TOGAF Standard, Version 9.2 Artifacts

Note:
Next Module provides detailed
information on Phase C: Data
Architecture, Catalogs, Matrices
and Diagrams

515
Step 2: Develop a Baseline Data Architecture
Description

If possible, describe the baseline Data Architecture as building blocks

Use the models identified in step 1 to describe the baseline Data

Architecture

Continued…

516
Step 3: Develop Target Data Architecture Description

If possible, describe the target Data Architecture as building blocks

Use the models identified in step 1 to describe the target Data Architecture

517
Step 4: Perform Gap Analysis

Identify gaps between the baseline and target architectures using Gap
Analysis technique

518
Step 5: Define candidate roadmap components

Data Architecture roadmap will be used as raw material to support cross-

discipline roadmap within the Opportunities & Solutions phase

519
Step 6: Resolve impacts across the Architecture
Landscape

Identify:

 The impact on any pre-existing architectures

 The impact of any recent changes on the Data Architecture

 The impact on other areas of the organization

 The impact of the Data Architecture on other projects

 The impact of other projects on the Data Architecture

520
Step 7: Conduct Formal Stakeholder Review

Compare the Data Architecture with the SOW

Conduct impact analysis on Business and Application Architectures

Identify constraints on Technology Architecture

Continued…

521
Step 8: Finalize the Data Architecture

Select standards for each of the ABBs

Fully document each ABB

Cross check the overall architecture against the business requirements

Document final requirements traceability report

Identify reusable ABBs

522
Step 9: Create Architecture Definition Document

Document the rationale for all building block decisions

Prepare the data sections of the architecture definition document report.

Prepare data views using the identified modeling tools

Review the architecture definition document

523
Phase C: Outputs: Data Architecture

 Statement of Architecture Work

 Validated data principles, or new

data principles

 Draft Architecture Definition

Document

 Draft Architecture Requirements

Specification

 Data Architecture components of

an Architecture Roadmap
Architecture Definition Document – Data Architecture
Components

Baseline Data Architecture, if appropriate

Target Data Architecture, including:

 Business data model
 Logical data model
 Data management process models
 Data Entity/Business Function matrix

Data Architecture views corresponding to the selected viewpoints

addressing key stakeholder concerns

525
Architecture Requirements Specification –
Data Architecture Components

Gap analysis results

Data interoperability requirements

Areas where the Business Architecture may need to change in order to

comply with changes in the Data Architecture

Constraints on the Technology Architecture about to be designed

Updated business/application/data requirements, if appropriate

526
Summary

The Data Architecture phase defines

the types and sources of data
needed to support the business, in a
way that can be understood by
stakeholders.

The architecture team should

consider existing relevant data
models, such as the ARTS and
Energistics models.
 Summary
Phase C: Information Systems Architectures – Data Architecture
Objectives Steps Inputs Outputs
Develop the Target Data Architecture that Select reference models, viewpoints, Request for Architecture Work Statement of Architecture Work, updated if
enables the Business Architecture and the and tools Capability Assessment necessary
Architecture Vision, in a way that Communications Plan Validated data principles, or new data
addresses the Statement of Architecture Develop Baseline Data Architecture Organizational Model for Enterprise Architecture principles
Work and stakeholder concerns Description Tailored Architecture Framework
Data principles Draft Architecture Definition Document
Identify candidate Architecture Roadmap Develop Target Data Architecture Statement of Architecture Work containing content updates:
components based upon gaps between Description Architecture Vision  Baseline Data Architecture
the Baseline and Target Data Architecture Repository  Target Data Architecture
Architectures Perform gap analysis  Data Architecture views corresponding to the
Draft Architecture Definition Document containing: selected viewpoints, addressing key
Define candidate roadmap components  Baseline Business Architecture (detailed) stakeholder concerns
 Target Business Architecture (detailed)
Resolve impacts across the Architecture  Baseline Data Architecture (high-level) Draft Architecture Requirements Specification
Landscape  Target Data Architecture (high-level) including content updates:
 Baseline Application Architecture (detailed or high-level)  Gap analysis results
Conduct formal stakeholder review  Target Application Architecture (detailed or high-level)  Data interoperability requirements
 Baseline Technology Architecture (high-level)  Relevant technical requirements that will
Finalize the Data Architecture Target Technology Architecture (high-level) apply to this evolution of the architecture
development cycle
Create Architecture Definition Document Draft Architecture Requirements Specification including:  Constraints on the Technology Architecture
 Gap analysis results  Updated business requirements
 Relevant technical requirements  Updated application requirements
Business Architecture components of an Architecture
Roadmap Data Architecture components of an
Architecture Roadmap

528
Test Yourself Question

Q. Which of the following is/are logical data model(s) which can be used
during Data Architecture?

A. DODAF
B. ARTS
C. Energistics Data Model for the Petrotechnical industry
D. Zachman

529
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 9. Phase C: Information Systems Architectures - Data

Architecture
https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap09.html
Practical Example – AS IS Data Architecture
Practical Example – TO BE Data Architecture
Workshop

Perform Gap Analysis for the data

domain of your EA project
Module 25
Phase C: Data
Architecture – Catalogs,
Matrices, and Diagrams
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The Catalogs, Matrices and Diagrams of Phase C, Data Architecture

 What they consist of

 How they are used

535
TOGAF Standard, Version 9.2 Artifacts

536
Catalogs, Matrices and Diagrams

Catalogs Diagrams
 Data Entity/Data Component  Conceptual Data diagram
catalog  Logical Data diagram
 Data Dissemination diagram
 Data Security diagram
Matrices  Data Migration diagram
 Data Entity/Business Function  Data Lifecycle diagram
matrix
 Application/Data matrix
The exact format of the
catalogs, matrices and
diagrams will depend on
the tools used

537
Catalogs

Catalog Purpose
Data Entity/Data To identify and maintain a list of all the data use across the enterprise, including
Component data entities and also the data components where data entities are stored.
Catalog
It contains the following metamodel entities:
•Data Entity
•Logical Data Component
•Physical Data Component
Matrices

Data Entity/Business Function matrix

Application/Data matrix

539
Data Entity/Business Function Matrix

The Data Entity/Business Function matrix depicts the relationship between

data entities and business functions within the enterprise.

The mapping of the Data Entity-Business Function relationship enables:

 Assignment of ownership of data entities to organizations
 Understand the data and information exchange requirements business
services
 Support the gap analysis and determine whether any data entities are
missing and need to be created
 Define system of origin, system of record, and system of reference for
data entities
 Enable development of data governance programs across the enterprise
(establish data steward, develop data standards pertinent to the
business function, etc.)

540
Example Data Entity/Business Function Matrix

BUSINESS
FUNCTION
CUSTOMER BUSINESS CUSTOMER PRODUCT
(Y-AXIS) /
MASTER PARTNER LEADS MASTER
DATA
ENTITY (X-AXIS)
Customer  Business partner data  Business partner  Lead Processing  N/A
Relationship management service data management Service
Management  Owner – Sales & Marketing service  Owner – Customer
business unit executive  Owner of data entity Relationship Manager
 Function can Create, read, (person or  Function can only
update and delete customer organization) Create, read, update
master data  Function can Create, customer leads
read, update and
delete

Supply Chain  Customer Requirement  N/A  N/A  Product data

Management Processing Service management
 Owner – Supply Chain Manager service
 Owner – Global
product
development
organization
Application/Data Matrix

The Application/Data matrix depicts the relationship between applications

and the data entities that are accessed and updated by them.

Applications will create, read, update, and delete specific data entities that
are associated with them.

 For example, a CRM application will create, read, update, and delete
customer entity information.

542
Example Application/Data Matrix

APPLICATION (Y-AXIS)
DESCRIPTION OR COMMENTS DATA ENTITY DATA ENTITY TYPE
AND DATA (X-AXIS)

CRM System of record for customer Customer data Master data

master data

Commerce Engine System of record for order Sales orders Transactional data
book

Sales Business Warehouse and data mart that Intersection of multiple data Historical data
Warehouse supports North American region entities (e.g. All sales orders by
customer XYZ and by month for
2006)
Diagrams

Conceptual Data diagram

Logical Data diagram

Data Dissemination diagram

Data Security diagram

Data Migration diagram

Data Lifecycle diagram

544
Conceptual Data Diagram

It depicts the relationships among the critical data entities (or classes) within
the enterprise.
Account
I.A1
Information

Update Customer Actor

Account Profile
P.A12 I.C2 Trigger

Contact Process
P.CS13
Payment
T.P8 P.CS5
Service
Agent Enquiry
Request
A.A4 T.C1
Customer
A.C2 Customer
Appeal Complaint
Information
I.C1 T.C19 T.C16

545
Logical Data Diagram

It depicts logical views relationships among the critical data entities (or
classes) within the enterprise.

The audience is

 Application developers

 Database designers

546
Data Dissemination Diagram

The Data Dissemination diagram shows the relationship between

 data entity
 business service
 application components

The diagram should show how the logical entities are to be physically
realized by application components.

Additionally, the diagram may show data replication and system ownership
of the master reference for data.

547
Example Data Dissemination Diagram

Warehouse
Warehouse
Customer
Order History
Stock

Online Account
Online Account
Self
SelfService
Service

Billing
Billing
Customer
Account Balance
Invoice History

Business Service Data Entities Application

Online Account Self Service Customer Warehouse

Billing

Order History Warehouse

Stock Warehouse

Account Balance Billing

Invoice History Billing

548
Data Security Diagram

The Data Security diagram depicts which actor (person, organization, or

system) can access which enterprise data.

This relationship can also be shown in a matrix form between two objects or
can be shown as a mapping.

549
Example Data Security Diagram

Class of Roles
(by job function)
Actor Business Process
Function

Single
- Sign
Physical
On or
Access
Access Control

Location Business
Service

Access Control
(levels of
Granularity)
Access Control
(levels of Logical
Granularity) Application
Component

550
Example Data Security Matrix

CLASS OF
BUSINESS TYPE OF
ACTOR ROLES (JOB FUNCTION LOCATION
SERVICE ACCESS
FUNCTION)
Financial Analyst SOA Portfolio Financial Analysis SOA portfolio service  NA (US, CA)  Physical
Financial Analyst  EMEA (UK, DE)  Access Control
 APJ (tables xyz only)

Procurement & Procurement WW Direct Supplier portal  NA (US Midwest)  Access control
Spend Analyst Management and Procurement Service
Control

WW Contracts Not applicable WW Direct Supplier Portal  LA  Access control

System Procurement Service (system to
(application) system)

WW Product Geo Brand WW Direct Supplier Portal  WW (all Geos)  Access Control
Development Managers Procurement Service
(Org Unit)
Data Migration Diagram

The Data Migration diagram shows the flow of data from the source to the
target applications.

The diagram provides a visual representation of the spread of

sources/targets and serve as a tool for data auditing and establishing
traceability.

552
Example Data Migration Diagram

“Baseline” Data migration technology “Target” application

application components components
components

ABM
Source of Customer CRM
records

CCB System of Record for

Customer Master

ERP
BDW
Source of order
history System of Record for
Material Master & Order
history

Source Transformation & Target

MRPA Staging Data Quality Staging
Source of Material
data SRM
VLC (one
per geo) System of Record for
Source of vendor Vendor Master &
data Contracts
Example Data Migration Mapping

SOURCE LOGICAL TARGET LOGICAL APPLICATION

SOURCE DATA ELEMENT TARGET DATA ELEMENT
APPLICATION COMPONENT COMPONENT
ABM Cust_Name CRM CUSTNAME

Cust_Street_Addr CUSTADDR_LINE1

Cust_Street_Addr CUSTADDR_LINE2

Cust_Street_Addr CUSTADDR_LINE3

Cust_ContactName CUSTCONTACT

Cust_Tele CUSTTELEPHONE
Data Lifecycle Diagram

The Data Lifecycle diagram is an essential part of managing business data

throughout its lifecycle from conception until disposal within the constraints
of the business process.

Fulfilment Order
New Fulfilled Invoiced Paid Closed Archived Deleted

Customer Order
New Dispatched Closed Archived Deleted

555
Module 26
Phase C:
Application Architecture V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand Phase C: Application

Architecture:

 Objectives

 Inputs

 Steps

 Outputs

557
Application Architecture – Objectives

Develop the Target Application Architecture

Identify candidate Architecture Roadmap components based upon gaps

between the Baseline and Target Application Architectures

558
Phase C: Inputs: Application Architecture

 Request for Architecture Work

 Capability Assessment
 Communications Plan
 Organization model for
enterprise architecture
 Tailored Architecture Framework
 Application principles
 Statement of Architecture Work

Continued…
Phase C: Inputs: Application Architecture

 Architecture Vision
 Architecture Repository
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Business and Data Architecture
components of an Architecture
Roadmap

Continued…
Steps

The order of the steps 9. Create Architecture Definition

should be adapted to the Document
situation. 8. Finalize the Application Architecture
In particular you should
determine whether it is 7. Conduct formal stakeholder review
appropriate to do the
Baseline Application 6. Resolve impacts across the Architecture
Architecture or Target Landscape
Application Architecture 5. Define candidate roadmap components
development first
4. Perform gap analysis

3. Develop Target Application Architecture Description

2. Develop Baseline Application Architecture Description

1. Select reference models, viewpoints, and tools

Step 1: Select reference models, viewpoints, and tools

Review/generate and validate application principles

Select Application Architecture resources

Select relevant Aplication Architecture viewpoints

Identify appropriate tools and techniques

Consider using platform-independent descriptions of business logic (e.g. the

OMG’s MDA)

Determine Overall Modelling Process (e.g. TM Forum model for

telecommunication, OMG models for healthcare, transportation, finance …)

562
Step 1: Select reference models, viewpoints, and tools

Address all stakeholders’ concerns

Identify Required Catalogs, Metrics and Diagrams of Application Building

Blocks

Identify Types of Requirements to be Collected

563
TOGAF Standard, Version 9.2 Artifacts

Note:
Next module provides detailed
information on Phase C:
Application Architecture,
Catalogs, Matrices and Diagra

564
Recommended Application Architecture Modelling
Process

 Identify required applications or application components

 Simplify complicated applications by decomposition
 Ensure consistency of applications
• Remove duplicate functionality
• Combine similar applications
 Identify logical applications and the most appropriate physical
applications
 Relate applications to business service, business function, data, process
… using matrices or diagrams considering
• Integration
• Migration
• Development
• Operational concerns

565
III-RM
Business and Technical Drivers

The cause:
• multiple systems, conceived and developed individually Sell Space
Compounding the problem: Customer Support
• cross-functional teams continuously forming, new Selling
business partners, stove-piped information
Internal Space
Manufacturing
Appl 1 Legal
Finance Online
Appl 2 Assembling Systems
Buy Space
Appl 50 Design
Procuring Systems
Appl 1 ERP
Partner 1
Systems
Appl 2 Requirements
Systems
Partner 2 Appl 50
Appl 1
Procurement Systems
Systems
Appl 2

Partner 3000 566

Appl 50
Step 2: Develop a Baseline Application Architecture
Description

If possible, describe the baseline Application Architecture as building blocks

Use the models identified in step 1 to describe the baseline Application

Architecture

Continued…

567
Step 3: Develop Target Application Architecture
Description

If possible, describe the target Application Architecture as building blocks

Use the models identified in step 1 to describe the target Application

Architecture

568
Step 4: Perform Gap Analysis

Identify gaps between the baseline and target architectures using Gap
Analysis technique

569
Step 5: Define candidate roadmap components

Application Architecture roadmap will be used as raw material to support

cross-discipline roadmap within the Opportunities & Solutions phase

570
Step 6: Resolve impacts across the Architecture
Landscape

Identify:

 The impact on any pre-existing architectures

 The impact of any recent changes on the Application Architecture

 The impact on other areas of the organization

 The impact of the Application Architecture on other projects

 The impact of other projects on the Application Architecture

571
Step 7: Conduct Formal Stakeholder Review

Compare the Application Architecture with the SOW

Conduct impact analysis on Business and Data Architectures

Identify constraints on Technology Architecture

Continued…

572
Step 8: Finalize the Application Architecture

Select standards for each of the ABBs

Fully document each ABB

Cross check the overall architecture against the business requirements

Document final requirements traceability report

Identify reusable ABBs

573
Step 9: Create Architecture Definition Document

Document the rationale for all building block decisions

Prepare the application sections of the architecture definition document

report.

Prepare application views using the identified modeling tools

Review the architecture definition document

574
Phase C: Outputs: Application Architecture

 Statement of Architecture Work

– updated if necessary
 Validated application principles,
or new application principles
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Application Architecture
components of an Architecture
Roadmap
Architecture Definition Document –
Application Architecture Components

Baseline Application Architecture, if appropriate

Target Application Architecture, including:

 Process systems model
 Place systems model
 Time systems model
 People systems model

Application Architecture views

576
Architecture Requirements Specification –
Application Architecture Components

Gap analysis results

Application interoperability requirements

Potential changes in the Business Architecture

Constraints on the Technology Architecture

Updated business/application/data requirements, if appropriate

577
Summary

This phase defines the kinds of

applications necessary to process
the data and support the business.

The goal is to define what kinds of

applications are relevant and what
those applications need to do.
 Summary
Phase C: Information Systems Architectures – Application Architecture
Objectives Steps Inputs Outputs
Develop the Target Application Select reference models, viewpoints, Request for Architecture Work Statement of Architecture Work, updated if
Architecture that enables the Business and tools Capability Assessment necessary
Architecture and the Architecture Communications Plan
Vision, in a way that addresses the Develop Baseline Application Organizational Model for Enterprise Architecture Validated application principles, or new
Statement of Architecture Work and Architecture Description Tailored Architecture Framework application principles
stakeholder concerns Application Principles
Develop Target Application Statement of Architecture Work Draft Architecture Definition Document
Identify candidate Architecture Architecture Description Architecture Vision containing content updates:
Roadmap components based upon Architecture Repository  Baseline Application Architecture
gaps between the Baseline and Target Perform gap analysis  Target Application Architecture
Application Architectures Draft Architecture Definition Document containing:  Application Architecture views corresponding to
Define candidate roadmap  Baseline Business Architecture (detailed) the selected viewpoints, addressing key
components  Target Business Architecture (detailed) stakeholder concerns
 Baseline Data Architecture (detailed or high-level)
Resolve impacts across the  Target Data Architecture (detailed or high-level) Draft Architecture Requirements Specification
Architecture Landscape  Baseline Application Architecture (high-level) including content updates:
 Target Application Architecture (high-level)  Gap analysis results
Conduct formal stakeholder review  Baseline Technology Architecture (high-level)  Application interoperability requirements
 Target Technology Architecture (high-level)  Relevant technical requirements that will apply
Finalize the Application Architecture to this evolution of the architecture development
Draft Architecture Requirements Specification including: cycle
Create Architecture Definition  Gap analysis results  Constraints on the Technology Architecture
Document  Relevant technical requirements  Updated business requirements
Business and Data Architecture components of an Architecture  Updated data requirements
Roadmap Application Architecture components of an
Architecture Roadmap

579
Test Yourself Question

Q1. How should the applications best be described?

A. As computer systems
B. As logical groups of capabilities
C. As schemas
D. As data-flow diagrams
E. As UML diagrams

580
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 10. Phase C: Information Systems Architectures - Application

Architecture
https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap10.html
Practical Example – AS IS Application Architecture
Practical Example – TO BE Application Architecture
Workshop

Represent the target interoperability

between the application components
of your EA project
Module 27
Phase C: Application
Architecture – Catalogs,
Matrices and Diagrams
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The Catalogs, Matrices and Diagrams of Phase C, Application

Architecture

 What they consist of

 How they are used

586
TOGAF Standard, Version 9.2 Artifacts

587
Catalogs, Matrices and Diagrams

Catalogs Diagrams
 Application Portfolio catalog  Application Communication
 Interface catalog diagram
 Application and User Location
diagram
Matrices  Application Use-Case diagram
 Application/Organization matrix  Enterprise Manageability
 Role/Application matrix diagram
 Application/Function matrix  Process/Application Realization
 Application Interaction matrix diagram
 Software Engineering diagram
 Application Migration diagram
The exact format of the  Software Distribution diagram
catalogs, matrices and
diagrams will depend on
the tools used
588
Catalogs

Catalog Purpose
Application Portfolio To identify and maintain a list of all the applications in the enterprise. This list helps to define the
Catalog horizontal scope of change initiatives that may impact particular kinds of applications. An agreed
Application Portfolio allows a standard set of applications to be defined and governed.

It contains the following metamodel entities:

•Information System Service
•Logical Application Component
•Physical Application Component
Interface Catalog The purpose of the Interface catalog is to scope and document the interfaces between applications to
enable the overall dependencies between applications to be scoped as early as possible.

It contains the following metamodel entities:

•Logical Application Component
•Physical Application Component
•Application communicates with application relationship
Exercise

590
Matrices

Application/Organization matrix

Role/Application matrix

Application/Function matrix

Application Interaction matrix

591
Application/Organization Matrix

This matrix depicts the relationship between applications and organizational

units within the enterprise.

The mapping of the Application Component-Organization Unit relationship

enables the following to take place:
 Assign usage of applications to the organization units that perform
business functions
 Understand the application support requirements of the business
services and processes carried out by an organization unit
 Support the gap analysis and determine whether any of the applications
are missing and as a result need to be created
 Define the application set used by a particular organization unit

592
Example Application/Organization Matrix

APPLICATION
(Y-AXIS)
PROCUREMENT AND CORPORATE
AND CUSTOMER SERVICES HR
WAREHOUSING FINANCE
ORGANISATION
UNIT (X-AXIS)
SAP HR X X X

SIEBEL X X

SAP X X X
FINANCIALS

PROCURESOFT X X
Role/Application Matrix

This matrix depicts the relationship between applications and the business
roles that use them within the enterprise.

The mapping of the Application Component-Role relationship enables the

following to take place:
 Assign usage of applications to the specific roles in the organization
 Understand the application security requirements of the business
services and processes supporting the function, and check these are in
line with current policy
 Support the gap analysis and determine whether any of the applications
are missing and as a result need to be created
 Define the application set used by a particular business role; essential in
any move to role-based computing

594
Example Role/Application Matrix

APPLICATION (Y-
CALL CENTRE CHIEF
AXIS) AND FUNCTION CALL CENTRE MANAGER FINANCE ANALYST
OPERATOR ACCOUNTANT
(X-AXIS)
SAP HR X X X X

SIEBEL X X

SAP FINANCIALS X X X X

PROCURESOFT X X
Application/Function Matrix

This matrix depicts the relationship between applications and business

functions within the enterprise.

The mapping of the Application Component-Function relationship enables

the following to take place:
 Assign usage of applications to the business functions that are
supported by them
 Understand the application support requirements of the business
services and processes carried out
 Support the gap analysis and determine whether any of the applications
are missing and as a result need to be created
 Define the application set used by a particular business function

596
Example Application/Function Matrix

APPLICATION (Y-
GENERAL LEDGER
AXIS) AND FUNCTION CALL CENTRE 1ST LINE WAREHOUSE CONTROL VACANCY FILLING
MAINTENANCE
(X-AXIS)

SAP HR X X X X

SIEBEL X X

SAP FINANCIALS X X X

PROCURESOFT X X
Example Application Interaction Matrix

Application 1 Application 2 Application 3 Application 4

Application 1 Consumes

Application 2 Communicates with

Application 3 Consumes Communicates with

Application 4
Diagrams

 Application Communication diagram

 N2 model or Node Connectivity diagram
 Application and User Location diagram
 Application Use-Case diagram
 Enterprise Manageability diagram
 Process/Application Realization diagram
 Software Engineering diagram
 Application Migration diagram
 Software Distribution diagram

599
Application Communication Diagram

This diagram depicts all models and mappings related to communication

between applications in the metamodel entity.

It shows application components and interfaces between components.

Communication should be logical and should only show intermediary

technology where it is architecturally relevant.

600
Application Communication Diagram

601
Alternate Example:
N2 Model

1c
ABC
1a

1b
ABM 2a

3c

CCD 3a

4a
3b
CRM
1d

4b
IPC
3d

602
Alternate Example:
Information Exchange Matrix

LABEL SOURCE DESTINATION DATA ENTITY EVENT TRIGGERED

1a  ABC  ABM  Sales order  New sales order

(create request) from front end

1b  ABM  ABC  Sales order  Order created in

(confirm create) the backend ERP
system

2a  ABM  CCD  Product catalog  Subscribe/

Publish timer
Application & User Location Diagram

This diagram depicts the business locations from which business users
typically interact with the applications, but also the hosting location of the
application infrastructure.

The diagram enables:

 Identification of the number of package instances needed
 Estimation of the number and the type of user licenses
 Estimation of the level of support needed
 Selection of system management tools, structure, and management
system
 Appropriate planning for the technological components of the business
 Performance considerations while implementing solutions

604
Example Application & User Location Diagram (part 1)

INTERNAL,
USER
CUSTOMER LOCATION
APPLICATION USER TYPE BUSINESS
OR ADDRESS ORG UNIT (USER
LOCATION BELONGS TO)
PARTNER
CRM Developer Internal NA Western Chicago Sears NA Sales &
Super User Region tower office Marketing
Administrator Chicago
EMEA EMEA Sales
Headquarters, Downtown office
UK Middlesex, London

SAP R/3 Test Engineers Internal Beijing Manufacturing &

Mechanical Manufacturing logistics
Engineers Plant
Procurement
managers
Example Application & User Location Diagram (part 2)
Application Use Case Diagram

Source: wikipedia.org

607
Enterprise Manageability Diagram

The Enterprise Manageability diagram shows how one or more applications

interact with application and technology components that support
operational management of a solution.

Analysis can reveal duplication and gaps, and opportunities in the IT service
management operation of an organization.

608
Example Enterprise Manageability Diagram
Process/Application Realization Diagram

This diagram depicts the sequence of events when multiple applications are
involved in executing a business process.

It enhances the Application Communication diagram by augmenting it with

any sequencing constraints, and hand-off points between batch and real-
time processing.

610
Example Process/Application Realization Diagram
Software Engineering Diagram

The Software Engineering diagram breaks applications into packages,

modules, services, and operations from a development perspective.

It enables more detailed impact analysis when planning migration stages,

and analyzing opportunities and solutions.

It is ideal for application development teams and application management

teams when managing complex development environments.

612
Example Software Engineering Diagram
Application Migration Diagram

The Application Migration diagram identifies application migration from

baseline to target application components.

It enables a more accurate estimation of migration costs

It should be used to identify temporary applications, staging areas, and the

infrastructure required to support migrations

614
Example Application Migration Diagram
Software Distribution Diagram

This diagram is a composite of the Software Engineering diagram and the

Application-User Location diagram.

Depending on the circumstances, this diagram alone may be sufficient, or

may not be needed.

616
Module 28
The Integrated
Information Infrastructure
Reference Model (III-RM)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Roadmap
Module Objectives

The objectives are to:

 Describe the business and technical drivers for Boundaryless

Information Flow

 Describe the main components of the III-RM

 Explain how the III-RM was derived

 Explain the III-RM graphic

619
Key Business and Technical Drivers

Problem Space: The Need for Boundaryless Information Flow

The problem of getting information to the right people at the right time in a
secure, reliable manner

Solution Space: The Need for Integrated Information Infrastructure

We need:
 Integrated information so that different and potentially conflicting pieces
of information are not distributed throughout different systems
 Integrated access to that information so that staff can access all the
information they need and have a right to, through one convenient
interface

The infrastructure that enables this vision is called ‘‘integrated information

infrastructure’’.

620
Integrated Information Infrastructure Reference Model

A model of the key components for developing, managing, and operating an

integrated information infrastructure.

 Supporting “Boundaryless Information Flow”

A model of a set of applications that sit on top of an application platform.

An expanded subset of the TOGAF TRM, using different orientation.

621
TOGAF TRM

Qualities
Fundamentally a layered view, major
Infrastructure Applications Business Applications layers being
Application Platform Interface

International Operations
Transaction Processing
Software Engineering

Location & Directory

System & Network

Data Management

Graphics & Image

Data Interchange
 Application

User Interface
Management

Security

Operating System Services

 Application platform
Network Services

Communications Infrastructure Interface

Communication Infrastructure
Qualities
 Communications
TOGAF TRM Orientations

Side View Top Down View

Qualities
Infrastructure Applications Business Applications Qualities

Application Platform Interface

Communication Infrastructure

International Operations
Transaction Processing
Software Engineering
Comm Infrastructure Interfaces

Location & Directory

System & Network

Data Management

Graphics & Image

Data Interchange
User Interface
Management

Security
Network Services

Operating System Services

Application Platform

Appl Platform Interface

Operating System Services
Infra Apps Bus Apps

Network Services

Communications Infrastructure Interface

Qualities
Communication Infrastructure
Qualities
Boundaryless Information Flow Focus

Side View Top Down View

Qualities
Infrastructure Applications Business Applications Qualities

Application Platform Interface

Communication Infrastructure

International Operations
Transaction Processing
Software Engineering

Location & Directory

Comm Infrastructure Interfaces
System & Network

Data Management

Graphics & Image

Data Interchange
User Interface
Management

Security
Network Services

Operating System Services

Application Platform

Appl Platform Interfaces

Operating System Services
Infra Apps Bus Apps

Network Services

Communications Infrastructure Interface

Qualities
Communication Infrastructure

Qualities
Integrated Information Infrastructure Reference Model
– High-level Model

Security Qualities Mobility

Application Platform

Information Consumer Applications

Development Brokering Management

Tools Applications Utilities

Information Provider Applications

Performance SLAs Qualities Management Policy

Components of the III-RM

The III-RM has 2 main components:

 A taxonomy, which defines terminology, description of the components

and conceptual structure of III

 An III-RM graphic, which provides a visual representation, and inter-

relationships

626
Components of the High-Level III-RM

Business Applications:

Brokering Applications

Information Consumer Applications Information Provider Applications

Information Consumer Applications

Development Brokering Management
Tools Applications Utilities

Infrastructure Applications:
Information Provider Applications
Development Tools

Management Utilities

627
Components of the High-Level III-RM

An Application Platform, which provides supporting services to all the

applications and so provides the ability to locate, access, and move
information within the environment.

Application Platform

628
Components of the High-Level III-RM

The Interfaces used between the components. Interfaces include formats

and protocols, APIs, switches, data values, etc

The Qualities backplane. The Application Software and Application Platform

must adhere to the policies and requirements depicted by the qualities
backplane

629
Integrated Information Infrastructure Reference Model
– Detailed Model

Security Qualities Mobility

Application Platform
Web Portal Information Consumer Applications Desktop Video Conference

Streaming audio / video information Access Mail Phone / Fax

Directory Application Message Format

Referencing/Dereferencing Presentation
Application Messaging
Naming Transformation
Languages Libraries Application to application Browser services
Registries Registration communications services
Publish Portal and personalization
Enterprise Appl Integration Meta indices
Subscribe
Discovery
Development Tools Brokering Applications Management
Utilities
Business modeling tools Information Brokers Monitors
Design tools Application Integrators Executory Utilities
Construction tools Copy Managers
Languages and Libraries
Digital Signature Information Access
Info Format
Intrusion Detection Transformation Mapping
eForm services
Key Management Query distribution
Instant messaging services
Firewall Aggregation
Encryption Search
AAAC Web Portal Information Provider Applications Desktop Video Conference File services
SSO Web services
Streaming audio / video information Access Mail Phone / Fax

Messaging/Event Brokering Process/Workflow Control

Performance SLAs Qualities Management Policy

630
Summary

The III-RM has 2 main components: a taxonomy, and an associated

graphic.

A key driver for the III-RM is the Need for Boundaryless Information Flow:
getting information to the right people at the right time in a secure, reliable
manner

The infrastructure that enables this vision is called the ‘‘integrated

information infrastructure’’.

The III-RM has Business Applications, Infrastructure Applications, an

Application Platform, Interfaces and Qualities

631
Module 29
Phase D:
Technology Architecture V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase D:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

633
Phase D Objectives

Develop the Target Technology Architecture

Identify candidate Architecture Roadmap components based upon gaps

between the Baseline and Target Technology Architectures

634
Approach

Consider Emerging Technologies

 Evolution of new technologies is a major driver for

Review the Technology Architecture Resources available in the Architecture

Repository
 Existing IT Services in the IT Repository or IT Service Catalog
 The adopted technical reference model, if applicable
 Technology models relevant to the organization (e.g. TM Forum models
for telecommunication and the open group TRM and III-RM)

635
Technology Architecture: Inputs

 Request for Architecture Work

 Capability Assessment
 Communications Plan
 Organization model for
enterprise architecture
 Tailored Architecture Framework
 Technology principles
 Statement of Architecture Work
 Architecture Vision
 Architecture Repository
Continued…
Technology Architecture: Inputs

 Draft Architecture Definition Document,

containing:
• Baseline Business Architecture (detailed)
• Target Business Architecture (detailed)
• Baseline Data Architecture (detailed)
• Target Data Architecture (detailed)
• Baseline Application Architecture (detailed)
• Target Application Architecture (detailed)
• Baseline Technology Architecture (high-
level)
• Target Technology Architecture (high-level)
 Draft Architecture Requirements
Specification
 Business, Data, and Application
Architecture components of an
Architecture Roadmap
Steps

9. Create Architecture Definition

The order of the steps
Document
should be adapted to the
situation. 8. Finalize the Technology Architecture
In particular you should
determine whether it is 7. Conduct formal stakeholder review
appropriate to do the 6. Resolve impacts across the Architecture
Baseline Technology Landscape
Architecture or Target
Technology Architecture 5. Define candidate roadmap components
development first
4. Perform gap analysis

3. Develop Target Technology Architecture Description

2. Develop Baseline Technology Architecture Description

1. Select reference models, viewpoints, and tools

Step 1: Select reference models, viewpoints, and tools

 Review/generate and validate technology principles

 Select Technology Architecture resources
 Select relevant Technology Architecture viewpoints
 Identify appropriate tools and techniques
 Determine Overall Modelling Process
 Identify Required Catalogs, Metrics and Diagrams of Technology
Building Blocks
 Identify Types of Requirements to be Collected
 Select Services

639
TOGAF Standard, Version 9.2 Artifacts

Note:
Next module provides detailed
information on Phase D:
Technology Architecture,
Catalogs, Matrices and Diagrams

640
Step 2: Develop a Baseline Technology Architecture
Description

If possible, describe the baseline Technology Architecture as building blocks

Use the models identified in step 1 to describe the baseline Technology

Architecture

641
Step 3: Develop Target Technology Architecture
Description

If possible, describe the target Technology Architecture as building blocks

Use the models identified in step 1 to describe the target Technology

Architecture

642
Step 4: Perform Gap Analysis

Identify gaps between the baseline and target architectures using Gap
Analysis technique

643
Step 5: Define candidate roadmap components

Technology Architecture roadmap will be used as raw material to support

cross-discipline roadmap within the Opportunities & Solutions phase

644
Step 6: Resolve impacts across the Architecture
Landscape

Identify:

 The impact on any pre-existing architectures

 The impact of any recent changes on the Technology Architecture

 The impact on other areas of the organization

 The impact of the Technology Architecture on other projects

 The impact of other projects on the Technology Architecture

645
Step 7: Conduct Formal Stakeholder Review

Compare the Technology Architecture with the SOW

Does the Technology Architecture support other architecture domains?

Continued…

646
Step 8: Finalize the Technology Architecture

Select standards for each of the ABBs

Fully document each ABB

Cross check the overall architecture against the business requirements

Document final requirements traceability report

Identify reusable ABBs

647
Step 9: Create Architecture Definition Document

Document the rationale for all building block decisions

Prepare the technology sections of the architecture definition document

report.

Prepare technology views using the identified modeling tools

Review the architecture definition document

648
Technology Architecture Outputs

 Statement of Architecture Work,

updated if necessary
 Validated technology principles
or new technology principles
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Technology Architecture
components of an Architecture
Roadmap
Architecture Definition Document –
Technology Architecture Components

Baseline Technology Architecture, if appropriate

Target Technology Architecture, including:

 Technology components and their relationships to information systems
 Technology platforms and their decomposition
 Environments and locations
 Expected processing load and distribution of load
 Physical (network) communications
 Hardware and network specifications

Technology views

650
Architecture Requirements Specification –
Technology Architecture Components

Gap analysis results

Updated technology requirements

651
Summary

The purpose of Phase D:

Technology Architecture is to
transform application components
into a set of technology components.

The technology components can be

both software and hardware
components, available from the
market or configured within the
organization
 Summary
Phase D: Technology Architecture
Objectives Steps Inputs Outputs
Develop the Target Technology Select reference models, viewpoints, and Request for Architecture Work Statement of Architecture Work, updated if
Architecture that enables the tools Capability Assessment necessary
Architecture Vision, target business, Communications Plan Validated technology principles or new
data, and application building blocks to Develop Baseline Technology Architecture Organizational Model for Enterprise Architecture technology principles (if generated here)
be delivered through technology Description Tailored Architecture Framework
components and technology services, Technology principles Draft Architecture Definition Document
in a way that addresses the Statement Develop Target Technology Architecture Statement of Architecture Work containing content updates:
of Architecture Work and stakeholder Description Architecture Vision  Baseline Technology Architecture
concerns Architecture Repository  Target Technology Architecture
Perform gap analysis  Technology Architecture views corresponding
Identify candidate Architecture Draft Architecture Definition Document containing: to the selected viewpoints, addressing key
Roadmap components based upon Define candidate roadmap components  Baseline Business Architecture (detailed) stakeholder concerns
gaps between the Baseline and Target  Target Business Architecture (detailed)
Technology Architectures Resolve impacts across the Architecture  Baseline Data Architecture (detailed) Draft Architecture Requirements Specification
Landscape  Target Data Architecture (detailed) including content updates:
 Baseline Application Architecture (detailed)  Gap analysis results
Conduct formal stakeholder review  Target Application Architecture (detailed)  Requirements output from Phases B and C
 Baseline Technology Architecture (high-level)  Updated technology requirements
Finalize the Technology Architecture  Target Technology Architecture (high-level)
Technology Architecture components of an
Create Architecture Definition Document Draft Architecture Requirements Specification including: Architecture Roadmap
 Gap analysis results
 Relevant technical requirements
Business, Data, and Application Architecture components of
an Architecture Roadmap

653
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 11. Phase D: Technology Architecture

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap11.html
Practical Example – AS IS Technology Architecture
Practical Example – TO BE Technology Architecture
Workshop

Perform Gap Analysis for the

technology domain of your EA
project
Module 30
Phase D: Technology
Architecture – Catalogs,
Matrices and Diagrams
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 The Catalogs, Matrices and Diagrams of Phase D, Technology

Architecture

 What they consist of

 How they are used

659
TOGAF Standard, Version 9.2 Artifacts

660
Catalogs, Matrices and Diagrams

Catalogs Diagrams

 Technology Standards catalog  Environments and Locations

diagram
 Technology Portfolio catalog
 Platform Decomposition diagram

The exact format of the  Processing diagram

catalogs, matrices and
Matrices diagrams will depend on
the tools used  Networked Computing/Hardware
diagram
 Application/Technology matrix
 Network and Communications
diagram
661
Catalogs

Technology Standards catalog

Technology Portfolio catalog

662
Catalogs

Catalog Purpose
Technology This documents the agreed standards for technology across the enterprise covering
technologies, and versions, the technology lifecycles, and the refresh cycles for the
Standards
technology.
Catalog
It can be implemented as an extension to the Technology Portfolio Catalog and thus will
share the same metamodel entities:
•Technology Service, Logical Technology Component, Physical Technology Component
Technology This catalog identifies and lists all the technology in use across the enterprise, including
hardware, infrastructure software, and application software. An agreed technology portfolio
Portfolio
supports lifecycle management of technology products and versions and also forms the
Catalog basis for definition of technology standards
It contains the following metamodel entities:
•Technology Service, Logical Technology Component, Physical Technology Component
Matrices

Application/Technology matrix

664
Application/Technology Matrix

The Application/Technology matrix documents the mapping of applications

to the technology platform.

The Application/Technology matrix shows:

 Logical/Physical Application Components

 Services, Logical Technology Components, and Physical Technology

Components

 Physical Technology Component realizes Physical Application

Component relationships

665
Example Application/Technology Matrix

LOGICAL APPLICATION PHYSICAL TECHNOLOGY

SERVER ADDRESS IP ADDRESS
COMPONENT COMPONENT

ABM Web server - node 1 [email protected] 10.xx.xx.xx

Web server - node 2 [email protected] 10.xx.xx.xx
Web server - node 3 [email protected] 10.xx.xx.xx
App server – node 1 [email protected] 10.xx.xx.xx
App server – node 2 [email protected] 10.xx.xx.xx
App server – node 3 [email protected] 10.xx.xx.xx
Database server (production) [email protected] 10.xx.xx.xx

Database server (stating) [email protected] 10.xx.xx.xx

Load balancer and Dispatcher server [email protected] 242.xx.xx.xx
Dispatcher
Example Application/Technology Matrix

HARDWARE SOFTWARE
TECH FUNCTION HARDWARE LOGICAL SOFTWARE LOGICAL
PHYSICAL PHYSICAL

Load balancing Name – Balancer Model/Type – IBM P7xx Product- IBM Load SW Components –
Vendor - IBM Serial Number – balance manager LB v3.2 (list all the
Server Type – eServer 1S4568 Vendor - IBM other components of
Clustered – No Processor Type - RISC OS – UNIX the SW product)
No. of Nodes – N/A Power p5 AIX 10.2.1
Server logical address - Number of Processors - License Type -
[email protected] 8 way Enterprise wide
Maintenance Window – Memory - 1GB license
Sun 0100 to 0300 Hard drive - 40 GB License expiry date -
IP - 11.xx.xx.xx 12/31/2021
Example Application/Technology Matrix

APPLICATION COMPONENT DEPLOYMENT UNIT TECHNOLOGY COMPONENT

Load Balancer Smart dispatch v1.2 (both installation Load balancing server
and execution code) ([email protected])

Commerce pages HTML code Web Server cluster

Applets ([email protected],
JSP [email protected],
[email protected])

Commerce Engine •Order Entry (both installation and •Application Server

execution code) ([email protected],
•Shopping Cart (both installation and [email protected])
execution code)
Diagrams

Environments and Locations diagram

Platform Decomposition diagram

Processing diagram

Networked Computing/Hardware diagram

Network and Communications diagram

669
Environments and Locations Diagram

Depicts which locations host which applications

Identifies what technologies and/or applications are used at which locations

Identifies the locations from which business users typically interact with the
applications.

It should also show the existence and location of different deployment

environments
 including non-production environments, such as development and pre
production.

670
Example Environments and Locations Diagram

671
Platform Decomposition Diagram

Depicts the technology platform that supports the operations of the

Information Systems Architecture.

Covers all aspects of the infrastructure platform and provides an overview of

the enterprise's technology platform.

672
Example Platform Decomposition Diagram

Platform Decomposition (Application Support)

Hardware Software
Logical Technology Physical Technology
Logical Technology Physical Technology
Components Components
Components Components

Tech Function Tech Function Tech Function Tech Function

Web Server Web server layer

Layer Web Server Layer Web Server Layer

Application Layer Application Layer Application Layer Application Layer

Database Layer Database Layer Database Layer Database Layer

Attributes Attributes
• Name  Product Name
• Model/Type  Vendor
• Clusters  OS
• Number of Components  SW components
• Vendor  License Type
• Server Type (mainframe, Mid range, RISC, Intel)  License Expiry etc
• Server logical name
• IP Address etc

673
Processing Diagram

Focuses on deployable units of code/configuration and how these are

deployed onto the technology platform.

Addresses the following:

 Which set of application components need to be grouped to form a
deployment unit
 How one deployment unit connects/interacts with another (LAN, WAN,
and the applicable protocols)
 How application configuration and usage patterns generate load or
capacity requirements for different technology components

The organization and grouping of deployment units depends on separation

concerns of the presentation, business logic, and data store layers and
service-level requirements of the components.

674
Example Processing Diagram

Open DMZ Internet Zone Intranet Zone

Internet

File Explorer, HTML, Images

(DFS Distributed File System
Server)

Order capture
(DB server)

HTML Code (Web Order Entry &

Load server cluster with Shopping
Balancer 2 nodes) Cart
Code (Application Server
cluster with 2 nodes) App
Messaging Server DB
Server

Over LAN
HTTP

Firewall Firewall Firewall

675
Network Computing Hardware Diagram

This diagram shows the "as deployed" logical view of logical application
components in a distributed network computing environment.

The diagram is useful for the following reasons:

 Enable understanding of which application is deployed where
 Establishing authorization, security, and access to these technology
components
 Understand the Technology Architecture that support the applications
during problem resolution and troubleshooting
 Isolate performance problems encountered and perform necessary
upgrade to specific physical technology components
 Identify areas of optimization
 Enable application/technology auditing and prove compliance
 Serve as an important tool supporting effective change management
676
Example Network Computing Hardware Diagram
DMZ Internet Zone Intranet Zone

Application
Web Server cluster
Load server Application
(node 3)
Web Database Database
Balancer cluster Server cluster
server (ABM (ABM
and (node 3)
App Server Staging)
cluster Production)
Dispatcher cluster - node 3
Web (ABM)
server
cluster-
node 3 DFS Distributed File
(ABM) System (html,
images)

Load Web server Database

cluster Application App
Balancer DB
Server (Order Server
and Web server Engine)
Dispatcher cluster-node 2
(eCommerce)

App Server

Firewall Firewall Firewall

677
Network and Communications Diagram

The Network and Communications diagram describes the means of

communication between assets in the Technology Architecture

It takes logical connections between client and server components and

identifies network boundaries and network infrastructure required to
physically implement those connections.

It does not describe the information format or content, but addresses

protocol and capacity issues.

678
Network and Communications Diagram

DMZ KEY
Client
Server
Port xxx Port xxx PC
Opened on Opened on
Networ
Internet Firewall Firewall Network
k Area
Mobile
Device
Data
Store
OBMG OBMG
GPRS Proprietary Proprietary User Network Linking
(OBMG / Encrypted) Protocol Protocol Firewall
Device
(Encrypted) (Encrypted)

Mobile Device
OBMG

Prop col
DMZ Proxy

OBM ry
(Enc
Proto ted)
rieta
ryp

G
LAN
MS Exchange
Mail Synch Protocol

MG
OB ietary
pr l Au
Pro otoco d) th c ol
Pr ypte OBMG Pr o to Microsoft
cr o Pr
(En to
Server c ol Au
th Exchange
Cradle / USB
Cable

Mobile Device Desktop PC

(OBMG Desktop Proxy)
Active Directory

679
Module 31
TOGAF® Foundation
Architecture: the TRM
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Roadmap
Module Objectives

To understand the TOGAF Technical Reference Model.

The TOGAF Technical Reference Model (TRM) is an example of a

Foundation Architecture.

The Purpose, Structure and Use of the TRM

The Platform Services Taxonomy

Application Platform Service Qualities

682
Foundation Architectures

A Foundation Architecture is an architecture of building blocks and

corresponding standards that supports all the Common Systems
Architectures and, therefore, the complete enterprise operating environment

The TOGAF Library includes the TOGAF TRM as an example Foundation

Architecture

The ADM supports specialization of such Foundation Architectures in order

to create organization-specific models.

683
TRM Components

The TRM has two main components:

 A taxonomy which defines terminology and description of the
components and conceptual structure of an information system

 An associated TRM graphic that provide a visual representation

684
The TRM

Application Portability is achieved via the

Application Platform Interface, identifying the
set of services that are to be made available in
a standard way to applications via the
platform

Interoperability is achieved via the

Communications Infrastructure Interface,
identifying the set of Communications
Infrastructure services that are to be built on
in a standard way
 Infrastructure Applications, provide Business Applications, implement
The API specifies
The Application Platform is the the interface between
The TRM has two categories of
general purpose functionality, usually business processes and are enterprise
Application
conceptual entity containing Software and the underlying Application Software
COTS or vertical specific
Operating System Services, Network platform
Services and a generic set of Platform
Services
Qualities are the set of attributes
applying across all components

The Communications Infrastructure

Interface is the interface between the
Application Platform and the
Communications Infrastructure
Typical Qualities are manageability
and security. Some qualities can be
specified better in terms of measures
rather than standards, e.g.
performance
The Communications Infrastructure contains basic
services to interconnect systems and provide for data
transfer. It handles the physical communications
infrastructure. Slide 686
Taxonomy of Platform Services

Not exclusive or optimal definition

The TOGAF ADM is not dependent on the TRM

689
Summary

The TOGAF Technical Reference

Model provides a model and core
taxonomy of generic platform-centric
services

It can be used to build any system

architecture

A taxonomy defines consistent

terminology
Test Yourself Question

Q. Which of the following best describes the purpose of the TRM?

A. To provide a framework for IT Governance

B. To provide a visual model, terminology and coherent description of
components and structure of an information system
C. To provide a list of standards
D. To provide a method for architecture development
E. To provide a system engineering viewpoint on a possible solution

693
Test Yourself Question

Q. Which of the following statements about the Taxonomy of Platform

Services is true?

A. It provides a description of a specific vertical industry information system

B. It defines a number of service qualities
C. It provides a widely accepted, useful definition of an Application Platform
entity
D. It is used in structuring the III-RM
E. It provides a list of standards

694
Module 32
Phase E:
Opportunities and
Solutions V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase E:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

696
Phase E Objectives

Generate the initial complete version of the Architecture Roadmap

Determine whether an incremental approach is required

 If so, identify Transition Architectures

Define the overall SBBs

697
Approach

Key concepts for transitioning from developing to delivering a Target

Architecture:

 Architecture Roadmap:lists individual work packages in a timeline that

will realize the Target Architecture

 Work Packages: logical group of changes necessary to realize the

Target Architecture

 Transition Architectures: describes the enterprise at an architecturally

significant state between the Baseline and Target Architectures

 Implementation and Migration Plan: provides a schedule of the

projects that will realize the Target Architecture

698
Phase E: Inputs

 Product Information
 Request for Architecture Work
 Capability Assessment
 Communications Plan
 Planning Methodologies
 Governance models and
frameworks
 Tailored Architecture Framework

Continued
Phase E: Inputs

 Statement of Architecture Work

 Architecture Vision
 Architecture Repository
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Change Requests for existing
programs and projects
 Candidate Architecture
Roadmap components from
Phases B,C, and D
Steps
11. Create Architecture Roadmap &
Implementation and Migration Plan
10. Identify Transition Architectures

9. Identify and group major work packages

8. Formulate Implementation & Migration Strategy

7. Confirm readiness and risk for business transformation

6. Refine and validate dependencies

5. Consolidate and reconcile interoperability requirements

4. Review consolidated requirements across related business functions

3. Review and consolidate gap analysis results from Phases B to D

2. Determine business constraints for implementation

1. Determine corporate change attributes

Step 1: Determine Corporate Change Attributes

Create an Implementation Factor Assessment and Deduction Matrix

Assess Transition Capabilities of Corporate and Partner Organizations

Assess Transition Capabilities of the Enterprise and IT Organization

702
Step 2: Determine Business Constraints for
Implementation

Identify any business drivers that would constrain the sequence of

implementation, this requires review of:

 Corporate Strategic Plan

 Corporate Line-of-Business Strategic Plans

 The EA Maturity Assessment

703
Step 3: Review and Consolidate Gap Analysis Results
from Phases B to D

Create a Consolidated Gaps, Solutions, and Dependencies Matrix

Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix

More factors may be added to the Implementation Factor Assessment and

Deduction Matrix

704
Step 4: Review Consolidated Requirements Across
Related Business Functions

Assess the requirements, gaps, solutions and factors to identify a minimal

set of requirements for work packages

This functional perspective leads to the satisfaction of multiple requirements

through the provision of shared solutions and services

705
Step 5: Consolidate and Reconcile Interoperability
Requirements

Consolidate Interoperability Requirements identified in previous phases

Identify any constraints on Interoperability required by the potential set of

solutions

Two approaches to resolve Interoperability conflicts

 Create a building block that transforms or translates between conflicting

building blocks

 Make a change to the specification of the conflicting building blocks.

706
Step 6: Refine and Validate Dependencies

Identify constraints based on dependencies

Dependencies must be used to identify

 Sequence of implementation

 Logical increments of deliverables

 Transition Architectures

707
Step 7: Confirm Readiness and Risk for Business
Transformation

Review the Business Transformation Readiness Assessment previously

conducted in Phase A

Determine the impact on the Architecture Roadmap and the Implementation

and Migration Strategy

Identify, classify, and mitigate associated risks

Document risks documented in the Consolidated Gaps, Solutions, and

Dependencies matrix

708
Step 8: Formulate Implementation and Migration
Strategy

Determine an overall strategic approach

 Greenfield
 Revolutionary
 Evolutionary

Determine an Implementation Approach

 Quick win (snapshots)
 Achievable targets
 Value chain method (e.g. NASCIO methodology)

These approaches and identified dependencies are the basis of work

packages

709
Step 9: Identify and Group Major Work Packages

Group activities into work packages

Fill in the "Solution" column in the Consolidated Gaps, Solutions, and

Dependencies matrix

Perform Make/Buy/Reuse analysis for solutions

Classify system
 Mainstream Systems
 Contain Systems
 Replace Systems

Group Work Packages into portfolios and projects

710
Step 10: Identify Transition Architectures

The Transition Architectures should provide measurable business value

The time-span between successive Transition Architectures does not have

to be of uniform duration

711
Step 11:Create the Architecture Roadmap &
Implementation and Migration Plan

Consolidate the work packages and Transition Architectures into the

Architecture Roadmap, Version 0.1

The Implementation and Migration Plan, Version 0.1 must be aligned to the
Architecture Roadmap

Update the Architecture Vision, Architecture Definition Document, and

Architecture Requirements Specification, if necessary

712
Phase E Outputs

 Statement of Architecture Work

 Architecture Vision
 Draft Architecture Definition
Document, including:
• Transition Architectures, if any
 Draft Architecture Requirements
Specification, including
• Consolidated Gaps, Solutions and
Dependencies Assessment

Continued
Phase E Outputs

 Capability Assessment,
including:
• Business Capability Assessment
• IT Capability Assessment
 Architecture Roadmap,
including:
• Work Package portfolio
• Identification of Transition
Architectures, if any
• Implementation Recommendations
 Implementation & Migration Plan
(outline)
Summary

Phase E is the first phase concerned

with implementation

It identifies the parameters of

change, the phases and necessary
projects

The output forms the basis of the

Implementation Plan
 Summary
Phase E: Opportunities & Solutions
Objectives Steps Inputs Outputs
Generate the initial complete version Determine/confirm key corporate change Product information Statement of Architecture Work, updated if necessary
of the Architecture Roadmap, based attributes
upon the gap analysis and candidate Request for Architecture Work Architecture Vision, updated if necessary
Architecture Roadmap components Determine business constraints for
from Phases B, C, and D implementation Capability Assessment Draft Architecture Definition Document, including:
 Transition Architecture, number and scope, if any
Determine whether an incremental Review and consolidate gap analysis Communications Plan
approach is required, and if so identify results from Phases B to D Draft Architecture Requirements Specification, updated if
Transition Architectures that will Planning methodologies necessary
deliver continuous business value Review consolidated requirements across
related business functions Organizational model for Enterprise Architecture Consolidated and validated Architecture Roadmap
Define the overall solution building
blocks to finalize the Target Consolidate and reconcile interoperability Governance models and frameworks Capability Assessment, including:
Architecture based on the Architecture requirements  Business Capability
Building Blocks (ABBs) Tailored Architecture Framework  IT Capability
Refine and validate dependencies
Statement of Architecture Work Architecture Roadmap, including:
Confirm readiness and risk for business  Work Package portfolio
transformation Architecture Vision  Identification of Transition Architectures, if any
 Impact analysis – project list
Formulate Implementation and Migration Architecture Repository  Implementation Recommendations
Strategy
Draft Architecture Definition Document Implementation and Migration Plan (outline), including:
Identify and group major work packages  Implementation and Migration Strategy
Draft Architecture Requirements Specification
Identify Transition Architectures
Change Requests for existing programs and
Create Architecture Roadmap & projects
Implementation and Migration Plan
Candidate Architecture Roadmap components
from Phases B, C, and D
716
TOGAF Standard, Version 9.2 Artifacts

717
Project Context Diagram

718
Project Context Diagram

719
Benefits Diagram

720
Benefits Diagram

721
Test Yourself Question

Q. Which of the following is the most successful strategy for Phase E?

A. Focus on the application systems that are relevant to the enterprise

B. Focus on projects that will deliver short-term payoffs
C. Focus on top-down development
D. Reverse engineering
E. Trial and error

722
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 12. Phase E: Opportunities & Solutions

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap12.html
Practical Example – Transition Architectures
Module 33
Phase F:
Migration Planning V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase F:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

726
Phase F Objectives

Finalize the Architecture Roadmap

Finalize the Implementation and Migration Plan

Align the Implementation and Migration Plan with the enterprise's

management approach

Ensure that the business value and cost of work packages and Transition
Architectures is understood by key stakeholders

727
Approach

The focus is finalization of the Implementation and Migration plan initially

prepared in Phase E

Activities include the dependencies, costs, and benefits of the various

migration projects

728
Phase F: Inputs

 Request for Architecture Work

 Capability Assessment
 Communications Plan
 Organizational model for
Enterprise Architecture
 Governance Models and
Frameworks
 Tailored Architecture Framework
 Statement of Architecture Work
 Architecture Vision
 Architecture Repository
Continued
Phase F: Inputs

 Draft Architecture Definition

Document, including:
• Transition Architectures, if any
 Draft Architecture Requirements
Specification
 Change Requests for existing
programs and projects
 Architecture Roadmap, including:
• Identification of work packages
• Identification of Transition Architectures
• Implementation Factor Assessment and
Deduction Matrix
 Capability Assessment
 Implementation and Migration Plan
(outline) Continued
Steps

7. Complete the architecture development cycle

and document lessons learned

6. Complete the Implementation & Migration Plan

5. Confirm Architecture Roadmap and Architecture Definition

Document
4. Prioritize migration projects through the conduct of a
cost/benefit assessment and risk validation
3. Estimate resource requirements, project timings, and
availability/delivery vehicle

2. Assign a business value to each work package

1. Confirm management framework interactions for the Implementation &

Migration Plan
Step 1:Confirm Management Framework Interactions
for the Implementation and Migration Plan

Align the Implementation and Migration Plan with the used management
frameworks
 Business Planning
 Enterprise Architecture
 Portfolio/Project Management
 Operations Management

The Implementation and Migration Plan could be part of a different plan

produced by another framework

732
Step 2: Assign a Business Value to Each Work
Package

Define business values and how to measure them

Assign and apply business values to each

 Work package
 Project
 Project increment
 Deliverable

Assign risks to projects

Estimate the business value for each project using the Business Value
Assessment Technique

733
Step 3: Estimate Resource Requirements, Project
Timings, and Availability/Delivery Vehicle

Determine costs to:

 Create the capability
 Run and sustain the capability

Identify opportunities to offset costs by decommissioning existing systems

Assign resources to each activity

Aggregate resources at the project increment and project level

734
Step 4: Prioritize the Migration Projects through the Conduct of a
Cost/Benefit Assessment and Risk Validation

Prioritize the projects according to cost/benefit analysis

Determine the net benefit of all of the delivered SBBs

Verify effective risk mitigation

Allocate resources to the projects based on priorities

735
Step 5:Confirm Architecture Roadmap and Update
Architecture Definition Document

Update the Architecture Roadmap with Transition Architectures

 Identify time-spans between Transition Architecture

 Consolidate the deliverables by project.

 A Transition Architecture State Evolution Table can be used to show the

proposed state of the domain architectures

Update the Architecture Definition Document according to implementation

approach and implementation increments shifts

736
Step 6: Generate the Implementation & Migration Plan

Integrate all of the projects, activities, dependencies and impact of change

into the Implementation and Migration Plan

Any Transition Architectures will act as portfolio milestones

Assess the overall availability of resources

737
Step 7: Complete the Architecture Development Cycle
and Document Lessons Learned

This step transitions governance from the development to the realization of

the architecture

Lessons learned during the development of the architecture are important

for governance

738
Phase F Outputs

 Implementation and Migration Plan

(detailed)
 Finalized Architecture Definition
Document, including:
• Finalized Transition Architectures, if any
 Finalized Architecture
Requirements Specification
 Finalized Architecture Roadmap
 Re-Usable ABBs
 Requests for Architecture Work for
a new iteration of the ADM (if any)
 Implementation Governance Model
 Change Requests
Summary

Phase F addresses migration

planning – how to move from the
Baseline to the Target

It includes creating the finalized

Architecture Definition Document,
Architecture Roadmap and the
detailed Implementation & Migration
Plan

At the completion of this phase the

preparation for implementation has
been completed
 Summary
Phase F: Migration Planning
Objectives Steps Inputs Outputs
Finalize the Architecture Roadmap Confirm management framework Request for Architecture Work Implementation and Migration Plan (detailed),
and the supporting Implementation interactions for Implementation and Communications Plan including:
and Migration Plan Migration Plan Organizational Model for Enterprise Architecture  Implementation and Migration Strategy
Governance models and frameworks  Project and portfolio breakdown of the
Ensure that the Implementation and Assign a business value to each work Tailored Architecture Framework implementation
Migration Plan is coordinated with the package Statement of Architecture Work  Project charters (optional)
enterprise's approach to managing Architecture Vision
and implementing change in the Estimate resource requirements, project Architecture Repository Finalized Architecture Definition Document,
enterprise's overall change portfolio timings, and availability/delivery vehicle including:
Draft Architecture Definition Document, including:  Finalized Transition Architectures, if any
Ensure that the business value and Prioritize the migration projects through  Transition Architectures, if any
cost of work packages and Transition the conduct of a cost/benefit assessment Finalized Architecture Requirements
Architectures is understood by key and risk validation Draft Architecture Requirements Specification Specification
stakeholders Change Requests for existing programs and projects
Confirm Architecture Roadmap and Finalized Architecture Roadmap
update Architecture Definition Document Architecture Roadmap
Re-usable Architecture Building Blocks
Complete the Implementation Roadmap Capability Assessment, including:
and Migration Plan  Business Capability Requests for Architecture Work for a new
 IT Capability iteration of the ADM cycle (if any)
Complete the architecture development
cycle and document lessons learned Implementation and Migration Plan (outline), including: Implementation Governance Model
 High-level Implementation and Migration Strategy
Change Requests for the Architecture
Capability arising from lessons learned

741
Test Yourself Question

Q. When preparing the detailed Migration Plan, which of the following should
not be a consideration?

A. Risk Assessment
B. Project Priorities
C. Availability of Resources
D. Cost/benefit assessment
E. Choice of target platform

742
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 13. Phase F: Migration Planning

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap13.html
Practical Example – Migration Plan
Workshop

Define the transition architectures of

your EA project
Module 34
Migration Planning
Techniques
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

Understand the techniques used in Phases E and F

Key areas include:

 Implementation Factor Assessment and Deduction Matrix

 Consolidated Gaps, Solutions and Dependencies Matrix

 Architecture Definition Increments table

 Enterprise Architecture State Evolution Table

 Business Value Assessment Technique

747
The Implementation Factor Assessment and
Deduction Matrix

Documents the factors impacting the Implementation and Migration Plan

Factors include:
 Risks
 Issues
 Assumptions
 Dependencies
 Actions
 Impacts

748
The Implementation Factor Assessment and
Deduction Matrix

Created in Step 1 of Phase E and updated throughout Phase E

Input to Phase F

Repository for architecture implementation and migration decisions

Includes:

 a list of the factors to be considered

 their descriptions, and

 the deductions that indicate the actions or constraints that have to be

taken into consideration when formulating the plans

749
Example – Implementation Factor Assessment and
Deduction Matrix
The Consolidated Gaps, Solutions and Dependencies
Matrix

Used when consolidating the gap analysis results from Phases B to D

Used to assess potential solutions and dependencies to one or more gaps

First created in Step 3 of Phase E

Input to Phase F

Used as a planning tool when creating work packages

Will drive the creation of projects and migration planning in Phases E and F

751
Example – Consolidated Gaps, Solutions and
Dependencies Matrix
Architecture Definition Increments table

Allows to plan a series of Transition Architectures outlining the status of the

EA at specified times

It is created in Phase F

Lists the projects and their incremental deliverables across the Transition
Architectures

753
Architecture Definition Increments table
The Transition Architecture State Evolution Table

Shows the proposed state of the architectures at various levels using the
defined taxonomy (e.g. TRM)

Drawn up in Phase F

All SBBs should be described with respect to their delivery and impact on
services

755
The Transition Architecture State Evolution Table
The Business Value Assessment Technique

Assess business value considering risk

Used in Phase F

Should include criteria

The risk index should include criteria

757
The Business Value Assessment Technique
Summary

This module has explained the techniques used in Phase E and F for
migration planning. In particular, it has discussed:

2 matrices (the Implementation Factor Assessment and Deduction Matrix

and the Consolidated Gaps, Solutions and Dependencies Matrix).

2 tables (the Architecture Definition Increments table and the Enterprise

Architecture State Evolution Table).

1 technique (the Business Value Assessment Technique)

759
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 24. Migration Planning Techniques

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap24.html
Workshop

List the required projects to

implement the vision of your EA
project and prioritize them
Module 35
Capability Based Planning
(technique) V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 What is capability and what is capability based planning

 How to apply capability based planning in the ADM

 The relationship between capability based planning, EA and

Project/Portfolio Management

763
Capability based planning

Capability-based planning is a technique that focuses on the planning,

engineering and delivery of strategic business capabilities

It frames all phases of the architecture development in the context of

business outcomes, clearly linking the IT vision, architectures (ABBs and
SBBs), and the Implementation and Migration Plans with the corporate
strategic, business, and line of business plans.

764
Capabilities

765
Capability based planning

Capabilities are directly derived from the corporate strategic plan to satisfy
the enterprise goals, objectives, and strategies

Architectures are expressed in terms of business outcomes and value.

Phase A: EA is driven by corporate strategic direction

Phases B, C, and D: specific capabilities are targeted

Phase E: EA is increments of capabilities

766
Capability based planning, EA and Project/Portfolio
Management

767
Summary

The enterprise has a set of capabilities

In capability based planning, each transition architecture implements group

of capabilities crossing all BDAT domains, instead of implementing domains
or functions

Project portfolios and projects are centered about capabilities, instead of

domains or functions
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 28. Capability-Based Planning

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap28.html
Practical Example – Capability Based Planning
Practical Example –
Capability Based Architecture Definition
Workshop

List the capabilities to be

implemented in each transition
architecture of your EA project
Module 36
Phase G:
Implementation
Governance V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase G:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

774
Phase G Objectives

Ensure conformance with the Target Architecture by implementation projects

Perform appropriate Architecture Governance functions for the solution and

any implementation-driven architecture Change Requests

775
Approach

Establish Architecture Contract

The development happens in parallel with Phase G

Adopt a phased deployment schedule that reflects the business priorities embodied
in the Architecture Roadmap

Follow the organization's standard for governance

Use the organization's established portfolio/program management approach, where

this exists

Define an operations framework to ensure the effective long life of the deployed
solution

776
Phase G: Inputs

 Request for Architecture Work

 Capability Assessment
 Organizational model for EA
 Tailored Architecture Framework
 Statement of Architecture Work
 Architecture Vision
 Architecture Repository
 Architecture Definition
Document

Continued
Phase G: Inputs

 Architecture Requirements
Specification
 Architecture Roadmap
 Implementation Governance
Model
 Architecture Contract
 Request for Architecture Work
from E and F
 Implementation and Migration
Plan
Steps

6. Do post-implementation review, close the

implementation
5. Implement business and IT operations

4. Perform EA compliance reviews

3. Guide development of solutions deployment

2. Identify deployment resources and skills

1. Confirm scope and priorities for deployment with the development
management
Step 1: Confirm scope and priorities

Review migration planning outputs and produce recommendations on

deployment

Identify Enterprise Architecture priorities for development teams

Identify deployment issues and make recommendations

Identify building blocks for replacement, update, etc.

Perform gap analysis on Enterprise Architecture and solutions framework

Produce a gap analysis report

780
Step 2: Identify deployment resources and skills

Identify system development methods required for solutions development

Ensure that the systems development method enables feedback to the

architecture team on designs

781
Step 3: Guide development of solutions deployment

Document Architecture Contract

Update Enterprise Continuum with solutions

Guide development of business & IT operating models

Provide service requirements derived from EA

Identify gaps between Solution Architecture and operations

Produce Implementation Plan

782
Step 4: Perform EA compliance reviews

Review ongoing implementation governance and architecture compliance

for each BB

Conduct post-development reviews

Close development part of deployment projects

783
Step 5: Implement business and IT operations

Operate according to the new EA

Publish new Baseline Architectures in the Architecture Repository

 Update other repositories, such as operational configuration

management stores

784
Step 6: Do post-implementation review, close the
implementation

Conduct post-implementation reviews

Publish reviews and close projects

785
Phase G Outputs

 Architecture Contract (signed)

 Compliance Assessments
 Change Requests
 Architecture-compliant solutions
deployed, including:
• Implemented system
• Performance metrics
• SLAs
• Transition Architecture
• Business and IT operating models
Summary

Phase G defines architecture

constraints on the implementation
projects and constructs and obtains
signatures on an Architecture
Contract

The contract and documentation is

delivered to the implementation
team

The phase includes governing the

architecture through implementation
by compliance reviews and by risk
monitoring
 Summary
Phase G: Implementation Governance
Objectives Steps Inputs Outputs
Ensure conformance with the Confirm scope and priorities for Request for Architecture Work Architecture Contract (signed)
Target Architecture by deployment with development
implementation projects management Capability Assessment Compliance Assessments

Perform appropriate Identify deployment resources Organizational Model for Enterprise Architecture Change Requests
Architecture Governance and skills
functions for the solution and Tailored Architecture Framework Architecture-compliant solutions deployed, including:
any implementation-driven Guide development of solutions  The architecture-compliant implemented system
architecture Change Requests deployment Statement of Architecture Work  Populated Architecture Repository
 Architecture compliance recommendations and
Perform Enterprise Architecture Architecture Vision dispensations
compliance reviews  Recommendations on service delivery requirements
Architecture Repository  Recommendations on performance metrics
Implement business and IT  Service Level Agreements (SLAs)
operations Architecture Definition Document  Architecture Vision, updated post-implementation
 Architecture Definition Document, updated post-
Perform post-implementation Architecture Requirements Specification implementation
review and close the  Business and IT operating models for the implemented
implementation Architecture Roadmap solution

Implementation Governance Model

Architecture Contract

Request for Architecture Work identified in Phases E and F

Implementation and Migration Plan

788
Test Yourself Question

Q. Which one of the following provides a foundation for governing the

implementation of the recommended projects?

A. Impact Analysis
B. Principles
C. Strategic Plan
D. Architecture Contracts
E. Risk Assessment

789
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 14. Phase G: Implementation Governance

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap14.html
Workshop

Update the previously defined

governance board to govern the
implementation of your EA project
Module 37
Phase H:
Architecture Change
Management V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Phase H:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

793
Phase H Objectives

Ensure that the architecture lifecycle is maintained

Ensure that the Architecture Governance Framework is executed

Ensure that the enterprise Architecture Capability meets current

requirements

794
Approach
Change Management Process

There are three main categories of architecture change:

 Simplification: this can be handled via change management

techniques.

 Incremental: this may be handled via change management techniques,

or it may require partial re-architecting.

 Re-architecting: this requires putting the whole architecture through the

architecture development cycle again.

796
Change Management Process

To determine whether a change is simplification, incremental, or re-

architecting:

 Register all events that may impact the architecture

 Allocate resources and management

 Assess what should be done

 Evaluate the impact

797
Maintenance versus Redesign

If the change:

 Impacts 2 stakeholders or more, then it is likely to require an

architecture redesign and re-entry to the ADM (e.g. change related to
business strategy)

 Impacts only 1 stakeholder, then it is likely to be a candidate for change

management (e.g. new technology will change only technology
architecture)

 Can be allowed under a dispensation, then it is likely to be a candidate

for change management (e.g. many systems merged in one system)

798
Phase H: Inputs

 Request for Architecture Work

 Organizational model for EA
 Tailored Architecture Framework
 Statement of Architecture Work
 Architecture Vision
 Architecture Repository
 Architecture Definition document
 Architecture Requirements
Specification

Continued
Phase H: Inputs

 Architecture Roadmap
 Change Requests (due to
technology changes, business
changes, lessons learned)
 Implementation Governance
Model
 Architecture Contract
 Compliance Assessments
 Implementation and Migration
Plan

Continued
Chang Request Contents

Description of the proposed change

Rationale for the proposed change

Impact assessment of the proposed change, including:

Repository reference number

801
Steps

7. Activate the process to implement

Change
6. Manage Governance Process
5. Develop Change Requirements to meet
Performance Targets
4. Provide Analysis for Architecture Change Management

3. Manage Risks

2. Deploy Monitoring Tools

1. Establish Value Realization process

Step 1. Establish Value Realization Process

Influence business projects to exploit the Enterprise Architecture for value

realization (outcomes)

803
Step 2. Deploy Monitoring Tools

Monitor technology changes

Monitor business changes

Business value tracking

Monitor EA Capability maturity

Track and assess asset management programs

Track the QoS performances and usage

Determine and track business continuity requirements

804
Step 3. Manage Risks

Manage Enterprise Architecture risks and provide recommendations

805
Step 4. Provide Analysis for Architecture Change
Management

Analyze performance

Conduct EA performance reviews

Ensure that the expected value realization and SLA are met

Undertake a gap analysis of the performance of the Enterprise Architecture

Ensure change requests adhere to the EA governance and framework

806
Step 5. Develop Change Requirements to Meet
Performance Targets

Make recommendations on change requirements to

 Meet performance requirements

 Develop a position to act

807
Step 6. Manage Governance Process

Arrange meeting of Architecture Board

Hold meeting of the Architecture Board to decide on handling changes

808
Step 7. Activate the Process to Implement Change

Produce a new Request for Architecture Work and request for investment

Ensure any changes implemented in this phase are captured and

documented in the Architecture Repository

809
Phase H Outputs

 Architecture updates
 Changes to architecture
framework and principles
 New Request for Architecture
Work, to initiate another cycle of
the ADM
 Statement of Architecture Work,
updated if necessary
 Architecture Contract, updated if
necessary
 Compliance Assessments,
updated if necessary
Business Users’ Architecture Contract

 Introduction and background

 The nature of the agreement
 Scope
 Strategic requirements
 Conformance requirements
 Architecture adopters
 Time window
 Architecture business metrics
 Service architecture (includes Service Level Agreement (SLA))

811
Request for Architecture Work

 Organization sponsors  External constraints, business

 Organization's mission constraints
statement  Current business system
 Business goals (and changes) description
 Strategic plans of the business  Current architecture/IT system
 Time limits description
 Changes in the business  Description of developing
environment organization
 Organizational constraints  Description of resources
available to developing
 Budget information, financial organization
constraints

812
Summary

Preliminary
Phase H Change Management

A.
 Ensures that changes to the
Architecture

H.
Vision
B.
architecture are managed in a
Architecture
Change
Management
Business
Architecture cohesive and controlled manner

C.
G. Requirements Information
Implementation Management Systems
Governance Architectures
 Establishes and supports the
architecture to provide flexibility
F.
Migration
D.
Technology
to evolve the architecture rapidly
Planning Architecture
E.
Opportunities
in responses to changes in
and
Solutions
© The Open Group
technology and business
 Summary
Phase H: Architecture Change Management
Objectives Steps Inputs Outputs
Ensure that the architecture Establish value realization process Request for Architecture Work Architecture updates
lifecycle is maintained
Deploy monitoring tools Organizational Model for Enterprise Architecture Changes to architecture framework and
Ensure that the Architecture principles
Governance Framework is Manage risks Tailored Architecture Framework
executed New Request for Architecture Work, to initiate
Provide analysis for architecture change Statement of Architecture Work another cycle of the ADM
Ensure that the Enterprise management
Architecture Capability meets Architecture Vision Statement of Architecture Work, updated if
current requirements Develop change requirements to meet necessary
performance targets Architecture Repository
Architecture Contract, updated if necessary
Manage governance process Architecture Definition Document
Compliance Assessments, updated if
Activate the process to implement change Architecture Requirements Specification necessary

Architecture Roadmap

Change Requests due to technology changes

Change Requests due to business changes

Change Requests from lessons learned

Implementation Governance Model

Architecture Contract (signed)

Compliance Assessments

Implementation and Migration Plan

814
Test Yourself Question

Q. Which of the following is part of an architecture change management

process?

A. Ensuring that business continues as usual

B. Determining whether a change warrants an update to the architecture
C. Determining whether a change requires a new cycle of the ADM
D. Managing change properly
E. Establishing criteria for judging change requests

815
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 15. Phase H: Architecture Change Management

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap15.html
Module 38
ADM Architecture
Requirements
Management Phase
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand the Requirement

Management Phase:

 Objectives

 Approach

 Steps

 Inputs

 Outputs

818
ADM Requirements Management

The process of managing

architecture requirements:

 Applies to all phases of the ADM

cycle

 Is central to the ADM process

 Is a dynamic process addressing

the identification of
requirements, their storage and
delivery to the phases

819
Requirements Management Phase Objectives

Ensure that the Requirements Management process is sustained and

operates for all relevant ADM phases

Manage architecture requirements

Ensure that the requirements are available for use

820
Approach

Architecture bridges the divide between the aspirations of the stakeholders

and a practical solution

The Requirements Management process does not dispose of, address or

prioritize requirements;

 this is done within the phases of the ADM

Use a Requirements Repository

821
Requirements Development

High level requirements are developed in Phase A

For each ADM phase, from Preliminary to Phase H

 Select the approved requirements for that phase
 At the completion of a phase, update the requirements status

During phase execution

 New requirements generated for future architecture work within the
scope of the current Statement of Architecture Work need to be
documented within the Architecture Requirements Specification
 New requirements which are outside of the scope of the current
Statement of Architecture Work must be input to the Requirements
Repository for management through the Requirements Management
process

822
Resources

TOGAF specifies generic needs for requirements, not specific tools or

processes

It recommends use of

 Business Scenarios

 Commercial off the shelf tools

823
Volère Requirements Specification Template

The “Waiting Room”

A repository for requirements that are beyond the planned scope, or the time
available, for the current iteration.

Store future requirements to avoid the perception of discarding them

824
Requirements Management: Inputs

 Requirements-related outputs
from each ADM phase

 The first high-level requirements

are produced as part of the
Architecture Vision

 Each architecture domain then

generates detailed requirements

 Deliverables in later ADM

phases contain mappings to new
types of requirements

825
Steps Overview

Requirements Management Steps ADM Phase Steps

1. Identify/document requirements
2. Baseline requirements
3. Monitor baseline requirements 4. Identify changed requirement

5. Identify changed requirement 6. Assess impact of change

and record priorities 7. Implement changes arising from
Phase H
8. Update the Architecture
Requirements Repository with 9. Implement change in the current
information relating to the phase
changes requested, including 10. Assess and revise gap analysis
stakeholder views affected for past phases

826
Steps in Detail

1. Identify/document requirements (ADM Phase Step)

 Use Business Scenarios or an equivalent technique

2. Baseline requirements (Requirements Management Step)

 Determine priorities arising from current phase of ADM
 Confirm stakeholder buy-in to resultant priorities
 Record requirements priorities and place in Requirements Repository.

3. Monitor baseline requirements (Requirements Management Step)

827
Steps in Detail

4. Identify changed requirement (ADM Phase Step)

 Remove or re-assess priorities
 Add requirements and re-assess priorities
 Modify existing requirements

5. Identify changed requirements and record priorities (Requirements

Management Step)
 Identify changed requirements
 Record new priorities
 Resolve conflicts
 Generate Requirements Impact Statement

828
Steps in Detail

6. Assess impact of changed requirements on current and previous phases

 Decide whether to implement the change of defer it to a future ADM
cycle
 Issue new version of Requirements Impact Statement

7. Implement requirements arising from Phase H (ADM Phase Step)

829
Steps in Detail

8. Update the Architecture Requirements Repository with information

relating to the changes requested, including stakeholder views affected
(Requirements Management Step)

9. Implement change in the current phase (ADM Phase Step)

10. Assess and revise gap analysis for past phases (ADM Phase Step)

 Gap analysis may generate some requirements

830
Requirements Management: Outputs

 Updated Architecture
Requirements Specification

 Requirements Impact Statement

831
Requirements Impact Assessment

When new requirements arise, or existing ones are changed, a

Requirements Impact Statement is generated

It identifies the phases of the ADM that need to be revisited to address the
changes

The impact assessment covers costs, timescales, and business metrics

Architecture Requirements Specification should be updated after finalizing

the requirements of each ADM cycley

832
Summary

Requirements Management is an
ongoing activity of the ADM.

The Requirements Repository

contains the current requirements for
the Target Architecture.

When new requirements arise, or

existing ones are changed, a
Requirements Impact Statement is
generated that identifies the phase
of the ADM to be revisited. This goes
through various iterations until a final
version is produced.

833
 Summary
Requirements Management
Objectives Steps Inputs Outputs
Ensure that the Requirements Management Identify/document requirements The inputs to the Requirements Management Changed requirements
process is sustained and operates for all process are the requirements-related outputs
relevant ADM phases Baseline requirements from each ADM phase. Requirements Impact Assessment, which
identifies the phases of the ADM that need to
Manage architecture requirements identified Monitor baseline requirements The first high-level requirements are produced be revisited to address any changes. The final
during any execution of the ADM cycle or a as part of the Architecture Vision. version must include the full implications of the
phase Identify changed requirement; remove, add, requirements (e.g., costs, timescales, and
modify, and re-assess priorities Each architecture domain then generates business metrics).
Ensure that relevant architecture requirements detailed requirements. Deliverables in later
are available for use by each phase as the Identify changed requirement and record ADM phases contain mappings to new types of
phase is executed priorities; identify and resolve conflicts; requirements (for example, conformance
generate Requirements Impact Statements requirements).

Assess impact of changed requirements on

current and previous ADM phases

Implement requirements arising from Phase H

Update the Architecture Requirements

Repository

Implement change in the current phase

Assess and revise gap analysis for past phases

834
Test Yourself Question

Q. Which of the following is not a resource recommended for Requirements

Management?

A. Business Scenarios
B. Gap Analysis
C. Volère Requirements Specification template
D. Requirements Tools
E. Volère “waiting room” template

835
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 16. ADM Architecture Requirements Management

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap16.html
Workshop

List the requirements of your EA

project, including Volère
Requirements
Module 39
ADM Deliverables
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The aim of this module is to introduce the key deliverables of the ADM cycle:

The role of Architecture Deliverables

The purpose of key deliverables

839
The role of Architecture Deliverables

The contractual or formal work products of an architecture project

The definition of deliverable provided by the TOGAF standard is a baseline

It is thus a starting point for tailoring

840
Architecture Deliverables

 Architecture Building Blocks  Communications Plan

 Architecture Contract  Implementation and Migration
 Architecture Definition Plan
Document  Implementation Governance
 Architecture Principles Model
 Architecture Repository  Organizational model for
 Architecture Requirements Enterprise Architecture
 Architecture Roadmap  Request for Architecture Work
 Architecture Vision  Requirements Impact
Assessment
 Business Principles, Business
Goals and Business Drivers  Solution Building Blocks
 Capability Assessment  Statement of Architecture Work
 Change Request  Tailored Architecture Framework

841
Request for Architecture Work

Sent from the Sponsor to the Architecture Organization

This initiates a cycle of the ADM

Created as an output from the Preliminary Phase or an approved

architecture Change Request

842
Statement of Architecture Work

A deliverable output from Phase A

A response to the Request for Architecture Work

A plan for the architecture work

843
Architecture Vision

Produced in Phase A

An aspirational view of the end architecture product

Its purpose is to agree the desired outcome for the architecture

844
Communications Plan

Produced in Phase A

Allows for a planned and managed process for communication about a new
architecture

845
Architecture Definition Document

The deliverable container for the core artifacts

 Business, Data, Application, and Technology architectures

 Includes baseline, transition and target architectures

 Developed through phases A, B, C, and D

 It provides a qualitative view of the solution

846
Architecture Requirements Document

The deliverable container for the requirements for an architecture

A companion to the Architecture Definition Document

It contains measurable criteria – a quantitative view

Often used as a component of the Architecture Contract

847
Architecture Roadmap

Incrementally developed throughout phases E and F

 Informed by the Candidate Roadmap Components identified in phases

B, C, and D

This lists individual increments of change

Shows progression from Baseline to Target

848
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 32. Architecture Deliverables

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap32.html
Practical Example – Vision Document
Practical Example –
AS IS Architecture Definition Document
Practical Example –
TO BE Architecture Definition Document
Practical Example – Roadmap Document
Module 40
Architecture Partitioning
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to describe:

 How an overall EA can be partitioned

 Key learning outcomes:

• The purpose of Architecture Partitioning

• The classification criteria for solutions and architectures when considering partitioning

• How Architecture Partitioning can be employed in the Preliminary Phase of the ADM

855
Partitioning

Allows for management of costs and complexity by dividing up the Enterprise and
assigning appropriate roles and responsibilities to each partition

856
The Need to Partition

Managing Complexity

Managing Conflicts

Managing Parallel developments

Managing Re-use

857
Applying Classification to Partitioned Architectures:
Solution Partitioning

Subject Matter (breadth)

Its content, structure and function

Time
All solutions exist for a period of time

Maturity/Volatility
The extent to which subject matter and environment of a solutions are likely
to change over time

858
Applying Classification to Partitioned Architectures:
Architecture Partitioning

Depth (Level of detail) depends on stakeholder interested

Details
High Level
Details
Implementation
Executives Operation

859
Preliminary Phase

Determine the organization structure for architecture within the enterprise

 Identify the teams

Determine responsibilities for each architecture team

 Subject matter areas
 Level of detail
 Time period
 Stakeholders

Determine the relationship between architectures

 Where do architectures overlap?
 What are the compliance requirements between architectures?

860
Example Teams allocated

861
Summary

Architecture Partitioning can be used to manage complexity, parallel

developments, conflicts and re-use

Classification criteria are defined for architectures and, solutions

TOGAF provides guidance on how to use partitioning in the Preliminary

Phase of the ADM cycle

862
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 36. Architecture Partitioning

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap36.html
Practical Example – Architecture Partitioning
Workshop

Identify partitions of your EA project

and justify them
Module 41
Adapting the ADM:
Iteration and Levels
(guideline) V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives of this module are to understand:

 How to adapt the ADM using iteration and different levels of architecture
engagement

867
Iteration and Levels

868
Iteration and the ADM

The ADM supports the following concepts as iterations:

 Iterations to describe parts of the overall Architecture Landscape based

on SOW initiatives or development and integration decisions

 Iterations to implement EA changes

869
Iteration to develop a comprehensive Architecture
Landscape

Several projects will run through

ADM cycles

Each cycle is bound by Request for

Architecture Work

The architecture landscape is

updated frequently by the outputs

Projects may run concurrently

One project may trigger the initiation

of another project.
Iteration within an ADM Cycle

Projects may operate multiple ADM

Phases concurrently

Projects may cycle between phases

Projects may return to previous

phases
 Architecture Capability Architecture Development
iterations support creation iterations support creation
Iteration Cycles
and evolution of the and evolution of
Architecture Capability architecture content by
cycling through Phases B, C,
and D

Architecture Governance
iterations support
governance of change activity

As iterations converge on a
Transition Planning iterations target, extensions into Phases
support the creation of E & F ensure the viability of
formal change roadmaps implementation is considered

874
Approaches to Architecture Development

Baseline First Target First

Identify problem areas The high level target is already

agreed

Baseline is complex
The enterprise is willing to transform

Baseline is not clearly understood

875
Classes of Architecture Engagement

Identification of Change Required

Definition of Change

Implementation of Change

876
Classes of Architecture Engagement

877
Iteration Focus for Classes of Architecture
Engagement (Extract)

Engagement Iteration Focus Scope

Supporting Architecture Capability Broad, shallow consideration given to the Architecture
Business Strategy Landscape in order to address a specific strategic
Architecture Development question and define terms for more detailed architecture
(Baseline First)
efforts to address strategy realization.
Architectural Architecture Capability Focus on physical assessment of baseline applications
Portfolio and technology infrastructure to identify improvement
Management of the Architecture Development opportunities, typically within the constraints of
Landscape (Baseline First)
maintaining business as usual.

Architectural Transition Planning Focus on projects, project dependencies, and

Portfolio Architecture Governance landscape impacts to align project sequencing in a way
Management of that is architecturally optimized.
Projects
Iteration Considerations

Iteration between ADM Cycles

Higher level architecture guides and constrains detailed architectures

The Migration Planning phase of one ADM cycle initiates new projects to
develop architectures

Develop a complete architecture landscape in multiple iterations

879
A Hierarchy of ADM Processes

880
Iteration within the ADM Cycle – Baseline First

881
Iteration within the ADM Cycle – Target First

882
Architecture Development Iteration “Baseline First”

Iteration 1
Define the Baseline Architecture

Iteration 2
Define the Target Architecture and
gaps

Iteration n
Refine the Baseline Architecture,
Target Architecture, and gaps

883
Architecture Development Iteration “Target First”

Iteration 1
Define the Target Architecture

Iteration 2
Define the Baseline Architecture and
gaps

Iteration n
Refine the Baseline Architecture,
Target Architecture, and gaps.

884
Transition Planning

Iteration 1
Define and agree a set of
improvement opportunities, aligned
against a provisional Transition
Architecture

Iteration n
Agree the Transition Architecture,
refining the identified improvement
opportunities to fit

885
Architecture Governance

Iteration 1
Mobilize architecture governance
and change management
processes.

Iteration n
Carry out architecture governance
and change control

886
Applying the ADM Across the Architecture Landscape

887
Organizing the Architecture Landscape

The following characteristics can be used to organize the Architecture

Landscape
Breadth (subject matter)
Depth
Time
Recency
Summary

TOGAF provides guidelines for adapting the ADM for iteration

This includes proposed iteration cycles for different classes of architecture

engagement

Guidance is also provided for the use of levels for architecture development
across the Architecture Landscape

889
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 18. Applying Iteration to the ADM

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap18.html

Chapter 19. Applying the ADM Across the Architecture Landscape

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap19.html
Workshop

List the iterations of your EA project

and the scope of each iteration
Module 42
Architecture Skills
Framework
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives are to:

 Explain the purpose of the Architecture Skills Framework and why it is

needed

 Describe the benefits of using the Architecture Skills Framework

 Describe the structure of the Architecture Skills Framework, including

roles, skills and proficiency levels

893
Roles

Architecture Sponsor CxO

Project
Manager

Architecture
Sponsor

Business
Architecture Board
Member There are many roles involved in an Architect

enterprise architecture practice

Application
Project EA Architect
Manager Manager

Technology Architecture Board

Architect Member
IT Designer
Business Business
Architect Domain
Experts
Data
Architect

QA / Standards Enterprise IT Designer

Groups IT Designer Security

894
Purpose

Definitional Rigor
 ‘‘Enterprise Architecture’’ and ‘‘Enterprise Architect’’ are widely used but
poorly defined terms.
 There is a need for clearer definitions.

Basis of an Internal Architecture Practice

 An enterprise architecture practice is a formal program of development
and certification by which an enterprise recognizes the skills of its
architects
 Such a program is essential in order to ensure the alignment of staff
skills and experience with the architecture tasks that the enterprise
wishes to perform

895
Purpose

An enterprise architecture practice is both difficult and costly to set up

The TOGAF Architecture Skills Framework attempts to address this need

 By providing definitions of the architecting skills and proficiency levels

required of personnel, internal or external, who are to perform the
various architecting roles defined within the TOGAF Framework

896
Benefits of using the Architecture Skills Framework

Specific benefits anticipated include:

Reduced time, cost, and risk in training, hiring, and managing architecture
professionals, both internal and external.

Reduced time and cost to set up an internal architecture practice

This in turn helps reduce the time, cost and risk of overall solution
development

897
The structure of the Architecture Skills Framework

The TOGAF Architecture Skills Framework provides a view of the

competency levels for specific roles within the enterprise architecture team.

The Framework defines:

 The roles within an enterprise architecture work area

 The skills required by those roles

 The depth of knowledge required to fulfil each role successfully

898
The structure of the Architecture Skills Framework

A typical EA team comprises the following roles:

 Architecture Board Members
 Architecture Sponsor
 Architecture Manager
 Architects for :
• Enterprise Architecture
• Business Architecture
• Data Architecture
• Application Architecture
• Technology Architecture
• Program and/or Project Managers
• IT Designer
• etc . . .

899
The structure of the Architecture Skills Framework

The TOGAF team will include the following main categories of skills:
 Generic Skills: leadership, team working, inter-personal skills, etc.
 Business Skills & Methods: business cases, business process,
strategic planning, etc.
 EA Skills: modeling, building block design, applications and role design,
systems integration, etc.
 Program or Project Management Skills: managing business change,
project management methods and tools, etc.
 IT General Knowledge Skills: brokering applications, asset
management, migration planning, SLAs, etc.
 Technical IT Skills: software engineering, security, data interchange,
data management, etc.
 Legal Environment: data protection laws, contract law, procurement
law, fraud, etc.

900
The structure of the Architecture Skills Framework

Proficiency Levels

901
The structure of the Architecture Skills Framework

Skills Matrices – Example Generic Skills

902
Summary

This module has introduced the Architecture Skills Framework, a

classification model for architect roles.

903
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 46. Architecture Skills Framework

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap46.html
Module 43
Adapting the ADM:
Security (guideline)
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Roadmap

906
Module Objectives

The objectives of this module are:

 Obtain an understanding of the security considerations that need to be

addressed during application of the ADM

907
The Open Group Guide: Integrating Risk and Security
within a TOGAF® Enterprise Architecture

Provides guidance to consider security while developing EA

Explains how to tailor TOGAF to use existing Enterprise Security

Architecture

908
Enterprise Security Architecture
Enterprise Architecture Business Drivers / Business Objectives Enterprise Security Architecture
Security Principles
Risk Appetite

Key Risk Areas / Business Impact

Security Resource Plan

Security Policy Architecture

Security Domain Model
Trust Framework

Risk Assessment
Business Risk Model / Risk Register Identity &
Access Mgt
Applicable Law and Regulation Register
Continuity
Applicable Control Framework Register Management
Security
Intelligence
Security Services Catalogue
Security
Security Classification Monitoring
Data Quality Compliance
Management
Security Standards Etc.

Business Attribute Profile

Control Objectives / Security Objectives Enterprise

Information Risk
Risk Mitigation Plan Security Management
Management
Security Audit

Security Training & Awareness

909
Security as a Cross-Cutting Concern
Security

Business

Data

Application

Technology

910
Adapting the ADM for Security

911
ADM Requirements Management
Use Business Attribute Profiling, a
requirements engineering technique
from The SABSA® Institute

Advantages:
 Executive communication in non-IT
terms
 Traceability mapping between
business drivers and requirements
 Performance measurement against
business-defined targets
 Grouping and structuring of
requirements, which facilitates
understanding and oversight by
architects
Preliminary Phase

Consider:

 Business Drivers/Business
Objectives affecting security

 Security Principles

 Risk Appetite

 Key Risk Areas/Business Impact

Analysis

 Security Resource Plan

913
Phase A: Architecture Vision

Identify the complete list of all

stakeholders, their concerns, and
associated requirements for
approval of the architecture.

Satisfy security Stakeholders

Satisfy business stakeholders

914
Phase B: Business Architecture

Consider business-level trust, risk, and

controls, independent from specific IT or
other systems within the specific scope
of the architecture engagement.

Artifacts include:
 Security Policy Architecture
 Security Domain Model
 Trust Framework
 Risk Assessment
 Business Risk Model/Risk Register
 Applicable Law and Regulation
Register
 Application Control Framework
Register

915
Phase C: Information Systems Architectures

Consider functional security services

and their security classification.

Artifacts include:
 Security Services Catalog
 Security Classification
 Data Quality

916
Phase D: Technology Architecture

Ensure that the required controls are

included in the Technology
Architecture

Verify the controls are used in an

effective and efficient way

Specific Technology Architecture

security views or deliverable may be
required

917
Phase E: Opportunities and Solutions

Evaluate security and risk

Security ABBs defined in previous

phases become SBBs

This phase should include a Risk

Mitigation Plan (including security
risks)

918
Phase F: Migration Planning

Migration is itself a business process

that needs to be secured

Migration strategy should include a

Risk Assessment and a Risk
Mitigation Plan

Migration planning should include a

security impact analysis

919
Phase G: Implementation Governance

Ensure adherence to the overall

Security Architecture

Ensure avoidance of unacceptable

risks during implementation

920
Phase H: Architecture Change Management

Continuously evaluate risks related

to changes in business opportunity
and security threats

Consider security in change

management

921
Summary

The Open Group Guide: Integrating Risk and Security within a TOGAF®
Enterprise Architecture introduces guidance on Security and the ADM to
help practitioners avoid missing a critical security concern

It is intended to inform the enterprise architect of how the TOGAF method

and framework can be tailored to address security and risk properly.

922
Module 44
Architecture Maturity
Models
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives are to:

 Explain the role of a Capability Maturity Model

 Explain the CMMI process improvement approach development by CMU

 Describe the structure and levels of the ACMM developed by CMU for
the US DoC

 Explain the role of Maturity Assessments in the ADM

924
Capability Maturity Models

Capability Maturity Models (CMMs) provide an effective method for control

and improvement of change processes

Benefits of such models include:

 They describe the practices that any organization must perform in order
to improve its processes
 They provide measures for improvement
 They provide a framework for managing the improvement efforts
 They organize the various practices into levels, each level representing
an increased ability to control and manage the development
environment

925
Capability Maturity Models

An evaluation of the organization ’ s practices against the model (an

“assessment ” ) is performed to find the current level at which the
organization currently stands

This shows the organization’s maturity and the areas to focus on for the
greatest improvement and the highest ROI

926
Capability Maturity Models

The original CMM was developed in the early 1990s by CMU and is still
widely used today.

CMMI have been developed for:

 Development (for Software, Hardware or System Engineering)
 Services
 Supplier Management
 People Management

In the future CMMI will cover:

 Security
 Safety

927
The CMMI

According to the CMMI Institute, the use of the CMMI model improves on
best practices by enabling organizations to:
 Explicitly link management and engineering activities to business
objectives
 Expand the scope of and visibility into the product lifecycle and
engineering activities
 Incorporate lessons learned from additional areas of best practice (e.g.,
measurement, risk management etc.)
 Implement more robust high-maturity practices
 Address additional organizational functions
 Comply with ISO standards

CMMI has been adopted worldwide.

928
The CMMI

SCAMPI, the Standard CMMI Appraisal Method for Process Improvement, is

used to identify strengths, weaknesses, and ratings relative to CMMI
reference models.

It incorporates best practice and is based on the features of several

appraisal methods.

It is applicable to a wide range of appraisal usage modes, including both

internal process improvement, source selection and process monitoring.

929
US Department of Commerce ACMM

The enterprise Architecture Capability Maturity Model (ACMM) was

developed for conducting internal assessments. It is a framework that
represents the key components of a productive EA process. The goal is to
identify weak areas and provide a way to improve the overall architecture
process.

The ACMM has 3 sections:

 The EA maturity model
 EA characteristics of processes at different maturity levels
 The EA CMM scorecard

930
ACMM Maturity Levels

The DoC ACMM consists of

5: Measured

4: Managed  6 maturity levels

3: Defined

 9 architecture elements
2: Under Development

1: Initial

0: None

931
ACMM Enterprise Architecture Elements

Architecture process:
Is there an established Enterprise Architecture process?
Architecture development:
To what extent is the development and progression of the Operating Units'
Enterprise Architecture documented?
Business linkage:
To what extent is the Enterprise Architecture linked to business strategies or
drivers?
Senior management involvement:
To what extent are the senior managers of the Operating Unit involved in the
establishment and ongoing development of an IT Architecture?
Operating unit participation
To what extent is the Enterprise Architecture process accepted by the Operating
Unit?
To what extent is the Enterprise Architecture process an effort representative of the
whole organization?

932
ACMM Enterprise Architecture Elements

Architecture communication
 To what extent are the decisions of EA practice documented?
 To what extent is the content of the EA made available electronically to
everybody in the organization?
 To what extent is architecture education done across the business on the EA
process and contents?
IT security
To what extent is IT Security integrated with the EA?
Architecture governance
To what extent is an EA governance (governing body) process in place and
accepted by senior management ?
IT investment and acquisition strategy
To what extent does the EA influence the IT Investment and Acquisition Strategy?

933
Example: ACMM Scoring Criteria

Score Element Architecture Process

0 No EA Not established or does not exist.

1 Initial Exists in ad-hoc or localized form or early draft form may exist. Some Enterprise
Architecture processes are defined. There is no unified architecture process
across technologies or business processes. Success depends on individual
efforts.
2 Developing Being actively developed. Basic Enterprise Architecture Process program is
documented based on OMB Circular A-130 and Department of Commerce
Enterprise Architecture Guidance. The architecture process has developed clear
roles and responsibilities.
3 Defined The architecture is well defined and communicated to IT staff and business
management with Operating Unit IT responsibilities. The process is largely
followed.
4 Managed Enterprise Architecture process is part of the culture, with strong linkages to
other core IT and business processes. Quality metrics associated with the
architecture process are captured. These metrics include the cycle times
necessary to generate Enterprise Architecture revisions, technical environment
stability, and time to implement a new or upgraded application or system.
5 Measured Continuous improvement of Enterprise Architecture processes.
934
Maturity Assessments in the ADM

Maturity Assessments are referred to in the Preliminary Phase, Phase A,

and Phase E of the ADM

The approach to the Preliminary Phase recommends their use as part of

developing the Organizational Model for Enterprise Architecture

In Phase A, a maturity assessment is part of the Capability Assessment

used to determine the baseline and target capability of the enterprise

This Capability Assessment is also revisited in Phase E, when preparing the

Implementation and Migration Plan

935
Maturity Assessments in the ADM (Cont’d)

When using CMMs with the ADM, it is recommended that they be

customized and discussed in workshops involving the major stakeholders
within the organization

The actual levels of maturity can provide a strategic measure of the

organization’s ability to change, as well as a series of sequential steps to
improve that ability

936
Summary

This module has explained the role of Architecture Capability Maturity

Models in enabling an enterprise to determine the state of its Enterprise
Architecture process and to evaluate risks and options during the
development of the Enterprise Architecture

Performing a maturity assessment may involve the use of a number of

models. The assessment focuses on measuring business benefits and
return on investment

937
Reference

TOGAF 9.2
https://pubs.opengroup.org/architecture/togaf92-doc/arch/

Chapter 45. Architecture Maturity Models

https://pubs.opengroup.org/architecture/togaf92-doc/arch/chap45.html
Module 45
The TOGAF® Certification
for People Program
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Module Objectives

The objectives are to:

 Describe The Open Group Certification for People program for the
TOGAF Standard

 Understand the levels for certification

 Understand the paths for certification

 Understand the requirements for certification

940
TOGAF Certification for People

Ensures that individuals are knowledgeable about the TOGAF standard

Is a common baseline of knowledge

Provides a visible trust mark

Is a foundation for the emerging profession

941
TOGAF 9 Certification Levels

Level Tag Purpose

1 TOGAF 9 To provide validation that the candidate
Foundation has gained knowledge of the TOGAF
terminology, structure, and basic
concepts, and understands the core
principles of Enterprise Architecture and
the TOGAF standard
2 TOGAF 9 To provide validation that in addition to
Certified knowledge and comprehension, the
candidate is able to analyze and apply
knowledge of the TOGAF standard

942
 2

TOGAF 9 Certified

TOGAF 9 Foundation 1

Level 2 is a superset of Level 1

Level 1 – TOGAF 9 Foundation
Target Audience

Individuals requiring a basic understanding of the TOGAF 9 standard

Professionals working in roles associated with an architecture project such

as those responsible for planning, execution, development, delivery and
operation

Architects looking for a first introduction to the TOGAF 9 standard

Architects who want to achieve Level 2 certification in a stepwise approach.

944
Level 2 – TOGAF 9 Certified
Target Audience

Individuals requiring a deeper understanding of the TOGAF 9 standard

Professionals working in an organization where the TOGAF 9 standard has

been adopted and who need to participate in architecture projects and
initiatives

Architects who will be responsible for developing architecture artifacts

Architects who wish to introduce the TOGAF 9 standard into an architecture

practice;

Architects who want to achieve a recognized qualification to demonstrate

their detailed knowledge of the TOGAF 9 standard.

945
Paths to Certification

Sample
Sample
Yes
Stepwise TOGAF 9 TOGAF 9 TOGAF 9
Development? Part 1 Exam Foundation Part 2 Exam

No TOGAF 9
Certified

TOGAF 9
Combined Part 1 & Part 2 Exam

946
Components

Level Tag Requirements

1 TOGAF 9 13 Learning Units
Foundation

2 TOGAF 9 13 Learning Units (from Foundation)

Certified Plus
26 Learning Units

947
Level 1 Learning Units

1. Basic Concepts
2. Core Concepts
3. General Definitions
4. Introduction to the ADM
5. Enterprise Continuum and Tools
6. ADM Phases (Level 1)
7. ADM Guidelines and Techniques
8. Architecture Governance (Level 1)
9. Architecture Views, Viewpoints and Stakeholders
10. Building Blocks
11. ADM Deliverables (Level 1)
12. TOGAF Reference Models (Level 1)
13. TOGAF Certification Program

948
Level 2 Learning Units

Level 1 Units + 13. The Integrated Information Infrastructure

Reference Model (Level 2)
14. Phase D: Technology Architecture
1. Preliminary Phase
15. Migration Planning Techniques
2. Architecture Governance (Level 2)
16. Phase E: Opportunities & Solutions
3. Business Scenarios Technique
17. Phase F: Migration Planning
4. Phase A: Architecture Vision
18. Phase G: Implementation Governance
5. Architecture Content Framework
19. Phase H: Architecture Change
6. Stakeholder Management Management
7. TOGAF Content Metamodel 20. ADM Architecture Requirements
8. Architecture Implementation Support Management
Techniques 21. Architecture Partitioning
9. Phase B: Business Architecture 22. The Architecture Repository
10. Phase C: Information Systems 23. Guidelines for Adapting the ADM: Iteration
Architectures – Data Architecture and Levels
11. Phase C: Information Systems 24. Guidelines for Adapting the ADM: Security
Architectures – Application Architecture
25. Architecture Maturity Models
12. TOGAF Foundation Architecture: The
TRM (Level 2) 26. Architecture Skills Framework

949
Level 1 Exam Requirements

Level Tag Requirements

1 TOGAF 9 Exam Type: Multiple Choice
Foundation 40 Questions / 60 minutes
Supervised: Yes
Open Book: No
1 point for the correct answer
0 points for any wrong answer
Passing score is 60%
As a non-English speaker you can add
50% to the exam time

950
Level 2 Exam Requirements

Level Tag Requirements

2 TOGAF 9 Exam Type: Complex Multiple Choice
Certified Scenario-based
8 Questions / 90 minutes
Supervised: Yes
Open Book: Yes
5 points for the best answer
3 points for the send best answer
1 point for the third best answer
0 points for the wrong answer
Passing score is 70%
As a non-English speaker you can add
50% to the exam time

951
Combined Part 1 and 2 Examination

Each section must be passed in order to obtain an overall pass mark

If you fail a section then no certification is awarded, however you only need
retake the Examination(s) corresponding to the failed section(s)

You must wait one month before a retake

952
Certification

Within 6 working days of receipt of the exam results you will receive an
email from The Open Group and be invited to login to complete your
certification

You may download and print your certificate

You can adjust your register entry to make it public (the default is to be
confidential)

You will be invited to opt-in to The Open Group Badging program to receive
a digital credential (in addition to the certificate)
953
Module 46
Archisurance Case Study
V9.2 Edition Copyright © 2009-2018
All rights reserved
Originally Published by The Open Group, 2018
Updated by ILKD, 2020
Not for distribution outside trainees
Practical Example – Archisurance Case Study V3.1
 ‫شكرا‬
Obrigado
Grazie
Tak
KÖSZÖNÖM Arigato
Danke schön
‫شکريہ‬ Xiexie
谢谢