TOGAF

The Open Group Architecture Framework

By: Ahmad Alharbi

TOGAF Ahmad Alharbi 1

Ahmad Alharbi
• Enterprise Architect with +9 years of experience. I possess wide
experience in solution architecture, designed implementation
using different architectural style and technologies.

• Accredited certifications in TOGAF Certified, Business Architecture

Level1 from TOGAF, Business Continuity from DR Institute, PMP,
GEIT from ISACA, Oracle Cloud Infrastructure, Oracle Autonomous
DB Cloud, Oracle E-Business Suite HCM, ITIL v4 SL, ITIL v4 DIS,
ITIL v4 DPI, ITILv4 Foundation.

• TOGAF Instructor, Consultant (EA, ITSM, DT), EA Expert, Part time

with government entities as EA Expert, DBA, Developer. M: 0555004772

TOGAF Ahmad Alharbi 2

 Module
Course Content
Introduction Introduction (Who we are?)
Module 1 Course introduction (Basic Concept)
Module 2 Core concept and TOGA with other Frameworks
Module 3 Introduction to the ADM and ADM Phases
Module 3 Preliminary Phase Module
Module 3 Phase A: Architecture Vision
Module 3 Phase B: Business Architecture
Module 3 Phase C: Information Systems Architecture - Overview
Module 3 Phase C: Data Architecture
Module 3 Phase C: Application Architecture
Module 3 Phase D: Technology Architecture
Module 3 Phase E: Opportunities and Solutions
Module 3 Phase F: Migration Planning
Module 3 Phase G: Implementation Governance
Module 3 Phase H: Architecture Change
Module 3 ADM Architecture Requirements
Module 4 ADM Deliverables
Module 4 Building Blocks
Module 5 ADM Guidelines and techniques
Module 5 The Enterprise Continuum
Module 6 Architecture Repository
Module 7 Architecture Content Framework and Content Metamodel
Module 8 Architecture Governance
Module 9 TRM and III-RM
Module 10 Architecture Views, Viewpoints
Module 11 Architecture Maturity Model
Module 12 EA and DGA Interactions + (OM, Blueprint and BC) Docs
Module 12 Exam Preparation

TOGAF Ahmad Alharbi 3

Introduction

01 02 03
Name Title Company (optional)

04 05
Architecture experience Expectations

TOGAF Ahmad Alharbi 4

 Course
Module 01

introduction
(Basic Concept)

TOGAF Ahmad Alharbi 5

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Course introduction and basic concept

History

Exam Basic
process concept

TOGAF Ahmad Alharbi 6

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

The history of TOGAF

• The TOGAF standard is a framework for Enterprise
Architecture. It may be used freely by any organization wishing
to develop an Enterprise Architecture for use within that
organization.

• The TOGAF standard is developed and maintained by members

of The Open Group. The original development of TOGAF
Version 1 in 1995 was based on the Technical Architecture
Framework for Information Management (TAFIM), developed
by the US Department of Defense (DoD).

• The DoD gave The Open Group explicit permission and

encouragement to create Version 1 of the TOGAF standard,
which itself was the result of many years of development
effort and many millions of dollars of US Government
investment. Starting from this sound foundation, the members
of The Open Group Architecture Forum have developed
successive versions of the TOGAF standard.

TOGAF Ahmad Alharbi 7

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

The history of TOGAF

The first version of TOGAF
(TOGAF 1.0) was
presented

01 TOGAF 1
03 TOGAF 8
05 TOGAF 8.1.1
07 TOGAF 9.1 09 TOGAF 10

• 1995 • 2002 • 2006 • 2012 • 2022

• 2001 • 2003 • 2009 • 2018

02 TOGAF 7
04 TOGAF 8.1
06 TOGAF 9 08 TOGAF 9.2

Around 2005 TOGAF

become a registered
trademark of the
Open Group

TOGAF Ahmad Alharbi 8

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Exam Process
Part 1 Part 1
• The exams are managed by Duration 60 minutes consisting of 40
multiple choice questions (closed book).
Duration 90 minutes
consisting of 8 complex
Pearson VUE One point is awarded for a correct answer, scenario-based multiple-
zero points for all other answers. Pass choice questions (open
mark is 22: book). Each question has
• The exam consists of two parts – • Basic Concept (3 Questions) four possible answers.
Foundation (Part 1) and Certified •
•
Core Concept (3 Questions)
Introduction to the ADM (3 Questions)
Five points are awarded
for the correct answer,
(Part 2) • The Enterprise Continuum (4 Questions) three points for the next
• ADM Guidelines and Techniques (6 best answer, one point a
Questions) barely correct answer,
• Architecture Governance (4 Questions)
and zero points for the
• Architecture Views, Viewpoints and
remaining answer. Pass
Stakeholders (2 Questions)
mark is 24.
• Building Blocks (2 Questions)
• ADM Deliverables (2 Questions)
• TOGAF Reference Models (2 Questions)

TOGAF Ahmad Alharbi 9

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Exam Process
Exam Path

Yes
TOGAF 9.1 TOGAF Essentials 2018
Certified?

TOGAF 9.2
No Foundation

Stepwise Yes TOGAF 9.1 Part TOGAF 9.1 Part 2

Development 1 Exam Exam

No

TOGAF 9.2 Combined Part 1vand

Part 2 Exam

TOGAF Ahmad Alharbi 10

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
What is an Enterprise?

An enterprise is a collection of organizations that share a common set of goals.

Enterprises come in many shapes and forms:

A B C D E F
A whole A government A chain of Chain of Groups of Partnerships and
corporation or a agency or a single geographically dispersed countries or alliances of
division of a government distant organizations governments businesses working
corporation department organizations linked by working together together, such as a
linked together by common to create common consortium or supply
common ownership or shareable chain And there is the
ownership deliverables or Extended Enterprise
infrastructures that encompasses
other organizations
who do business with
you.

TOGAF Ahmad Alharbi 11

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
Why Enterprise Architecture - What is its Purpose?

• Complex organizations (enterprises)

have complex systems.
• Enterprise Architecture is about
integrating those systems... Why? To Current IT systems Pressure to develop
support the business strategy. suffer from : Enterprise Architecture:
• EA provides a strategic context for
system evolution, in response to the • Fragmented, • Laws and regulations
constantly changing business duplicated (DGA)
environment, particularly Digital
• Poorly understood, • Audit requirements
Transformation.
• It creates an environment where IT • Not responsive to • More co-operative IT
efficiency is balanced against business change operations
need.

TOGAF Ahmad Alharbi 12

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
What are the EA Benefits?

A more efficient business A more efficient IT Better return on existing investment,

operation: operation: reduced risk for future investment:
• Lower business operation • Lower software development, • Reduced complexity in the business
costs support and maintenance costs and IT
• More agile organization • Increased portability of • Maximum return on investment in
• Lower change management applications existing business and IT
costs • Improved ability to address • The flexibility to make, buy, or
• Improved business critical enterprise-wide issues outsource business and IT solutions
productivity like security • Reduced risk overall in new
• Easier upgrade and exchange of investments and their cost of
system components ownership

TOGAF Ahmad Alharbi 13

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
The TOGAF Framework parts

TOGAF Ahmad Alharbi 14

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
The TOGAF Framework Parts:

Introduction: The Architecture ADM Guidelines and Architecture Content The Enterprise Architecture Capability
overview and Development Techniques: this contains Framework: puts Continuum: despite its Framework: this final
summary of the Method: a process many established structure into the sort rather enigmatic title section has some
techniques. It is the most
Standard, including for undertaking of documents this area provides some important aspects, not
valuable toolkit,
key definitions – Enterprise architects deal with, fundamental and least guidance on
addressing topics such as
Not mentioned in Architecture Governance (principles),
and more importantly substantial help on how Architecture
the figure - Stakeholder Management, perhaps, a Metamodel to both visualize and Governance, and a
Business Scenarios, Gap that describes organize both Skills Framework
Analysis, Migration architectural entities Architecture definitions
Planning Techniques, Risk and their relationships (Building Blocks), and
Management, and more the associated
processes

Part I Part II Part III Part IV Part V Part VI

TOGAF Ahmad Alharbi 15

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Basic concepts
TOGAF Framework Capabilities:

TOGAF Ahmad Alharbi 16

 Module 02

Core concept and

TOGAF framework

TOGAF Ahmad Alharbi 17

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Core concept and TOGAF framework

What is Types of ADM Deliverables Enterprise Architecture Enterprise TOGAF with

TOGAF Architecture , Artifacts, Continuum Repository Architecture Other
and Building Capability Frameworks
Blocks

TOGAF Ahmad Alharbi 18

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

What is TOGAF?
What is Architecture the Context of TOGAF?
The fundamental organization of a system, embodied in its components, their relationships to each other
and the environment, and the principles governing its design and evolution

Architecture has two meanings depending upon the context:

• A formal description of a system, or a detailed plan of the system at component level to guide its
implementation
• The structure of components, their inter-relationships, and the principles and guidelines governing
their design and evolution over time

What is TOGAF Standard?

It provides the methods and tools for assisting in the acceptance, production, use, and maintenance of
an Enterprise Architecture. It is based on an iterative process model supported by best practices and a
re-usable set of existing architecture assets.

TOGAF Ahmad Alharbi 19

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

What is TOGAF?
What is an Architecture Framework?
• Like any framework, it is a lot of good advice that’s been developed over years
• Guidance on designing the “Building Blocks” of an architecture
• A set of tools (vocabulary, techniques) to help in this process
• The standardization necessary to attract vendor-based tools to help architects in their work

So why is the TOGAF® Framework so suitable?

• Because it has evolved over many years to deliver this toolset
• It is “best practice” used by and supported by many architects
• The TOGAF® Framework really comes to the fore when considering more complex
systems in complex organizations, by addressing the problems often encountered in
these situations
• It has a process and toolset that is...
- Focused on aligning IT and business
- Based on “codified common sense” and best practices
- The product of many experienced architects
- An open standard, therefore free
- Supported by tool vendors and others
- Widely adopted

TOGAF Ahmad Alharbi 20

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Types of Architecture
What Kind of Architecture Does
TOGAF Deal With?

TOGAF Ahmad Alharbi 21

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Types of Architecture
There are four architecture domains that are commonly accepted as subsets of an overall enterprise
architecture, all which TOGAF is designed to support:

The Business Architecture defines the The Data Architecture describes the
business strategy, governance, structure of an organization's logical and
organization, and key business processes physical data assets and data management
resources

The Application Architecture provides a The Technology Architecture describes

blueprint for the individual applications to the logical software and hardware
be deployed, their interactions, and their capabilities that are required to support the
relationships to the core business deployment of business, data, and
processes of the organization. application services. This includes IT
infrastructure, middleware, networks,
communications, processing, standards, etc

TOGAF Ahmad Alharbi 22

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM
The TOGAF Architecture
Development Method (ADM)

TOGAF Ahmad Alharbi 23

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM
The TOGAF Architecture Development Method (ADM)
➢ The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including
customization of TOGAF and definition of Architecture Principles.
➢ Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining
the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining
approval to proceed with the architecture development.
➢ Phase B: Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision.
➢ Phase C: Information Systems Architectures describes the development of Information Systems Architectures to support the agreed
Architecture Vision.
➢ Phase D: Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture
Vision.
➢ Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the
architecture defined in the previous phases.
➢ Phase F: Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed
Implementation and Migration Plan.
➢ Phase G: Implementation Governance provides an architectural oversight of the implementation.
➢ Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
• Requirements Management examines the process of managing architecture requirements throughout the ADM.

TOGAF Ahmad Alharbi 24

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Deliverables, Artifacts, and Building Blocks

The TOGAF Architecture Content Framework provides a structural model for architectural content that allows major work
products to be consistently defined, structured, and presented.

The TOGAF Architecture Content Framework provides a structural model for architectural content that allows major work
products to be consistently defined, structured, and presented.

A Deliverable is a work product that is contractually specified and in turn formally

reviewed, agreed, and signed off by the stakeholders.

Artifacts are generally classified as catalogs (lists of things), matrices (showing

relationships between things), and diagrams (pictures of things). Examples Business
service catalog, Stakeholder map matrix, HLD diagram. An architectural deliverable
may contain many artifacts and artifacts will form the content of the Architecture
Repository.

A Building Block represents a (potentially re-usable) component of business, IT, or

architectural capability that can be combined with other building blocks to deliver
architectures and solutions.

TOGAF Ahmad Alharbi 25

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Deliverables, Artifacts, and Building Blocks

Building blocks can be defined at various levels of detail, depending on what stage of architecture
development has been reached:
represent components that will be
Architecture Building used to implement the required
Blocks (ABBs) capability. For example, a network is a
building block that can be described
typically describe required capability through complementary artifacts and
and shape the specification of Solution then put to use to realize solutions for
Building Blocks (SBBs). For example, a the enterprise.
customer services capability may be
required within an enterprise, supported Solution Building
by many SBBs, such as processes, Blocks (SBBs)
data, and application software.

TOGAF Ahmad Alharbi 26

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Deliverables, Artifacts, and Building Blocks

The figure shown the

relationships between
deliverables, artifacts,
and building blocks.

TOGAF Ahmad Alharbi 27

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Deliverables, Artifacts, and Building Blocks

An example of the relationships between deliverables, artifacts, and building blocks:

TOGAF Ahmad Alharbi 28

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Continuum

TOGAF Ahmad Alharbi 29

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Continuum
TOGAF includes the concept of the Enterprise
Continuum, which sets the broader context for
an architect and explains how generic solutions
can be leveraged and specialized in order to
support the requirements of an individual
organization.

The Enterprise Continuum is a view of the

Architecture Repository that provides methods
for classifying architecture and solution artifacts
as they evolve from generic Foundation
Architectures to Organization-Specific
Architectures. The Enterprise Continuum
comprises two complementary concepts: the
Architecture Continuum and the Solutions
Continuum.

TOGAF Ahmad Alharbi 30

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Supporting the Enterprise Continuum is the
concept of an Architecture Repository
which can be used to store different classes
of architectural output at different levels of
abstraction, created by the ADM. In this
way, TOGAF facilitates understanding and
co-operation between stakeholders and
practitioners at different levels.

TOGAF Ahmad Alharbi 31

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
The major components within an Architecture Repository are as follows:

The Architecture The Architecture The Architecture The Standards The Reference The Governance
Metamodel describ Capability defines the Landscape is the Information Library provides Log provides a
es the parameters, architectural Base (SIB) captures guidelines, record of
organizationally structures, and representation of the standards with templates, governance
tailored application processes that assets deployed which new patterns, and other activity across
of an architecture support governance of within the operating architectures must forms of reference the enterprise.
framework, the Architecture enterprise at a comply, which may material that can
including a Repository. particular point in include industry be leveraged in
metamodel for time. The landscape standards, selected order to accelerate
architecture is likely to exist at products and services the creation of
content. multiple levels of from suppliers, or new architectures
abstraction to suit shared services for the enterprise.
different architecture already deployed
objectives. within the
organization.

TOGAF Ahmad Alharbi 32

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Architecture Capability

TOGAF Ahmad Alharbi 33

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Architecture Capability

In order to carry out architectural activity effectively within an enterprise, it
is necessary to put in place an appropriate business capability for
architecture, through organization structures, roles, responsibilities, skills,
and processes.
An enterprise architecture practice should establish
capabilities in the following areas:

Financial Performance Service Risk Resource

Management Management Management Management Management

Resource Quality Supplier Configuration Environment

Management Management Management Management Management

TOGAF Ahmad Alharbi 34

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF with Other Frameworks

TOGAF Ahmad Alharbi 35

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF with Other Frameworks

TOGAF Ahmad Alharbi 36

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF with Other Frameworks

Because TOGAF is a generic framework and intended to be
used in a wide variety of environments, it provides a flexible
and extensible content framework that underpins a set of
generic architecture deliverables.

In all cases, it is expected that the architect will adapt and

build on the TOGAF framework in order to define a tailored
method that is integrated into the processes and
organization structures of the enterprise.

This architecture tailoring may include adopting elements

from other architecture frameworks, or integrating TOGAF
methods with other standard frameworks, such as ITIL,
CMMI, COBIT, PRINCE2, PMBOK, and MSP.

TOGAF Ahmad Alharbi 37

 Introduction to the
Module 03

ADM and ADM

phases
The TOGAF Architecture Development
Method (ADM)

TOGAF Ahmad Alharbi 38

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

Introduction to ADM Phases

the ADM

TOGAF Ahmad Alharbi 39

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

TOGAF Ahmad Alharbi 40

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

History Overview Basic concept

TOGAF Ahmad Alharbi 41

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

The ADM and Key Points

TOGAF Ahmad Alharbi 42

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

Definition process
– Phases A to D

TOGAF Ahmad Alharbi 43

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

ADM Relationships

TOGAF Ahmad Alharbi 44

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

Guidelines and Techniques

TOGAF Ahmad Alharbi 45

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Introduction to the ADM

Adapting the ADM
The ADM is a generic method for architecture development, which is designed to deal with most system
and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit
specific needs.
One of the tasks before applying the ADM is to review its components for applicability, and then tailor
them as appropriate to the circumstances of the individual enterprise. This activity may well produce an
"enterprise-specific" ADM.
Scoping the Architecture:
Breadth: what is the full Depth: to what level of detail Time Period: what is Architecture Domains: a
extent of the enterprise, should the architecting effort the time period that complete Enterprise
and what part of that go? What is the appropriate needs to be articulated Architecture description
extent will this demarcation between the for the Architecture should contain all four
architecting effort deal architecture effort and other, architecture domains
Vision?.
with?. related activities (system (business, data, application,
design, system engineering, technology.
system development)?

TOGAF Ahmad Alharbi 46

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 47

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Objectives:

1 2
Determine the desired Architecture Establish the Architecture
Capability: Capability:
• Review the organizational context • Establish the Organizational Model for
• Identify and scope the elements of the Enterprise Architecture
enterprise organizations • Establish governance process and
• Identify the established frameworks, resources
methods, and processes that intersect • Select and implement EA tools
with the Architecture Capability • Define the Architecture Principles
• Establish a Capability Maturity target

TOGAF Ahmad Alharbi 48

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Approach:

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

TOGAF Ahmad Alharbi 49

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Inputs:

Any
The Other Business Business Major Governance
existing:
TOGAF architecture strategies principles, framework and legal • Organizationa
Library. frameworks and board business s operating frameworks l model
business goals, and in the • Architecture
framework
plans, IT business business • Architecture
strategy drivers Principles
• Architecture
Repository

TOGAF Ahmad Alharbi 50

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

TOGAF Ahmad Alharbi 51

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

1- Scope the Enterprise Organizations Impacted:

• Identify core enterprise.

• Identify soft enterprise.

• Identify extended enterprise.

• Identify communities.

• Identify governance involved.

TOGAF Ahmad Alharbi 52

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

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.

TOGAF Ahmad Alharbi 53

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

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

TOGAF Ahmad Alharbi 54

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

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

TOGAF Ahmad Alharbi 55

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

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:

TOGAF Ahmad Alharbi 56

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Steps:

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 …

• Best Enterprise Architecture (EA) Tools Reviews 2023 from Gartner:

TOGAF Ahmad Alharbi 57

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Outputs:

A B C D E F
Organizational Tailored Initial Restatement Request for Architecture
model for Architecture Architecture of business Architecture Governance
Enterprise Framework, Repository. principles, Work. Framework.
Architecture. including goals and
Architecture drivers.
Principles.

TOGAF Ahmad Alharbi 58

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Artifacts:

TOGAF Ahmad Alharbi 59

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

Preliminary phase 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”.

TOGAF Ahmad Alharbi 60

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Example of Architecture Principles
Business Principles
➢ Principle 1: Business Continuity:
- Statement: Enterprise operations are maintained in spite of system
interruptions.
- Rationale: As system operations become more pervasive, we become
more dependent on them; therefore, we must consider the reliability of such systems
throughout their design and use. Business premises throughout the enterprise must
be provided with the capability to continue their business functions regardless of
external events. Hardware failure, natural disasters, and data corruption should not
be allowed to disrupt or stop enterprise activities.
- Implications: Dependency on shared system applications mandates that
the risks of business interruption must be established in advance and managed.
Management includes periodic reviews, testing for vulnerability. Applications must
be assessed for criticality and impact on the enterprise mission, in order to
determine what level of continuity is required and what corresponding recovery plan
is necessary

TOGAF Ahmad Alharbi 61

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
L1 & L2 Business Capabilities

1
Core Business
2
Service Exposure
3
Core enablement
4
Enterprise enablement
5
IT Security
1.1 Customer business 3.1 Service catalogue 4.1 Physical asset Mgt
5.1 Strategy,
enablement Mgt
4.2 Enterprise strategic Architecture& Mgt
Mgt
3.2 Service level Mgt
1.2 Customer 2.1 Channels 4.3 Human resource
Mgt
relationship Mgt 3.3 Program & project 5.2 Data protection
Mgt 4.4 Financial Mgt

1.3 Data & Analytics 4.5 Procurement Mgt

3.4 Service operations
Mgt Mgt 4.6 Administrative
support 5.3 Infrastructure
3.5 Non IT & Design 4.7 IT Mgt
1.4 Offering
Mgt
Cloud services 4.8 Governance& risk
3.6 Partner & vendor Mgt 5.4 Infrastructure
Mgt &
2.2 Channel Mgt 4.9 Knowledge Mgt
1.5 Integration Mgt protection
3.7 Business process
Mgt 4.10 Legal Mgt
1.6 Platform 4.11 Corporate comm& 5.5 Identity & access
development 3.8 Customer service branding Mgt
&operations Mgt Mgt
4.12 Marketing

TOGAF Ahmad Alharbi 62

 Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Enablement Capabilities (1 of 3)

4.1.1 4.1.2 4.1.3 4.1.4 4.1.5
Access control Asset lifecycle Tenant Mgt Asset tracking Asset monitoring

1 4.1 Physical asset

Mgt

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5

Strategic planning Strategy alignment Tech strategy creation Business strategy Performance Mgt
[Link] Monetization model [Link] Data strategy creation
2 4.2 Enterprise definition
[Link] Capabilities
strategic Mgt mapping

4.3.1 4.3.2 4.3.3 4.3.4 4.3.5

Organizational Mgt Talent Mgt HR services & admin HR operations & support HRMS
[Link] Interview Mgt [Link] Resource demand
3 4.3 HR 1.
2.
Talent acquisition
Learning & dev
[Link] Recruitment Mgt
[Link] Career & perf
Mgt 3. Student & scholarship
[Link] Onboarding Mgt
[Link] Employee contract

4.4.1 4.4.2 4.4.3 4.4.4 4.4.5

4.4 Financial Mgt General accounting & Fixed asset Purchase to pay Travel & expense Order to cash
4 reporting accounting reimbursement

4.4.6 4.4.7 4.4.8 4.4.9 4.4.10

Payroll Tax Treasury Mgt Planning & Revenue & invoicing
budgeting

TOGAF Ahmad Alharbi 63

 Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Enablement Capabilities (2 of 3)

4.5.1 4.5.2 4.5.3
Define procurement Prepare & process Perform provisioning
strategy tender

5 4.5. Procurement Mgt

4.6.1 4.6.2 4.6.3 4.6.4 4.6.5

Facilities Mgt Travel desk Logistics Meeting catering Reception
[Link] Soft services [Link] Data strategy
1. Attendance Mgt
2. Asset Mgt BYOD
4.6 Administrative
6 support
[Link] Hard services
1. Access Mgt
2. Facilities allocation
& booking

4.7.1 4.7.2 4.7.3 4.7.4 4.7.5

Physical It Mgt Virtual IT Mgt Inhouse soft dev Asset, config & Collaboration tools
[Link] Infrastructure Mgt [Link] Cloud Mgt [Link].1 Soft code release Mgt [Link] Whiteboard &
7 4.7 IT Mgt 1.
2.
Compute
Storage
[Link] Cloud compute generation [Link] License Mgt ideation
3. Network
[Link] Cloud Storage [Link].2 Build & integration [Link] Software config Mgt [Link] Productivity suite
[Link] Cloud Network [Link]. 3 Test case & data [Link] Deploy orchestration [Link] Survey/complaint
[Link] Tenant Mgt Mgt Mgt
[Link] Automated [Link].4 Test execution & [Link] Digital Signature
provisioning automation
[Link].5 Low to no code
4.7.6 4.7.7 IT analysis/design [Link].6 Source control
IT service quality Mgt Mgt [Link].7 Continuous
[Link] Req Mgt integration
[Link] CX Mgt [Link] Continuous deploy
[Link] Customer
prototyping
[Link] Process Mgt
TOGAF Ahmad Alharbi 64
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Enterprise Enablement Capabilities (3 of 3)

4.8.1 4.8.2 4.8.3
Policy Mgt EA governance Data governance
[Link] Security Policy [Link] DM & privacy

8 4.8 Governance & Mgt strategy

[Link] Integration Policy [Link] Build &
risk Mgt Mgt integration
4.8.3.3Test case & data
Mgt
4.9.1 4.9.2 [Link] Test execution &
Co-creation & Document repository automation
collaboration AI search [Link] Low to no code
4.8.3..6 Source Control
[Link] Continuous
4.9 Knowledge
9 Mgt
integration
[Link] Data architecture
& modeling

4.10.1 4.10.3 4.10.4 4.10.5

4.10.2
Corporate Assets & Intellectual Dispute Mgt Legal compliance
Commercial
property

10 4.10 Legal Mgt

4.12.1 4.12.2
4.11.1 Social media Market research
Events Mgt Mgt
4.12 Marketing
4.11 Corporate 4.12.3
11 Comms & 4.11.2 12 Digital marketing
Corporate Mgt automation
branding
TOGAF Ahmad Alharbi 65
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Preliminary phase Summary:

TOGAF Ahmad Alharbi 66

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 67

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Objectives:

1 2

Develop a high-level Obtain approval for a

aspirational vision of the Statement of Architecture
capabilities and business Work.
value to be delivered.

TOGAF Ahmad Alharbi 68

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Approach:

The architecture Emerging If business goals,

vision is an important technologies help to drivers, constraints
selling tool: catch opportunities. and principles are
Clarifying the purpose of the
•
architecture defined understand
• Showing how it will be achieved them, otherwise
High level view of the baseline
establish them.
•
and target architectures
• What is in and what is out the
architecture effort

TOGAF Ahmad Alharbi 69

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Inputs:

Request for Business Organization Tailored Populated

Architecture principles, Model for Architecture Architecture
Work (see business goals Enterprise Framework, Repository.
next slide). and drivers. Architecture. including
Architecture
Principles.

TOGAF Ahmad Alharbi 70

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Request for Architecture Work:

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

TOGAF Ahmad Alharbi 71

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

TOGAF Ahmad Alharbi 72

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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.

TOGAF Ahmad Alharbi 73

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

2: Identify stakeholders, concerns, and business requirement:

➢ 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 This is
• The stakeholders that are involved with the reflected
project in the
• The key roles and responsibilities within the Stakeholder
project Map
• Views and viewpoints need to be developed to
satisfy stakeholder requirements

TOGAF Ahmad Alharbi 74

 Module 3Module
Module Module
Module 1
1 2
Module 2 Module
3 4 Module 5
Module 4 Module 6
Module 5 Module 7
Module 6 Module 8
Module 7 Module 9
Module 8ModuleModule
10 Module 11
9 ModuleModule
10 12Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

3: Confirm business goals, drivers and constraints:

• If they are already defined:

- Make sure they are current
- Clarify ambiguity

• Otherwise define and approve them.

TOGAF Ahmad Alharbi 75

 Module 3Module
Module Module
Module 1
1 2
Module 2 Module
3 4 Module 5
Module 4 Module 6
Module 5 Module 7
Module 6 Module 8
Module 7 Module 9
Module 8ModuleModule
10 Module 11
9 ModuleModule
10 12Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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
(see next slide).

TOGAF Ahmad Alharbi 76

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:
The business capabilities:

TOGAF Ahmad Alharbi 77

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 78

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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

TOGAF Ahmad Alharbi 79

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

6: Define the Scope:

• 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

TOGAF Ahmad Alharbi 80

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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.

TOGAF Ahmad Alharbi 81

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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

TOGAF Ahmad Alharbi 82

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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

TOGAF Ahmad Alharbi 83

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

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

TOGAF Ahmad Alharbi 84

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:

11: Develop Statement of Architecture Work; Secure approval: (see next slide)
• 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

TOGAF Ahmad Alharbi 85

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Steps:
Statement of Architecture Work:

Title Architecture Architectur Overview of Change of Roles, Acceptance Architecture Approvals

project e project Architecture scope responsibilit criteria and project plan
request and description vision procedures ies and procedures and
background and scope deliverables schedule

TOGAF Ahmad Alharbi 86

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase 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

TOGAF Ahmad Alharbi 87

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase Artifacts:

TOGAF Ahmad Alharbi 88

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase 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

TOGAF Ahmad Alharbi 89

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 90

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Vision phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 91

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Objectives:

➢ Develop the Target Business Architecture.

➢ Identify candidate Architecture Roadmap components based upon gaps between Baseline and Target
Business Architectures.

TOGAF Ahmad Alharbi 92

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Approach:

Knowledge of Business Business Check if some of Scope depends If there is no If there is no

the Business Strategy Architecture the Business on existing existing existing strategy
Architecture is a defines what to describes how Architecture work strategy and strategy or or planning,
prerequisite for achieve. to achieve it. is already done planning. planning, identify any
Data, under another identify any existing
Applications discipline (e.g. existing architecture
and Technology business planning architecture definitions, then
architectures. or enterprise definitions, verify and
planning). then verify and update.
update.

TOGAF Ahmad Alharbi 93

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Inputs:

Request for Business Capability Communications Organization Tailored

Architecture principles, goals Assessment. Plan Model for Architecture
Work. and drivers. Enterprise Framework.
Architecture.

Approved Architecture Enterprise Architecture Architecture Draft Architecture

Statement of Principles. Continuum. Repository. Vision. Definition
Architecture Work Document.

TOGAF Ahmad Alharbi 94

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

TOGAF Ahmad Alharbi 95

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

1: Select Reference Models, Viewpoints, and Tools:

• Select resources
• Select viewpoints
• Identify appropriate tools and techniques
• Determine overall modelling process
• Identify Required Service Granularity Level, Boundaries, and Contracts
• Identify Required Catalogs. Matrices, and Diagrams
• Identify Types of Requirement to be Collected

TOGAF Ahmad Alharbi 96

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

2: Develop Baseline Business Architecture Description:

Business Architecture phase Steps:

➢ 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

TOGAF Ahmad Alharbi 97

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

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

TOGAF Ahmad Alharbi 98

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

4: Perform Gap Analysis:

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

TOGAF Ahmad Alharbi 99

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

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

TOGAF Ahmad Alharbi 100

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

6: Resolve Impacts Across the Architecture Landscape

• The impact on any pre-existing architectures

• The impact of any recent changes on the Business Architecture

Identify:
• 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

TOGAF Ahmad Alharbi 101

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

7: Conduct Formal Stakeholder Review:

➢Compare the business architecture with the SOW

TOGAF Ahmad Alharbi 102

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

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

TOGAF Ahmad Alharbi 103

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Steps:

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

TOGAF Ahmad Alharbi 104

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Outputs:

➢ Statement of Architecture Work.

➢ Validated business principles, goals and drivers.

➢ Refined and updated Business Architecture Principles.

➢ Draft Architecture Definition Document (see next slide).

➢ Draft Architecture Requirements Specification (see next slide).

➢ Business Architecture components of an Architecture Roadmap.

TOGAF Ahmad Alharbi 105

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Outputs:
Architecture Definition Document:
➢ Scope
➢ Goals, objectives, and constraints
➢ Architecture Principles
➢ Baseline Architecture
➢ Architecture models for each state to be modeled (BDAT Models)
➢ Rationale and justification for architectural approach
➢ Mapping to Architecture Repository:
- Mapping to Architecture Landscape
- Mapping to reference models
- Mapping to standards
- Re-use assessment
➢ Gap analysis
➢ Impact assessment
➢ Transition Architecture

TOGAF Ahmad Alharbi 106

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Outputs:
Architecture Definition Document - Business Architecture Components -:

➢ Business Architecture, if appropriate – this is a description of the existing Business Architecture

➢ Target Business Architecture, including:
- Organization structure – identifying business locations and relating them to organizational units
- Business goals and objectives – for the enterprise and each organizational unit
- Business functions – a detailed, 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
- Business processes, including measures and deliverables
- Business roles, including development and modification of skills requirements
- Correlation of organization and functions – relate business functions to organizational units in the form of
a matrix report
➢ Views corresponding to the selected viewpoints addressing key stakeholder concerns

TOGAF Ahmad Alharbi 107

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Outputs:
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

TOGAF Ahmad Alharbi 108

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Outputs:
Architecture Requirements Specification - Business Architecture Components -:

➢ Gap analysis results

➢ Technical requirements
➢ Updated business requirements

TOGAF Ahmad Alharbi 109

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Artifacts:

TOGAF Ahmad Alharbi 110

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture –
Catalogs, Matrices and
Diagram:
Catalogs:

TOGAF Ahmad Alharbi 111

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business
Architecture – Strategy/Capability Matrix
Catalogs,
Matrices and
Diagram:
Matrices:

Actor/role Matrix

TOGAF Ahmad Alharbi 112

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Organization Map Diagram
Business
Architecture –
Catalogs,
Matrices and
Diagram:
Diagrams:
Process Flow Diagram

TOGAF Ahmad Alharbi 113

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Business Architecture phase Summary:

➢ Phase B is 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.

TOGAF Ahmad Alharbi 114

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 115

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Information Systems Architecture phase:
➢ Objectives

➢ Approach

TOGAF Ahmad Alharbi 116

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Information Systems Architecture phase Objectives :

1 2
Develop the Target Data Identify candidate
/ Application Architecture Roadmap
Architecture. components based
upon gaps between the
Baseline and Target
Information Systems
Architectures.

TOGAF Ahmad Alharbi 117

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Information Systems Architecture phase Approach:

involves Data and Advocates exist for Data-Driven Sequence

Applications both sequences. Implementation
Architecture, in either (Alternative Approach):
order. • First implement
application systems that
create data
• Then applications that
process the data
• Finally, applications that
archive data

TOGAF Ahmad Alharbi 118

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Information Systems Architecture phase Summary:
The objective of Phase C is to document the fundamental organization of an organization ’s IT System:

A B C D E
Embodied in the Their The principles The principles The principles
major types of relationships governing its governing its governing its
information and
to each other design and design and design and
the application
systems that and the evolution. evolution. evolution.
process them. environment.

TOGAF Ahmad Alharbi 119

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture

01 02
Objectives Inputs

03 05
Steps Outputs

TOGAF Ahmad Alharbi 120

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Objectives:

1 2
Develop the Target Identify candidate
Data Architecture. Architecture Roadmap
components based
upon gaps between the
Baseline and Target
Data Architectures.

TOGAF Ahmad Alharbi 121

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Inputs:

Request for Capability Communications Organization Tailored Data principles.

Architecture Assessment. Plan. model for Architecture
Work. enterprise Framework.
architecture.

Architecture Statement of Architecture Draft Draft Architecture Business

Vision Architecture Repository. Architecture Requirements Architecture
Work. Definition Specification components of an
Document Architecture
Roadmap

TOGAF Ahmad Alharbi 122

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

TOGAF Ahmad Alharbi 123

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

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

TOGAF Ahmad Alharbi 124

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

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

TOGAF Ahmad Alharbi 125

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

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

TOGAF Ahmad Alharbi 126

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

4: Perform Gap Analysis:

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

TOGAF Ahmad Alharbi 127

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

5: Define candidate roadmap components:

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

discipline roadmap within the Opportunities & Solutions phase

TOGAF Ahmad Alharbi 128

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

6: Resolve impacts across the Architecture Landscape:

• 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 Identify:

• The impact of the Data Architecture on other projects

• The impact of other projects on the Data Architecture

TOGAF Ahmad Alharbi 129

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

7: Conduct Formal Stakeholder Review:

• Compare the Data Architecture with the SOW

• Conduct impact analysis on Business and Data Architectures

• Identify constraints on Technology Architecture

TOGAF Ahmad Alharbi 130

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

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

TOGAF Ahmad Alharbi 131

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Steps:

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

TOGAF Ahmad Alharbi 132

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Outputs:

➢ Statement of Architecture Work

➢ Validated data principles, or new data principles

➢ Draft Architecture Definition Document (see next slide)

➢ Draft Architecture Requirements Specification (see next slide )

➢ Data Architecture components of an Architecture Roadmap

TOGAF Ahmad Alharbi 133

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Outputs:
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

TOGAF Ahmad Alharbi 134

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Outputs:
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

TOGAF Ahmad Alharbi 135

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Artifacts:

TOGAF Ahmad Alharbi 136

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Artifacts - Catalogs, Matrices and Diagram - :
Catalogs:

TOGAF Ahmad Alharbi 137

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data Architecture Artifacts - Catalogs, Matrices and Diagram - :
Matrices:

Application/
Data Matrix

TOGAF Ahmad Alharbi 138

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Data
Architecture Artifacts - Data Dissemination
Catalogs, Matrices and Diagram
Diagram - :
Diagrams:

Data Migration Diagram

Diagram

TOGAF Ahmad Alharbi 139

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

Phase C - Data Architecture

Artifacts 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
Energetics models.

TOGAF Ahmad Alharbi 140

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 141

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture

01 02
Objectives Inputs

03 05
Steps Outputs

TOGAF Ahmad Alharbi 142

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C – Application Architecture Objectives:

1 2

Develop the Target Application Identify candidate Architecture

Architecture. Roadmap components based
upon gaps between the Baseline
and Target Application
Architectures.

TOGAF Ahmad Alharbi 143

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Inputs:

Request for Capability Communications Organization Tailored Application

Architecture Assessment. Plan. model for Architecture principles.
Work. enterprise Framework.
architecture.

Statement of Architecture Architecture Draft Draft Architecture Business

Architecture Vision Repository. Architecture Requirements Architecture
Work. Definition Specification components of an
Document Architecture
Roadmap

TOGAF Ahmad Alharbi 144

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

TOGAF Ahmad Alharbi 145

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

1: Select reference models, viewpoints, and tools:

• Review/generate and validate application principles
• Select Application Architecture resources
• Select relevant Application 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 …)
• Address all stakeholders’ concerns
• Identify Required Catalogs, Metrics and Diagrams of Application Building Blocks
• Identify Types of Requirements to be Collected

TOGAF Ahmad Alharbi 146

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

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

TOGAF Ahmad Alharbi 147

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

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

TOGAF Ahmad Alharbi 148

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

4: Perform Gap Analysis:

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

TOGAF Ahmad Alharbi 149

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

5: Define candidate roadmap components:

• Application Architecture roadmap will be used as raw material to support cross

discipline roadmap within the Opportunities & Solutions phase

TOGAF Ahmad Alharbi 150

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

6: Resolve impacts across the Architecture Landscape:

• 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
Identify:

• The impact of the Application Architecture on other projects

• The impact of other projects on the Application Architecture

TOGAF Ahmad Alharbi 151

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

7: Conduct Formal Stakeholder Review:

• Compare the Application Architecture with the SOW

• Conduct impact analysis on Business and Application Architectures

• Identify constraints on Technology Architecture

TOGAF Ahmad Alharbi 152

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

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

TOGAF Ahmad Alharbi 153

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Steps:

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

TOGAF Ahmad Alharbi 154

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Outputs:

A B C D E
Statement of Validated Draft Draft Application
Architecture application Architecture Architecture Architecture
Work - principles, or Definition Requirements components of
updated if new application Document (see Specification an Architecture
necessary - principles next slide) (see next slide ) Roadmap

TOGAF Ahmad Alharbi 155

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Outputs:
Architecture Definition Document – Application Architecture Components:

Baseline Target Application Application

Application Architecture, Architecture
Architecture, if including: views
• Process systems mode
appropriate • Place systems model
• Time systems model
• People systems model

TOGAF Ahmad Alharbi 156

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Outputs:
Architecture Requirements Specification – Application Architecture Components:

A B C D E
Gap analysis Application Potential Constraints on Updated
results interoperability changes in the the Technology business/applic
requirements Business Architecture ation/data
Architecture requirements, if
appropriate

TOGAF Ahmad Alharbi 157

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Artifacts:

TOGAF Ahmad Alharbi 158

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Artifacts - Catalogs, Matrices and Diagram - :
Catalogs:

TOGAF Ahmad Alharbi 159

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Artifacts - Catalogs, Matrices and Diagram - :
Matrices:
Application
Interaction
Matrix

Application/Or
ganization
Matrix

TOGAF Ahmad Alharbi 160

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Artifacts - Catalogs, Matrices and Diagram - :
Diagrams:

Process/Applicati
on Realization
Diagram

Application
Communication
Diagram

TOGAF Ahmad Alharbi 161

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Phase C - Application Architecture Summary:

1 2

This phase defines the kinds of The goal is to define what

applications necessary to kinds of applications are
process the data and support relevant and what those
the business applications need to do

TOGAF Ahmad Alharbi 162

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 163

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 164

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Objectives:

1 2
Develop the Target Technology Identify candidate Architecture
Architecture. Roadmap components based
upon gaps between the
Baseline and Target Technology
Architectures.

TOGAF Ahmad Alharbi 165

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Approach:

Consider Emerging Review the Technology

Technologies. Architecture Resources
• Evolution of new available in the Architecture
technologies is a major driver Repository:
for • 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)

TOGAF Ahmad Alharbi 166

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Inputs:

Request for Capability Communications Organization

Architecture Assessment. Plan Model for
Work. Enterprise
Architecture.

Tailored Statement of Technology Architecture Architecture

Architecture Architecture Work principles. Vision. Repository.
Framework.

TOGAF Ahmad Alharbi 167

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Inputs:

• Draft Architecture Definition Document, containing:

- Baseline and Target (Business, Application and Data) Architecture (detailed)
- Baseline and Target (Technology) Architecture (high-level)
•
• Draft Architecture Requirements Specification .

• Business, Data, and Application Architecture components of an Architecture

Roadmap.

TOGAF Ahmad Alharbi 168

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

TOGAF Ahmad Alharbi 169

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

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

TOGAF Ahmad Alharbi 170

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

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

TOGAF Ahmad Alharbi 171

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

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

TOGAF Ahmad Alharbi 172

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

4: Perform Gap Analysis

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

TOGAF Ahmad Alharbi 173

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture phase Steps:

5: Define candidate roadmap components

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

discipline roadmap within the Opportunities & Solutions phase

TOGAF Ahmad Alharbi 174

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Steps:

6: Resolve impacts across the Architecture Landscape:

• 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 Identify:

• The impact of the Technology Architecture on other projects

• The impact of other projects on the Technology Architecture

TOGAF Ahmad Alharbi 175

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Steps:

7: Conduct Formal Stakeholder Review:

• Compare the Technology Architecture with the SOW

• Does the Technology Architecture support other architecture domains?

TOGAF Ahmad Alharbi 176

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Steps:

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

TOGAF Ahmad Alharbi 177

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Steps:

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

TOGAF Ahmad Alharbi 178

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Outputs:

A B C D E
Statement of Validated Draft Architecture Draft Technology
Architecture Work, technology Definition Architecture Architecture
updated if principles or new Document. Requirements components of an
necessary. technology Specification. Architecture
principles. Roadmap.

TOGAF Ahmad Alharbi 179

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Outputs:
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.

TOGAF Ahmad Alharbi 180

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Outputs:
Architecture Requirements Specification – Technology Architecture Components:

• Gap analysis results.

• Updated technology requirements.

TOGAF Ahmad Alharbi 181

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Artifacts - Catalogs, Matrices and Diagram - :

TOGAF Ahmad Alharbi 182

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Artifacts - Catalogs, Matrices and Diagram - :
Catalogs:

TOGAF Ahmad Alharbi 183

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Artifacts - Catalogs, Matrices and Diagram - :
Matrices:

Application/
Technology
Matrix

TOGAF Ahmad Alharbi 184

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Technology Architecture Artifacts - Catalogs, Matrices and Diagram - :
Diagrams:
Network and
Communications
Diagram

Processing Diagram

TOGAF Ahmad Alharbi 185

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

Technology Architecture 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 .

TOGAF Ahmad Alharbi 186

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 187

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
E. Opportunities and Solutions phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 188

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Objectives:

1 2 3
Determine whether an
Generate the initial Define the overall
incremental approach
complete version of SBBs.
is required
the Architecture • If so, identify Transition
Roadmap Architectures

TOGAF Ahmad Alharbi 189

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Approach:
Key concepts for transitioning from developing to delivering a Target Architecture:

A B C D
Architecture Work Packages: Transition Implementation
Roadmap: logical group of changes Architectures: and Migration
lists individual work necessary to realize the describes the enterprise Plan:
packages in a timeline Target Architecture. at an architecturally provides a
that will realize the significant state schedule of the
Target Architecture. between the Baseline projects that will
and Target realize the Target
Architectures. Architecture.

TOGAF Ahmad Alharbi 190

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Inputs:

Product Request for Capability Communications Planning Governance

Information. Architecture Assessment. Plan Methodologies. models and
Work. frameworks.

Statement of Architecture Architecture Draft Architecture Draft Architecture

Architecture Vision. Repository. Definition Definition
Work. Document. Document.

TOGAF Ahmad Alharbi 191

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Inputs:

1 2

Change Requests for Candidate Architecture

existing programs and Roadmap components from
projects. Phases B,C, and D.

TOGAF Ahmad Alharbi 192

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

TOGAF Ahmad Alharbi 193

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 194

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

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

TOGAF Ahmad Alharbi 195

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 196

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 197

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 198

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 199

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 200

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 201

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 202

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 203

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Steps:

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

TOGAF Ahmad Alharbi 204

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Outputs:

Statement of Architecture Draft Draft Capability Architecture Implementati

Architecture Vision. Architecture Architecture Assessment, Roadmap, on &
Work. Definition Requirements including: including: Migration
Document, Specification, • Business • Work Package Plan (outline).
Capability portfolio
including:- including: • Identification of
• Transition - Consolidated Assessment Transition
Architecture Gaps, Solutions • IT Architectures, if any
and Dependencies Capability • implementation
s, if any Recommendations
Assessment Assessment

TOGAF Ahmad Alharbi 205

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Artifacts - Catalogs, Matrices and Diagram - :

TOGAF Ahmad Alharbi 206

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and Solutions phase Artifacts - Catalogs, Matrices and Diagram - :
Diagrams:
Project Context Diagram

Benefits Diagram

TOGAF Ahmad Alharbi 207

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Opportunities and
Solutions phase 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.

TOGAF Ahmad Alharbi 208

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 209

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
F. Migration Planning phase :

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 210

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Objectives:

1 2
Finalize the Architecture Finalize the Implementation
Roadmap. and Migration Plan.

3 4
Align the Implementation and Ensure that the business value
Migration Plan with the and cost of work packages and
enterprise's management Transition Architectures is
approach. understood by key stakeholders.

TOGAF Ahmad Alharbi 211

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Approach:

The focus is Activities include

finalization of the the
Implementation dependencies,
and Migration costs, and
plan initially benefits of the
prepared in various
Phase E. migration
projects.

TOGAF Ahmad Alharbi 212

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Inputs:

Request for Capability Communications Organization Model

Governance models
Architecture Work. Assessment. Plan for Enterprise
and frameworks.
Architecture.

Tailored Draft Architecture

Statement of Architecture Architecture Vision.
Architecture Definition Document
Architecture Work Repository.
Framework. Transition Architectures, if
any

TOGAF Ahmad Alharbi 213

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Inputs:

➢ 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

➢ Implementation and Migration Plan (outline).

TOGAF Ahmad Alharbi 214

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

TOGAF Ahmad Alharbi 215

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:
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

TOGAF Ahmad Alharbi 216

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

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
TOGAF Ahmad Alharbi 217
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

3: Estimate Resource Requirements, Project Timings, and

Availability/Delivery Vehicle
• 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

TOGAF Ahmad Alharbi 218
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

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

TOGAF Ahmad Alharbi 219

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

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

TOGAF Ahmad Alharbi 220

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:

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

TOGAF Ahmad Alharbi 221

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase Steps:
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

TOGAF Ahmad Alharbi 222

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase 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.

TOGAF Ahmad Alharbi 223

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Migration Planning phase 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.

TOGAF Ahmad Alharbi 224

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 225

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
G. Implementation Governance phase :

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 226

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase 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.

TOGAF Ahmad Alharbi 227

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase 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.

TOGAF Ahmad Alharbi 228

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase 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.
• Architecture Requirements Specification.
• Architecture Roadmap.
• Implementation Governance Model.

TOGAF Ahmad Alharbi 229

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Inputs:

➢ Architecture Contract.

➢ Request for Architecture Work from E and F.

➢ Implementation and Migration Plan.

TOGAF Ahmad Alharbi 230

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

TOGAF Ahmad Alharbi 231

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

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

TOGAF Ahmad Alharbi 232

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

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

TOGAF Ahmad Alharbi 233

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

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

TOGAF Ahmad Alharbi 234

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

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

TOGAF Ahmad Alharbi 235

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

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

TOGAF Ahmad Alharbi 236

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase Steps:

6: Do post-implementation review, close the implementation

• Conduct post-implementation reviews

• Publish reviews and close projects

TOGAF Ahmad Alharbi 237

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase 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

TOGAF Ahmad Alharbi 238

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Implementation Governance phase 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.

TOGAF Ahmad Alharbi 239

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 240

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
H. Architecture Change Management phase:

01 02 03
Objectives Approach Inputs

04 05
Steps Outputs

TOGAF Ahmad Alharbi 241

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase 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.

TOGAF Ahmad Alharbi 242

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Approach
Change Management Process:

➢ This process will typically provide for the continual monitoring of such things as governance
requests, new developments in technology, and changes in the business environment. When
changes are identified, change management will determine whether to formally initiate a new
architecture evolution cycle.

➢ The Enterprise Architecture change management process needs to determine how changes
are to be managed, what techniques are to be applied, and what methodologies used. The
process also needs a filtering function that determines which phases of the architecture
development process are impacted by requirements.

➢ There are many valid approaches to change management, and various management
techniques and methodologies that can be used to manage change; for example, project
management methods such as PRINCE2, service management methods such as ITIL, and
many others. An enterprise that already has a change management process in place in a field
other than architecture (for example, in systems development or project management) may
well be able to adapt it for use in relation to architecture.

TOGAF Ahmad Alharbi 243

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase
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

➢ determine whether a change is simplification, incremental, or rearchitecting:

- Register all events that may impact the architecture
- Allocate resources and management
- Assess what should be done
- Evaluate the impact

TOGAF Ahmad Alharbi 244

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase 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.
➢ Architecture Roadmap.
➢ Change Requests (due to technology changes, business changes, lessons learned):
- Change Request Contents (Description of the proposed change, Rationale for the proposed
change and Impact assessment of the proposed change including Repository reference number)

TOGAF Ahmad Alharbi 245

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Inputs:

➢ Implementation Governance Model.

➢ Architecture Contract.

➢ Compliance Assessments.

➢ Implementation and Migration Plan.

TOGAF Ahmad Alharbi 246

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

TOGAF Ahmad Alharbi 247

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

1: Establish Value Realization Process

➢Influence business projects to exploit the Enterprise Architecture for value realization
(outcomes)

TOGAF Ahmad Alharbi 248

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

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

TOGAF Ahmad Alharbi 249

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

3: Manage Risks

• Manage Enterprise Architecture risks and provide recommendations

TOGAF Ahmad Alharbi 250

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

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

TOGAF Ahmad Alharbi 251

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

5: Develop Change Requirements to Meet Performance Targets

➢ Make recommendations on change requirements to

- Meet performance requirements
- Develop a position to act

TOGAF Ahmad Alharbi 252

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

6: Manage Governance Process

➢ Arrange meeting of Architecture Board

➢ Hold meeting of the Architecture Board to decide on handling change

TOGAF Ahmad Alharbi 253

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Steps:

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

TOGAF Ahmad Alharbi 254

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase 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.

TOGAF Ahmad Alharbi 255

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Architecture Change Management phase Summary:
➢ Ensures that changes to the architecture are managed in a cohesive and controlled manner.

➢ Establishes and supports the architecture to provide flexibility to evolve the architecture rapidly in responses to changes in
technology and business.

TOGAF Ahmad Alharbi 256

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 257

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase:

01 02 03
Overview Objectives Approach

04 05 06
Inputs Steps Outputs

TOGAF Ahmad Alharbi 258

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Overview:

➢ Technically, it’s a phase. But it’s constant.

➢ Continuous process of handling change during any phase of the ADM

process.

➢ The purpose is: ensure the process is sustained through all phases.

➢ The purpose is: manage change while the ADM cycle is in progress.

➢ Requirements Management is the process that manages the repository.

TOGAF Ahmad Alharbi 259

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Objectives:

➢ Ensure that the Requirements Management process is sustained and operates

for all relevant ADM phases.

➢ Manage architecture requirements identified during any execution of the ADM

cycle or a phase.

➢ Ensure that the requirements are available for use by each phase as the phase
executed.

TOGAF Ahmad Alharbi 260

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase 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.

TOGAF Ahmad Alharbi 261

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

Step Requirements Management Steps ADM Phases Steps

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

Step 2 Baseline requirements

Step 3 Monitor baseline requirements

Step 4 Identify changed requirements

Step 5 Identify changed requirements and record priorities

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

Step 7 Implement requirements arising from Phase H

TOGAF Ahmad Alharbi 262

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

Step Requirements Management Steps ADM Phases Steps

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

Step 9 Implement change in the current phase

Step 10 Assess and revise gap analysis for past phases

TOGAF Ahmad Alharbi 263

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

1: Identify/document requirements (ADM Phase Step)

➢ Use Business Scenarios or an equivalent technique

TOGAF Ahmad Alharbi 264

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

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

TOGAF Ahmad Alharbi 265

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

3: Monitor baseline requirements (Requirements Management Step)

TOGAF Ahmad Alharbi 266

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

4: Identify changed requirement (ADM Phase Step)

➢ Remove or re-assess priorities

➢ Add requirements and re-assess priorities

➢ Modify existing requirements

TOGAF Ahmad Alharbi 267

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

5: Identify changed requirements and record priorities (Requirements

Management Step)
➢ Identify changed requirements

➢ Record new priorities

➢ Resolve conflicts

➢ Generate Requirements Impact Statement

TOGAF Ahmad Alharbi 268

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:

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

(ADM Phase Step)

➢ Decide whether to implement the change of defer it to a future ADM cycle

➢ Issue new version of Requirements Impact Statement

TOGAF Ahmad Alharbi 269

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Steps:
7: Implement requirements arising from Phase H (ADM Phase Step)

8: Update the Architecture Requirements Repository with information relating

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

9: Update the Architecture Requirements Repository with information relating

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

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

➢ Gap analysis may generate some requirements

TOGAF Ahmad Alharbi 270

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Outputs:
➢ Updated Architecture Requirements Specification.

➢ Requirements Impact Statement.

TOGAF Ahmad Alharbi 271

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases
Requirements Management phase Summary:
➢ Requirements Management is an ongoing activity of the ADM.

➢ The Requirements Repository contains the current requirements for the Target Architecture.

➢ The Requirements Repository contains the current requirements for the Target Architecture.

TOGAF Ahmad Alharbi 272

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases

TOGAF Ahmad Alharbi 273

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

➢ In this phase we can define the EA Team and EA Tool ?

➢ What is the vision ?

History Overview Basic concept
➢ Where are we now ?

➢ Where do we want to be ?

➢ How do we get there ?

➢ Take a time ?

➢ Did we get there ?

➢ How do we keep the momentum going ?

TOGAF Ahmad Alharbi 274

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 275

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 276

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 277

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 278

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 279

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 280

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 281

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 282

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 283

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 284

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 285

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 286

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Phases Test yourself:

TOGAF Ahmad Alharbi 287

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Executive summary

EA Framework

EA
EA Service Model

EA Capability Map

Operating EA Organization

Model EA Governance Structure

EA Processes

EA Tools

TOGAF Ahmad Alharbi 288

EA Framework

Vision and Mission

EA Mandate

Strategic
Objectives KPIs

EA Services

EA Domains EA Capability Model Maturity Model

EA operating Model
EA Organization EA Governance EA Process Tools & Metamodel
EA org chart, roles and Decision making bodies charters and processes describing the steps and activities
Software's, applications and tools deployed
Responsibilities and position charters planning interaction model required to deliver the EA Services by EA resources to perform their tasks
TOGAF Ahmad Alharbi 289
EA Service Model

[Link] planning and performance management

1.2 Aligning EA Strategy with Org

1.1 Creating the EA Roadmap
Strategy

2. Architecture definition
2.1 Delivering Architecture Models (As-is And
2.2 Managing Application Lifecycle Roadmap
To-be)

2.3 Managing Technology Lifecycle Roadmap

3. Project support, architecture delivery and alignment

3.1 Evaluating Technology And Application
3.3 Evaluating Project compliance against EA target
Purchase Request

3.3 Architecture Consulting

4. Assets and tools management 5. EA awareness

4.1 Supporting Architecture Tools 5.1 Enhancing EA Team Skill

4.2 Defining and Updating Architecture Assets and

5.2 EA Broadcasting
Artifacts

TOGAF Ahmad Alharbi 290

 By Ahmad Alharbi
M: 0555004772

EA Organization

Courses,
Certificates and Governance EA GM Consultants
skills:
- TOGAF
- COBIT
- GEIT

Architecture &
Planning Department EA Tools Dept Partner Department
Research Dept

Arc: Oversee the

development of current and
Manage EA Docs & the Act as the connection
target architectures.
EA planning section point between EA
Manage the EA Tools Res: Research and identify
across project-related function and other related
latest technologies and
services verticals
standards periodically and
on-demand.
Courses, Certificates and skills:
Courses, Certificates and skills: Courses, Certificates and skills: - TOGAF Courses, Certificates and skills:
- TOGAF - TOGAF - Business Architecture Level1 - TOGAF
- PMP - Aris - AWS - Communications skills
- PMI Risk Management - Alfabet - ITIL Foundation - BPMA or BPMP
- Change Management Cert Program - MEGA - DAMA
- SPP - VMware
 Blueprints and
Roadmap Doc
Executive summary

Context and Objectives ( Context, Methodology and EA Objectives and Design Objectives )
Architecture Current State ( ) BDAT

Target Architecture Blueprints ( ) BDAT

EA Roadmap ( Gap Analysis, Roadmap Summary, EA Program)

TOGAF Ahmad Alharbi 292

 EA Setup
Plan
TOGAF Ahmad Alharbi 293
 EA Setup plan
# Desc OWNER
EA Planning EA Depts
01 Establish plan for EA Portal (About EA, How we work, Performance page, Tracker …etc)
02 Establish plan for How we work (User guide) to new employee/ replacement employee
Define and establish operating model document this doc will be contain (EA Service model, EA Organization, EA governance structure, EA
03
process and template for each process …etc)
Review, define and establish EA Blueprint document this doc will be contain (Executive summary, context and objectives, Architecture
04
current state, target architecture blueprints, Gap analysis and EA Programs)
05 Initial Architecture Repository
06 Stakeholder management

Business and Application layer SMEs Team

01 Architecture definition document (Business and Application) B & A architect
02 Review, define and Establish capability map (Business and Application) B & A architect
03 Establish RFP Checklist B & A architect and other domains
Update the repository (business service/function catalog, Strategy/Capability matrix, process flow
04 B & A architect
diagram, Application catalogue Software Distribution diagram, application function matrix …etc)

TOGAF Ahmad Alharbi 294

 Module 04

ADM Deliverables
and Building Blocks
ADM Deliverables and Building Blocks

TOGAF Ahmad Alharbi 295

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

ADM Deliverables Overview

➢ The deliverables that will typically be consumed and produced across the TOGAF
ADM cycle.

➢ As deliverables are typically the contractual or formal work products of an

architecture project, it is likely that these deliverables will be constrained or altered by
any overarching project or process management for the enterprise (such as CMMI,
PRINCE2, PMBOK, or MSP).

TOGAF Ahmad Alharbi 296

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Deliverable Output from... Input to...
Architecture Building Blocks F, H A, B, C, D, E

Architecture Contract - -

Architecture Definition Document B, C, D, E, F C, D, E, F, G, H

Architecture Principles Preliminary, A, B, C, D Preliminary, A, B, C, D, E, F, G, H

Architecture Repository Preliminary Preliminary, A, B, C, D, E, F, G, H,

Requirements Management
Architecture Requirements B, C, D, E, F, Requirements C, D, Requirements Management
Specification Management
Architecture Roadmap B, C, D, E, F B, C, D, E, F

Architecture Vision A, E B, C, D, E, F, G, H, Requirements

Management

TOGAF Ahmad Alharbi 297

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Deliverable Output from... Input to...
Business Principles, Business Goals, and Business Preliminary, A, B A, B
Drivers
Capability Assessment A, E B, C, D, E, F

Change Request F, G, H -

Communications Plan A B, C, D, E, F

Compliance Assessment G H

Implementation and Migration Plan E, F F

Implementation Governance Model F G, H

Organizational Model for Enterprise Architecture Preliminary Preliminary

TOGAF Ahmad Alharbi 298

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Deliverable Output from... Input to...

Request for Architecture Work Preliminary, F, H A, G

Requirements Impact Requirements Management Requirements Management

Assessment

Solution Building Blocks G A, B, C, D, E, F, G

Statement of Architecture Work A, B, C, D, E, F, G, H A, B, C, D, E, F, G, H

A, B, C, D, E, F, G, H Preliminary, A Preliminary, A, B, C, D, E, F, G, H,
Requirements Management

TOGAF Ahmad Alharbi 299

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Building Blocks
➢ A Building Block is a package of functionality defined to meet the business needs across an organization.

➢ A Building Block usually has a type that corresponds to the enterprise’s content Metamodel (such as actor, business
service, application, or data entity).

➢ A Building Block has a defined boundary and is generally recognizable as "a thing" by domain experts.

➢ A Building Block may interoperate with other, interdependent Building Blocks.

➢ A good Building Block has the following characteristics:

- It considers implementation and usage, and evolves to exploit technology and standards
- It may be assembled from other Building Blocks
- It may be a subassembly of other Building Blocks
- Ideally a Building Block is reusable and replaceable, and well specified

➢ Building Blocks types:

- Architecture Building Blocks (ABBs) - Solution Building Blocks (SBBs)

TOGAF Ahmad Alharbi 300

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Architecture Building Blocks (ABBs):

➢ Characteristics
- Capture architecture requirements, e.g. business, data, application and technology requirements
- Direct and guide the development of SBBs

➢ Specification content
- Fundamental functionality and attributes: semantic, unambiguous, including security, capability and
manageability
- Interfaces: chosen set, supplied
- Interoperability and relationship with other Building Blocks
- Dependent Building Blocks with required functionality and named user interfaces
- Map to business/organizational entities and policies

TOGAF Ahmad Alharbi 301

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Solution Building Blocks (SBBs):

➢ Characteristics
- Define what products and components will implement the functionality
- Define the implementation
- Fulfil business requirements
- Are product- or vendor-aware

➢ Specification content
- Are product- or vendor-aware
- Interfaces
- Required SBBs used with required functionality and names of the interfaces used
- Mapping from the SBBs to the IT topology and operational policies
- Specifications of attributes shared across the environment (not to be confused with functionality) such as
security, manageability, localizability, scalability
- Performance, configurability
- Design drivers and constraints, including the physical architecture
- Relationships between SBBs and ABBs
TOGAF Ahmad Alharbi 302
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Deliverables and Building Blocks

Building Blocks Summary

➢ The concept of Building Blocks is central to the approach recommended for designing a
system architecture.

➢ Architecture BBs are used to describe concepts and logic. Solution BBs describe physical
solutions.

➢ The way in which Building Blocks are assembled will vary widely between individual
architectures. Every organization must decide for itself what arrangement of Building
Blocks works best for it.

TOGAF Ahmad Alharbi 303

 Module 05

ADM Guidelines and

Techniques, The
Enterprise Continuum
ADM Guidelines and Techniques, The Enterprise Continuum

TOGAF Ahmad Alharbi 304

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development:

➢ Architecture Principles: principles for the use and deployment of IT resources across the enterprise -
describes how to develop the set of general rules and guidelines for the architecture being developed
➢Stakeholder Management: describes stakeholder management, an important discipline that
successful architecture practitioners can use to win support for their projects
➢Architecture Patterns: provides guidance on using architectural patterns
➢Gap Analysis: describes the technique known as gap analysis; it is widely used in the TOGAF ADM to
validate an architecture that is being developed
➢Migration Planning Techniques: describes a number of techniques to support migration planning in
Phases E and F
➢Interoperability Requirements: describes a technique for determining interoperability requirements

TOGAF Ahmad Alharbi 305

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development:

• Business Transformation Readiness Assessment: describes a technique for identifying

business transformation issues

• Risk Management: describes a technique for managing risk during an architecture/business

transformation project

• Capability-Based Planning: describes the technique of capability-based planning

TOGAF Ahmad Alharbi 306

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Architecture Principles):
Architecture Principles Overview

➢ Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform
and support the way in which an organization sets about fulfilling its mission.

➢ Each Principles should be contained (Statement, Rationale and Implications).

➢ Depending on the organization, principles may be established within different domains and at different
levels. Two key domains inform the development and utilization of architecture:
- Enterprise Principles provide a basis for decision-making throughout an enterprise, and inform how
the organization sets about fulfilling its mission
- Architecture Principles are a set of principles that relate to architecture work

TOGAF Ahmad Alharbi 307

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Architecture Principles):
Developing Architecture Principles

➢ Architecture Principles are typically developed by the Enterprise Architects, in conjunction with the key stakeholders,
and are approved by the Architecture Board.

➢ Specifically, the development of Architecture Principles is typically influenced by the following:

- Enterprise mission and plans: the mission, plans, and organizational infrastructure of the enterprise
- Enterprise strategic initiatives: the characteristics of the enterprise its strengths, weaknesses, opportunities, and
threats and its current enterprise-wide initiatives (such as process improvement and quality management)
- External constraints: market factors (time-to-market imperatives, customer expectations, etc.); existing and potential
legislation
- Current systems and technology: the set of information resources deployed within the enterprise, including systems
documentation, network configuration diagrams, policies, and procedures
- Emerging industry trends: predictions about economic, political, technical, and market factors that influence the
enterprise environment

TOGAF Ahmad Alharbi 308

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Architecture Principles):
Five Elements of a Good Principle

➢ Understandability: the underlying tenets can be quickly grasped and understood by individuals throughout the
organization. The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized
➢Robustness: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards
to be created. Each principle should be sufficiently definitive and precise to support consistent decision-making in complex,
potentially controversial situations
➢Completeness: every potentially important principle governing the management of information and technology for the
organization is defined - the principles cover every situation perceived
➢Consistency: The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not
be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle
statement should be carefully chosen to allow consistent yet flexible interpretation
➢Stability: principles should be enduring, yet able to accommodate changes

TOGAF Ahmad Alharbi 309

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Architecture Principles):
Example of Architecture Principles

Business Principles
❖ Principle 1: Business Continuity:
- Statement: Enterprise operations are maintained in spite of system interruptions.
- Rationale: As system operations become more pervasive, we become more dependent on them; therefore, we must consider the
reliability of such systems throughout their design and use. Business premises throughout the enterprise must be provided with the
capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption
should not be allowed to disrupt or stop enterprise activities.
- Implications: Dependency on shared system applications mandates that the risks of business interruption must be established in
advance and managed. Management includes periodic reviews, testing for vulnerability. Applications must be assessed for criticality and
impact on the enterprise mission, in order to determine what level of continuity is required and what corresponding recovery plan is
necessary
❖ Principle 1: Business Continuity:
- Statement: Enterprise information management processes comply with all relevant laws, policies, and regulations
- Rationale: Enterprise policy is to abide by laws, policies, and regulations. This will not preclude business process improvements
that lead to changes in policies and regulation
- Implications: The enterprise must be mindful to comply with laws, regulations, and external policies regarding the collection,
retention, and management of data
TOGAF Ahmad Alharbi 310
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Stakeholders Management):
Overview

• The most powerful stakeholders can be identified early and their input can then be used to shape the
architecture; this ensures their support and improves the quality of the models produced

• Support from the more powerful stakeholders will help the engagement win more resources, thus making
the architecture engagement more likely to succeed

• By communicating with stakeholders early and frequently, the architecture team can ensure that they
fully understand the architecture process, and the benefits of Enterprise Architecture; this means they can
support the architecture team more actively when necessary

• The architecture team can identify conflicting or competing objectives among stakeholders early and
develop a strategy to resolve the issues arising from them
TOGAF Ahmad Alharbi 311
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Stakeholders Management):
Steps in the Stakeholder Management Process:

• Identify Stakeholders: The first task is to brainstorm who the main Enterprise Architecture stakeholders are. As part of
this, think of all the people who are affected by it, who have influence or power over it, or have an interest in its successful
or unsuccessful conclusion
• Classify Stakeholder Positions: Develop a good understanding of the most important stakeholders and record this
analysis for reference and refresh during the project
• Determine Stakeholder Management Approach: The previous steps identified a long list of people and
organizations that are affected by the Enterprise Architecture project. This step enables the team to easily see which
stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters of the
initiative
• Tailor Engagement Deliverables: It is important to pay particular attention to stakeholder interests by defining
specific catalogs, matrices, and diagrams that are relevant for a particular Enterprise Architecture
• model. This enables the architecture to be communicated to, and understood by, all the stakeholders
, and enables them to verify that the Enterprise Architecture initiative will address their concerns

TOGAF Ahmad Alharbi 312

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Architecture Patterns):
Overview:

• A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably
be useful in others" (Source: Analysis Patterns - Re-usable Object Models, by M. Fowler).

• In the TOGAF standard, patterns are a way of 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.

• Patterns offer the promise of helping the architect to identify combinations of Architecture and/or
Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past and
may provide the basis for effective solutions in the future.

TOGAF Ahmad Alharbi 313

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Gap Analysis):
Overview:

• A gap analysis is a method of assessing the differences in performance between a business' information
systems or software applications to determine whether business requirements are being met and, if not,
what steps should be taken to ensure they are met successfully. Gap refers to the space between "where
we are" (the present state) and "where we want to be" (the target state).

• The technique known as gap analysis is widely used in the TOGAF Architecture Development Method
(ADM) to validate an architecture that is being developed. The basic premise is to highlight a shortfall
between the Baseline Architecture and the Target Architecture; that is, items that have been deliberately
omitted, accidentally left out, or not yet defined.

TOGAF Ahmad Alharbi 314

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Gap Analysis):
Potential sources of gaps include:

• Business domain gaps:

- People gaps (e.g., cross-training requirements)
- Process gaps (e.g., process inefficiencies)
- Tools gaps (e.g., duplicate or missing tool functionality)
- Information gaps
- Measurement gaps
- Financial gaps
• Data domain gaps:
- Data not located where it is needed
- Not the data that is needed
- Data relationship gaps
• Applications impacted, eliminated, or created
• Technologies impacted, eliminated, or created
TOGAF Ahmad Alharbi 315
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Migration Planning Techniques):
Overview:

• Implementation Factor Assessment & Deduction Matrix: The technique of creating an Implementation Factor Assessment and Deduction
matrix can be used to document factors impacting the architecture Implementation and Migration Plan. The matrix should include a list of the
factors to be considered, their descriptions, and the deductions that indicate the actions or constraints that must be taken into consideration when
formulating the plans. Factors typically include (Risks, Issues, Assumptions, Dependencies, Actions and Impacts)

• Architecture Definition Increments Table: The technique of creating an Architecture Definition Increments table allows the architect to plan
a series of Transition Architectures outlining the status of the Enterprise Architecture at specified times.

• Transition Architecture State Evolution Table: The technique of creating the Transition Architecture State Evolution table allows the
architect to show the proposed state of the architectures at various levels using the defined taxonomy. A table should be drawn, listing the
services from the taxonomy used in the enterprise, the Transition Architectures, and proposed transformations

• Business Value Assessment Technique: A technique to assess business value is to draw up a matrix based on a value index dimension and
a risk index dimension. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and
competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure.
Each criterion should be assigned an individual weight
TOGAF Ahmad Alharbi 316
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Interoperability Requirements):
Overview:

➢ A definition of interoperability is "the ability to share information and services". Defining the degree to which the
information and services are to be shared is a very useful architectural requirement, especially in a complex
organization and/or extended enterprise.

➢ The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows:
➢ In the Architecture Vision (Phase A), the nature and security considerations of the information and service exchanges are first revealed within
the business scenarios
❖ In the Business Architecture (Phase B), the information and service exchanges are further defined in business terms
❖ In the Data Architecture (Phase C), the content of the information exchanges is detailed using the corporate data and/or information
exchange model
❖ In the Application Architecture (Phase C), the way that the various applications are to share the information and services is specified
❖ In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are
specified
❖ In Opportunities & Solutions (Phase E), the actual solutions are selected
❖ In Migration Planning (Phase F), the interoperability is logically implemented
TOGAF Ahmad Alharbi 317
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Business Transformation Readiness Assessment):
Overview:

• Enterprise Architecture is a major endeavor within an organization and most often an innovative Architecture Vision (Phase A) and
supporting Architecture Definition (Phases B to D) will entail considerable change.

• Understanding the readiness of the organization to accept change, identifying the issues, and then dealing with them in the
Implementation and Migration Plans is key to successful architecture transformation in Phases E and F. This will be a joint effort
between corporate (especially human resources) staff, lines of business, and IT planners.

• The recommended activities in an assessment of an organization's readiness to address business transformation are:
- Determine the readiness factors that will impact the organization
- Present the readiness factors using maturity models
- Assess the readiness factors, including determination of readiness factor ratings
- Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
- Work these actions into Phase E and F Implementation and Migration Plan

TOGAF Ahmad Alharbi 318

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Business Transformation Readiness Assessment):
Determine Readiness Factors:
▪ This can be best achieved through the conduct of a facilitated workshop with individuals from different parts of the organization. It is
important that all perspectives are sought as the issues will be varied. In this workshop it is very useful to start off with a tentative list
of factors that participants can re-use, reject, augment, or replace. An example set of factors follows:
❖ Vision is the ability to clearly define and communicate what is to be achieved
❖ Desire, Willingness, and Resolve is the presence of a desire to achieve the results, willingness to accept the impact of doing the work, and the
resolve to follow through and complete the endeavor
❖ Need, in that there is a compelling need to execute the endeavor
❖ Business Case exists that creates a strong focus for the project, identifying benefits that must be achieved and thereby creating an imperative to
succeed
❖ Funding, in the form of a clear source of fiscal resources, exists that meets the endeavor's potential expenditures
❖ Sponsorship and Leadership exists and is broadly shared
❖ Governance is the ability to engage the involvement and support of all parties with an interest in or responsibility to the endeavor with the
objective of ensuring that the corporate interests are served, and the objectives achieved
❖ Accountability is the assignment of specific and appropriate responsibility, recognition of measurable expectations by all concerned parties, and
alignment of decision-making with areas of responsibility and with where the impact of the decisions will be felt

TOGAF Ahmad Alharbi 319

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Business Transformation Readiness Assessment):
Determine Readiness Factors:
• This can be best achieved through the conduct of a facilitated workshop with individuals from different parts of the
organization. It is important that all perspectives are sought as the issues will be varied. In this workshop it is very useful
to start off with a tentative list of factors that participants can re-use, reject, augment, or replace. An example set of
factors follows:
❖ Workable Approach and Execution Model is an approach that makes sense relative to the task, with a supporting environment, modeled
after a proven approach
❖ IT Capacity to Execute is the ability to perform all the IT tasks required by the project, including the skills, tools, processes, and
management capability
❖ Enterprise Capacity to Execute is the ability of the enterprise to perform all the tasks required by the endeavor, in areas outside of IT,
including the ability to make decisions within the tight time constraints typical to project environments based upon the recent successful
execution of a similar endeavor of at least half the size and complexity
❖ Enterprise Ability to Implement and Operate the transformation elements and their related business processes, absorb the changes
arising from implementation, and ongoing ability to operate in the new environment

TOGAF Ahmad Alharbi 320

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture
Development (Business
Transformation Readiness
Assessment):

TOGAF Ahmad Alharbi 321

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Overview:

• There will always be risk with any architecture/business transformation effort. It is important to
identify, classify, and mitigate these risks before starting so that they can be tracked throughout
the transformation effort.

• There are two levels of risk that should be considered, namely:

- Initial Level of Risk: risk categorization prior to determining and implementing mitigating actions
- Residual Level of Risk: risk categorization after implementation of mitigating actions (if any)

TOGAF Ahmad Alharbi 322

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Risk Classification:

Risk is pervasive in any Enterprise Architecture activity and is present in all phases within the
Architecture Development Method (ADM). From a management perspective, it is useful to
classify the risks so that the mitigation of the risks can be executed as expeditiously as possible.

Risks are normally classified as time (schedule), cost (budget), and scope but they could also
include client transformation relationship risks, contractual risks, technological risks, scope and
complexity risks, environmental (corporate) risks, and personnel risks.

TOGAF Ahmad Alharbi 323

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Risk Identification:

• The maturity and transformation readiness assessments will generate a great many risks. Identify the
risks and then determine the strategy to address them throughout the transformation.

• The use of Capability Maturity Models (CMMs) is suitable for specific factors associated with architecture
delivery to first identify baseline and target states and then identify the actions required to move to the
target state. The implications of not achieving the target state can result in the discovery of risks.
Business Transformation Readiness Assessment for specific details.

• Normally these methodologies involve procedures for contingency planning, tracking and evaluating
levels of risk, reacting to changing risk level factors, as well as processes for documenting, reporting, and
communicating risks to stakeholders.

TOGAF Ahmad Alharbi 324

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Initial Risk Assessment:
• The following guidelines are based upon existing risk management best practices. Effect could be
assessed using the following example criteria:
❖ Catastrophic: infers critical financial loss that could result in bankruptcy of the organization
❖ Critical: infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the
IT investment
❖ Marginal: infers a minor financial loss in a line of business and a reduced return on investment on the IT investment
❖ Negligible: infers a minimal impact on a line of business' ability to deliver services and/or products

• Frequency could be indicated as follows:

- Frequent: likely to occur very often and/or continuously
- Likely: occurs several times over the course of a transformation cycle
- Occasional: occurs sporadically
- Seldom: would probably occur not more than once during a transformation cycle
- Unlikely: will probably not occur during a transformation cycle

TOGAF Ahmad Alharbi 325

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Initial Risk Assessment:

• Combining the two factors to infer impact would be conducted using a heuristically-based but
consistent classification scheme for the risks. A potential scheme to assess corporate impact could be
as follows:
❖ Extremely High Risk (E): the transformation
effort will most likely fail with severe
consequences
❖ High Risk (H): significant failure of parts of the
transformation effort resulting in certain goals
not being achieved
❖ Moderate Risk (M): noticeable failure of parts of
the transformation effort threatening the
success of certain goals
❖ Low Risk (L): certain goals will not be wholly
successful
TOGAF Ahmad Alharbi 326
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Risk Management):
Risk Mitigation and Residual Risk Assessment:

• Risk mitigation refers to the identification, planning, and conduct of actions that will
reduce the risk to an acceptable level.

• The mitigation effort could be a simple monitoring and/or acceptance of the risk to a
full-blown contingency plan calling for complete redundancy in a Business Continuity
Plan (with all of the associated scope, cost, and time implications)

TOGAF Ahmad Alharbi 327

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Capability-Based Planning):
Overview:
• Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in
organizations where a latent capability to respond (e.g., an emergency preparedness unit).
• From an IT perspective, capability-based planning is particularly relevant. For example, setting up a data center is really about
consolidating corporate data and providing the related services. Lead Enterprise Architects for this capability will find
themselves involved in managing construction, personnel training, and other change management tasks as well as IT
architecture tasks.
• Capability-based planning 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
and business plans.
• From an Enterprise Architecture and IT perspective, capability-based planning is a powerful mechanism to ensure that the
strategic business plan drives the enterprise from a top-down approach. It is also adaptable with capability engineering to
leverage emerging bottom-up innovations.
• No matter how the corporation structures itself, it will have to cope with the delivery of business capabilities whose delivery
will require co-ordination and alignment across business verticals.

TOGAF Ahmad Alharbi 328

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Techniques for Architecture Development (Capability-Based Planning):
Overview:

• Capability-based planning is a versatile business planning paradigm that is very useful

from an Enterprise Architecture perspective. It assists in aligning IT with the business
and helps focus IT architects on the continuous creation of business value.

TOGAF Ahmad Alharbi 329

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Applying Iteration to the ADM:
Overview:

TOGAF Ahmad Alharbi 330

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Applying Iteration to the ADM:
Overview:

• The ADM supports a number of concepts that are characterized as iteration.

First, iteration describes the process of both describing a comprehensive
Architecture Landscape through multiple ADM cycles based upon individual
initiatives bound to the scope of the Request for Architecture Work. Second,
iteration describes the integrated process of developing an architecture
where the activities described in different ADM phases interact to produce
an integrated architecture. In order to concisely describe the activity and
outputs, this latter iteration is described in sequential terms. Third, iteration
describes the process of managing change to the organization's
Architecture Capability.
TOGAF Ahmad Alharbi 331
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

ADM Guidelines and Techniques
Applying Iteration to the ADM:
Overview:

➢ Architecture Capability iterations support the creation1 and evolution of the required Architecture
Capability. This includes the initial mobilization of the architecture activity for a given purpose or
architecture engagement type by establishing or adjusting the architecture approach, principles, scope,
vision, and governance.
➢ Architecture Development iterations allow the creation of architecture content by cycling through,
or integrating, Business, Information Systems, and Technology Architecture phases. These iterations
ensure that the architecture is considered. In this type of iteration stakeholder reviews are typically
broader. As the iterations converge on a target, extensions into the Opportunities & Solutions and
Migration Planning phases ensure that the architecture's implement ability is considered as the
architecture is finalized.
➢ Transition Planning iterations support the creation of formal change roadmaps for a defined
architecture
➢ Architecture Governance iterations support governance of change activity progressing towards a
defined Target Architecture
TOGAF Ahmad Alharbi 332
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Overview

• The purpose of this module is to understand the concept of the Enterprise Continuum, its purpose and
constituent parts.(Objectives)
• What is the Enterprise Continuum?
- A CLASSIFICATION SYSTEM...
- ...which can therefore assist in identifying reusable assets
- A way of “idealizing” (considering the design/architecture) and “realizing” (considering the solution)
- A communications aid, for use internally and externally (extended enterprise)
- An aid to (software) engineering and/or making effective use of COTS packages
Reuse
- Reference Models
- Patterns
- Building Blocks
- Frameworks
- Specifications
- Existing Architecture Assets

TOGAF Ahmad Alharbi 333

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Main Constituents

TOGAF Ahmad Alharbi 334

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Main Graphic

TOGAF Ahmad Alharbi 335

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Architecture Continuum

• When you “idealize” about architecture you should:

- Use reference models wherever possible: Examples: TRM (Foundation) and III-RM (Common
System) published as Series Guides
- Reuse existing logical (architectural) Building Blocks
- Think right to left

TOGAF Ahmad Alharbi 336

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Solutions Continuum

When you “realize” an architecture you should: :

- Derive from existing architectural assets
- Implement a physical solution
- Control that solution uses SLAs

TOGAF Ahmad Alharbi 337

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

ADM Guidelines and Techniques, The Enterprise Continuum

The Enterprise Continuum
Summary

• The Enterprise Continuum – a

classification system

• The constituent parts of the Enterprise

Continuum

• Architecture and Solution Continuums

• Explain how the Enterprise Continuum

relates to other parts of the TOGAF®
Framework – particularly during
definition phases

TOGAF Ahmad Alharbi 338

 Module 06

Architecture
Repository
Architecture Repository Overview

TOGAF Ahmad Alharbi 339

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository

TOGAF Ahmad Alharbi 340

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Overview
• Supporting the Enterprise Continuum is the
concept of an Architecture Repository which can
be used to store different classes of architectural
output, created by the ADM. In this way, the
TOGAF standard facilitates understanding and co-
operation between stakeholders and practitioners
at different levels.

• In this context, the TOGAF ADM can be regarded

as describing a process lifecycle that operates at
multiple levels within the organization, operating
within a holistic governance framework and
producing aligned outputs that reside in an
Architecture Repository.

TOGAF Ahmad Alharbi 341

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Classes of Repository Information
• The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a
method for architecture development and a Metamodel for architecture content.
• The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture
Repository.
• The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at
particular points in time.
• The Standards Information Base captures the standards with which new architectures must comply, which may include
industry standards, selected products and services from suppliers, or shared services already deployed within the
organization.
• The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged
in order to accelerate the creation of new architectures for the enterprise.
• The Governance Log provides a record of governance activity across the enterprise.
• The Architecture Requirements Repository provides a view of all authorized architecture requirements which have been
agreed with the Architecture Board.

TOGAF Ahmad Alharbi 342

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Classes of Repository Information
➢ The Solutions Landscape presents an
architectural representation of the Solution
Building Blocks (SBBs) supporting the
Architecture Landscape which have been
planned or deployed by the enterprise.

➢ The Enterprise Repository there are a

considerable number of enterprise repositories
that support the architecture both inside and
outside of the enterprise, such as development
repositories, specific operating environments,
instructions, and configuration management
repositories.

TOGAF Ahmad Alharbi 343

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Architecture Landscape
• Strategic Architectures: provide a
longer term (high-level) roadmap towards
achieving strategic business goals.

• Segment Architectures: are the next

level down, represent major business
domains or even systems/capabilities (the
classification is up to the organization), but
still at the higher level.

• Capability Architectures: represent the

“ground level” of architecting. They represent
packages or projects that are part of
transitionary or incremental plans. This is
where the Solution Building Blocks live.

TOGAF Ahmad Alharbi 344

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Standards Information Base

TOGAF Ahmad Alharbi 345

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Repository
Summary
• Architecture Repository: A framework for classifying architecture output.

• How does it relate to the Enterprise IT Repository? It fits alongside other repositories for development, deployment and
support.

• Describe the purpose of the main repository areas:

- The Architecture Metamodel organizes an architectural framework and models content
- The Architecture Capability supports governance of the repository
- The Architecture Landscape contains views of the architecture at a particular point in time
- The Solutions Landscape contains Solution Building Blocks
- The Standards Information Base captures standards
- The Reference Library provide guidelines
- The Governance Log records enterprise governance activity

TOGAF Ahmad Alharbi 346

 Module 07

Architecture
Content Framework
and The Content
Metamodel
Architecture Content Framework and The Content Metamodel

TOGAF Ahmad Alharbi 347

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Overview

• A significant new feature to Version 9

• Like any classification system

- Aids consistency of terminology
- Mapping items to other frameworks, such as Zachman

• Content Framework items are:

- Architecture Deliverables
- Architectural Artifacts
- Building Blocks
- Content Metamodel
TOGAF Ahmad Alharbi 348
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Content Framework items

• Deliverable: Contractually specified work product, formally reviewed, agreed and signed-off by the stakeholders. At
end of project, it will either be archived or transitioned into the Architecture Repository as a Reference Model, Standard
or snapshot of the Architecture Landscape at a point in time.
• Artifact: A more granular work product describing architecture from a specific view and viewpoint. Classified as:
- Catalogues (lists)
- Matrices (relationships between lists) and
- Diagrams
• Building Block: A potentially reusable component of business, IT or architectural capability. Combined with other
BBs, delivers:
- Architecture BBs describe capability
- Solutions BBs implement that capability
• The Content Metamodel.

TOGAF Ahmad Alharbi 349

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Key Relationships

TOGAF Ahmad Alharbi 350

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Example Deliverable

TOGAF Ahmad Alharbi 351

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Content Metamodel

TOGAF Ahmad Alharbi 352

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

Architecture Content Framework
Summary

• Explained the purpose of the Content Framework which provides a consistent platform for
describing architecture.

• Described the main components of the Content Metamodel which are the work products
and the Metamodel.

• Described the relationship between the Content Metamodel and the ADM where the
Metamodel is closely mapped to main ADM phases.

TOGAF Ahmad Alharbi 353

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Overview

• Core content metamodel concepts: A TOGAF architecture is based on defining a number of

architectural building blocks within architecture catalogs, specifying the relationships between those
building blocks in architecture matrices, and then presenting communication diagrams that show in a
precise and concise way what the architecture is.

• The core concepts that make up the TOGAF content metamodel, through the following
subsections:
- Contents Metamodel Extension introduce the way in which the TOGAF framework employs a basic
core metamodel and then applies a number of extension modules to address specific architectural issues
in more detail.

• Core Metamodel Entities introduces the core TOGAF metamodel entities, showing the purpose of
each entity and the key relationships that support architectural traceability.
TOGAF Ahmad Alharbi 354
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension

TOGAF Ahmad Alharbi 355

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Governance Extensions
• The governance extension is intended to allow additional structured data to be held against objectives and
business services, supporting operational governance of the landscape.

• The scope of this extension is as follows:

- The ability to apply measures to objectives and then link those measures to service
- The ability to apply contracts to service communication or service interactions with external users and systems
- The ability to define re-usable service qualities defining a service-level profile that can be used in contracts
- Creation of additional diagrams to show ownership and management of systems

• This extension should be used in the following situations:

- When an organization is considering IT change that will result in a significant impact to existing
operational governance models
- When an organization has granular requirements for service levels that differ from service to service
- When an organization is looking to transform its operational governance practice
- When an organization is looking to transform its operational governance practice

TOGAF Ahmad Alharbi 356

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Governance Extensions

❖ The benefits of using this extension are as follows:

• Service levels are defined in a more structured way, with (More detail, The ability to re-use
service profiles across contracts and Stronger tracing to business objectives).
• Impacts to operations and operational governance models are considered in a more
structured way, with (Additional diagrams of system and data ownership, Additional
diagrams of system operation and dependencies on operations processes).

TOGAF Ahmad Alharbi 357

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Governance Extensions

TOGAF Ahmad Alharbi 358

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Services Extensions
• The services extension is intended to allow more sophisticated modeling of the service portfolio by creating a concept of Information System
(IS) services in addition to the core concept of business services. IS services are directly supported by applications and creating the layer of
abstraction relaxes the constraints on business services while simultaneously allowing technical stakeholders to put more formality into an IS
service catalog.

• The scope of this extension is as follows:

- Creation of IS services as an extension of business service

• This extension should be used in the following situations:

- When the business has a preset definition of its services that does not align well to technical and architectural needs
- When business and IT use different language to describe similar capabilities
- Where IT service is misaligned with business need, particularly around the areas of quality of service,
visibility of performance, and management granularity
- Where IT is taking initial steps to engage business in discussions about IT architecture

TOGAF Ahmad Alharbi 359

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Services Extensions

• The benefits of using this extension are as follows:

- Business services can be defined outside of the constraints that exist in the core metamodel; this allows for a more
natural engagement with business stakeholders
- IS services can be defined according to a model that maps closely to implementation, providing a more realistic solution
abstraction to support IT decision-making
- Business and IS service relationships show where the business view aligns with the IS view and where there are
misalignments

TOGAF Ahmad Alharbi 360

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Services Extensions

TOGAF Ahmad Alharbi 361

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Process Modeling Extensions
• The process modeling extension is intended to allow detailed modeling of process flows by adding events,
products, and controls to the metamodel. Typically, Enterprise Architecture does not drill into process flow, but in
certain process-centric or event-centric organizations it may be necessary to elaborate process in a much more formal
manner using this extension module.

• The scope of this extension is as follows:

- Creation of events as triggers for processes
- Creation of controls that business logic and governance gates for process execution
- Creation of products to represent the output of a process
- Creation of event diagrams to track triggers and state changes across the organization

• This extension should be used in the following situations:

- Where the architecture must pay specific attention to state and events
- Where the architecture is required to explicitly identify and store process control steps; for example, to support
regulatory compliance
- Where the architecture features critical or elaborate process flows

TOGAF Ahmad Alharbi 362

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Process Modeling Extensions
• The benefits of using this extension are as follows:
- This extension allows detailed process modeling and the cataloging of process artifacts
- May be used to support regulatory compliance activities
- May be used to re-purpose legacy or non-architectural process decomposition analysis

TOGAF Ahmad Alharbi 363

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Process Modeling Extensions

TOGAF Ahmad Alharbi 364

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Data Extensions
• The data extension is intended to allow more sophisticated modeling and the encapsulation of data. The
core model provides a data entity concept which supports the creation of data models, which is then extended
by this extension to include the concept of a data component. Data components form a logical or physical
encapsulation of abstract data entities into units that can be governed and deployed into applications.

• The scope of this extension is as follows:

- Creation of logical data components that group data entities into encapsulated modules for governance,
security, and deployment purposes
- Creation of physical data components that implement logical data components and are analogous to
databases, registries, repositories, schemas, and other techniques of segmenting data
- Creation of data lifecycle, data security, and data migration diagrams of the architecture to show data
concerns in more detail

• This extension should be used in the following situations:

- Where the architecture features significant complexity and risk around the location, encapsulation, and
management of or access to data

TOGAF Ahmad Alharbi 365

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Data Extensions

• The benefits of using this extension are as follows:

- The structure of data is modeled independently from its location, allowing
data models to be developed that span multiple systems without being tied to
physical concerns
- Logical groupings of data can be used to set governance, security, or
deployment boundaries around data, providing a much more holistic appreciation of
data issues surrounding the architecture

TOGAF Ahmad Alharbi 366

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Data Extensions

TOGAF Ahmad Alharbi 367

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Infrastructure Consolidation Extensions
• The infrastructure consolidation extension is intended to be used in landscapes
where the application and technology portfolios have become fragmented, and the
architecture seeks to consolidate the business-as-usual capability into a smaller number
of locations, applications, or technology components.

• The scope of this extension is as follows:

- Creation of logical and physical application components to abstract the capability of an
application away from the actual applications in existence
- Creation of logical and physical technology components to abstract product type from
the actual technology products in existence
- Creation of logical and physical technology components to abstract product type from
the actual technology products in existence

TOGAF Ahmad Alharbi 368

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Infrastructure Consolidation Extensions
• This extension should be used in the following situations:
- Where many technology products are in place with duplicate or overlapping capability
- Where many applications are in place with duplicate or overlapping functionality
- Where applications are geographically dispersed and the decision logic for determining the location of an
application is not well understood
- When applications are going to be migrated into a consolidated platform
- When application features are going to be migrated into a consolidated application

• The benefits of using this extension are as follows:

- Allows visibility and analysis of redundant duplication of capability in the application and technology
domains
- Supports analysis of standards compliance
- Supports analysis of migration impact of application or technology consolidation
- Supports detailed architectural definition of application structure

TOGAF Ahmad Alharbi 369

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension

Infrastructure
Consolidation
Extensions

TOGAF Ahmad Alharbi 370

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Motivation Extensions

➢ The motivation extension is intended to allow additional structured modeling of the drivers, goals, and objectives
that influence an organization to provide business services to its customers. This in turn allows more effective definition
of service contracts and better measurement of business performance.

➢ The scope of this extension is as follows:

- Creation of a metamodel entity for Driver that shows factors generally motivating or constraining an organization
- Creation of a metamodel entity for Goal that shows the strategic purpose and mission of an organization
- Creation of a metamodel entity for Objective that shows near to mid-term achievements that an organization would
like to attain
- Creation of a Goal/Objective/Service diagram showing the traceability from drivers, goals, a
nd objectives through to services

TOGAF Ahmad Alharbi 371

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Motivation Extensions
• This extension should be used in the following situations:
- When the architecture needs to understand the motivation of organizations in more detail
than the standard business or engagement principles and objectives that are informally modeled
within the core content metamodel
- When organizations have conflicting drivers and objectives, and that conflict needs to be
understood and addressed in a structured form
- When service levels are unknown or unclear

• The benefits of using this extension are as follows:

- Highlights misalignment of priorities across the enterprise and how these intersect with
shared services (e.g., some organizations may be attempting to reduce costs, while others are
attempting to increase capability)
- Shows competing demands for business services in a more structured fashion, allowing
compromise service levels to be defined

TOGAF Ahmad Alharbi 372

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Contents Metamodel Extension
Motivation Extensions

TOGAF Ahmad Alharbi 373

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Core Contents Metamodel

TOGAF Ahmad Alharbi 374

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Core Contents Metamodel
Overview

• The content metamodel

defines a set of entities that
allow architectural concepts to
be captured, stored, filtered,
queried, and represented in a
way that supports
consistency, completeness,
and traceability. At the highest
level, the content framework
is divided up in line with the
TOGAF ADM phases

TOGAF Ahmad Alharbi 375

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Content Framework and The Content Metamodel

The Content Metamodel
Core Contents Metamodel
Overview
➢ The content metamodel defines a set of entities that allow architectural concepts to be captured, stored,
filtered, queried, and represented in a way that supports consistency, completeness, and traceability. At the
highest level, the content framework is divided up in line with the TOGAF ADM phases
➢ Architecture Principles, Vision, and Requirements entities are intended to capture the surrounding context of
formal architecture models, including general Architecture Principles, strategic context that forms input for
architecture modeling, and requirements generated from the architecture. The architecture context is typically
collected in the Preliminary and Architecture Vision phases.
➢ Business Architecture entities capture architectural models of business operation, looking specifically at
factors that motivate the enterprise, how the enterprise is organizationally structured, and also what business
capabilities the enterprise has
➢ Information Systems Architecture entities capture architecture models of IT systems, looking at applications
and data in line with the TOGAF ADM phases
➢ Technology Architecture entities capture procured technology assets that are used to implement and realize
information system solutions
➢ Architecture Realization entities capture change roadmaps showing transition between architecture states
and binding statements that are used to steer and govern an implementation of the architecture

TOGAF Ahmad Alharbi 376

 Module 08

Architecture
Governance
Architecture Governance

TOGAF Ahmad Alharbi 377

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Overview

➢ Architecture Governance is the practice and orientation by which Enterprise Architectures

and other architectures are managed and controlled at an enterprise-wide level.

➢ Operates within a hierarchy of governance structures typically made up (in larger

organizations) of:
- Corporate Governance
- Technology Governance
- IT Governance
- Architecture Governance

TOGAF Ahmad Alharbi 378

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Governance
Framework – Conceptual
Structure

TOGAF Ahmad Alharbi 379

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Organization Structure

TOGAF Ahmad Alharbi 380

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Governance Benefits
• Links IT processes, resources, and information to organizational strategies and objectives.

• Integrates and institutionalizes IT best practices.

• Aligns with industry frameworks such as COBIT (planning and organizing, acquiring and implementing, delivering and
supporting, and monitoring IT performance).

• Enables the organization to take full advantage of its information, infrastructure, and hardware and software assets.

• Protects the underlying digital assets of the organization.

• Supports regulatory and best practice requirements such as auditability, security, responsibility, and accountability.

• Promotes visible risk management.

TOGAF Ahmad Alharbi 381

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Key Success Factors

• Best practices for the submission, adoption, reuse, reporting and retirement of architecture policies,
procedures, roles, skills, organizational structures and support services.
• Organizational responsibilities and structures to support the architecture governance processes and
reporting requirements.
• Integration of tools and processes to facilitate the take-up of the processes, both procedurally and
culturally.
• Criteria for control of the architecture governance processes, dispensations, compliance
assessments, SLAs, and OLAs.
• Internal and external requirements for the effectiveness, efficiency, confidentiality, integrity,
availability, compliance, and reliability of all architecture governance-related information, services
and processes.

TOGAF Ahmad Alharbi 382

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Need for Architecture Board

• Oversees implementation of Enterprise Architecture governance strategy.

• Should represent all key stakeholders in architecture, therefore…
• Should be cross-organizational.
• Board comprised of:
- Local (domain experts, line responsibility)
- Global (organization-wide responsibility)
• Each board will have established…
- Responsibilities and decision-making capabilities
- Remit and authority limits

TOGAF Ahmad Alharbi 383

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Board Responsibilities

• Consistency between sub-architectures.

• Identifying reusable components.
• Flexibility of Enterprise Architecture:
- To meet changing business needs
- To capitalize on new technologies
• Enforcement of Architecture Compliance.
• Improving the maturity level of architecture discipline within the organization.
• Ensuring that the discipline of architecture-based development is adopted.
• Providing the basis for all decision-making with regard to changes to the architectures .
• Supporting a visible escalation capability for out-of-bounds decisions.

TOGAF Ahmad Alharbi 384

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Setting Up an Architecture Board

• Likely triggers are:

- New CIO
- Merger or acquisition
- Consideration of a move to newer forms of computing
- Recognition that IT is poorly aligned to business
- Desire to achieve competitive advantage via technology
- Creation of an Enterprise Architecture program
- Significant business change or rapid growth
- Requirement for complex, cross-functional solutions
• Likely size:
- 4 to 10 depending on size and complexity of organization
- Other related bodies include Design Authorities and Working Parties

TOGAF Ahmad Alharbi 385

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Governance and Capability

• Governance is part of the Architecture Practice that can be represented as a “system”

with the following architectures:
- Business Architecture (processes, organization, etc.)
- Data Architecture (repository/continuum)
- Application Architecture (functionality)
- Technology Architecture (platform support)

TOGAF Ahmad Alharbi 386

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Compliance
Need for Architecture Compliance

• To ensure compliance of individual projects with the Enterprise Architecture:

- The Architecture function prepares the project architectures
- The IT Governance Function will define a formal Compliance Review process

TOGAF Ahmad Alharbi 387

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Compliance
Architecture Compliance – Definitions

TOGAF Ahmad Alharbi 388

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Compliance
Purpose of Compliance Reviews

• First and foremost, catch errors in the project architecture early, and thereby reduce the cost and risk
of changes required later in the lifecycle. This in turn means that the overall project time is shortened,
and that the business gets the bottom-line benefit of the architecture development faster.
• Ensure the application of best practices to architecture work.
• Provide overview of compliance to a mandated enterprise standard.
• Identify where the standards themselves may require modification.
• Identify services currently application-specific that could be provided as part of the enterprise
infrastructure.
• Document strategies for collaboration, resource sharing, and other synergies across multiple
architecture teams.
• Take advantage of technology advances.

TOGAF Ahmad Alharbi 389

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Compliance
Purpose of Compliance Reviews

• Communicate to management the technical readiness of the project.

• Identify key criteria for procurement activities (e.g. for inclusion in Commercial Off-The-
Shelf (COTS) product RFI/RFP documents).

• Identify and communicate significant architectural gaps to product and service providers.

TOGAF Ahmad Alharbi 390

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Architecture Governance and Capability

• Business Architecture of the architecture practice that will highlight the architecture governance,
architecture processes, architecture organizational structure, architecture information requirements,
architecture products, etc.

• Data Architecture that would define the structure of the organization's Enterprise Continuum and
Architecture Repository.

• Application Architecture specifying the functionality and/or applications services required to enable
the architecture practice.

• Technology Architecture that depicts the architecture practice’s infrastructure requirements and
deployment in support of the architecture applications and Enterprise Continuum.

TOGAF Ahmad Alharbi 391

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Governance
Architecture Governance
Summary

➢ Architecture Governance is the practice and orientation by which Enterprise Architectures

and other architectures are managed and controlled at an enterprise-wide level.

➢ TOGAF provides guidance on aspects of Architecture Governance in the Architecture

Capability Framework.

➢ The Governance Board plays a critical role, especially at the operational level.

TOGAF Ahmad Alharbi 392

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 393

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 394

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 395

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 396

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 397

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 398

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 399

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 400

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TOGAF Ahmad Alharbi 401

 Module 09

TRM and III-RM

TRM & III-RM

TOGAF Ahmad Alharbi 402

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
Overview

• The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a
foundation on which more specific architectures and architectural components can be built. This Foundation
Architecture is embodied within the Technical Reference Model (TRM), which provides a model and taxonomy of
generic platform services.

• IT architectures derived from TOGAF may differ greatly depending on the requirements of the information
system. In practice, many architectures will not include all of the services discussed here, and many will include
additional services to support Application Software that is specific to the organization or to its vertical industry.

• TRM Components:
❖ A taxonomy, which defines terminology, and provides a coherent description of the components and conceptual
structure of an information system
❖ An associated TRM graphic, which provides a visual representation of the taxonomy, as an aid to understanding

TOGAF Ahmad Alharbi 403

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces

• The three entities:

- Application Software
- Application Platform
- Communications Infrastructure

• The two interfaces:

- Application Platform Interface
- Communications Infrastructure Interface

TOGAF Ahmad Alharbi 404

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities
and Interfaces

TOGAF Ahmad Alharbi 405

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM

TOGAF Ahmad Alharbi 406

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces
Application Software

• The detailed TRM recognizes two categories of Application Software:

- Business Applications, which implement business processes for a particular
enterprise or vertical industry. The internal structure of business applications relates
closely to the specific application software configuration selected by an organization.
- Infrastructure Applications, which provide general-purpose business
functionality, based on infrastructure services.

• During development of the Technology Architecture, business applications and

infrastructure applications are important sources of requirements for Technology
Architecture services, and the selection of standards for the Application Platform will
be influenced strongly by the Application Software configuration to be supported.

TOGAF Ahmad Alharbi 407

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces
Application Platform

The term "platform" is used in many ways within the IT industry today. Because of the different usages, the
term is often qualified; for example, "application platform", "standardized" and "proprietary platforms", "client"
and "server platforms", "distributed computing platform", "portability platform". Common to all these usages is
the idea that someone needs a set of services provided by a particular kind of platform and will implement a
"higher-level" function that makes use of those services.

The TOGAF TRM focuses on the Application Platform, and the "higher-level function" is the set of Application
Software, running on top of the Application Platform, that is needed to address the enterprise's business
requirements.

It is important to recognize that the Application Platform in the TOGAF TRM is a single, generic, conceptual
entity. From the viewpoint of the TOGAF TRM, the Application Platform contains all possible services. In a
specific Target Architecture, the Application Platform will contain only those services needed to support the
required functions.

TOGAF Ahmad Alharbi 408

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces
Communications Infrastructure

• The Communications Infrastructure provides the basic services to interconnect systems and provide the
basic mechanisms for opaque transfer of data. It contains the hardware and software elements which
make up the networking and physical communications links used by a system, and of course all the other
systems connected to the network. It deals with the complex world of networks and the physical
Communications Infrastructure, including switches, service providers, and the physical transmission
media.

• A primary driver in enterprise-wide Technology Architecture in recent years has been the growing
awareness of the utility and cost-effectiveness of the Internet as the basis of a Communications
Infrastructure for enterprise integration. This is causing a rapid increase in Internet usage and a steady
increase in the range of applications linking to the network for distributed operation.

TOGAF Ahmad Alharbi 409

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces
Application Platform Interface

• The Application Platform Interface (API) specifies a complete interface between the Application Software
and the underlying Application Platform across which all services are provided. A rigorous definition of the
interface results in application portability, provided that both platform and application conform to it. For this
to work, the API definition must include the syntax and semantics of not just the programmatic interface,
but also all necessary protocol and data structure definitions.
• Portability depends on the symmetry of conformance of both applications and the platform to the
architected API. That is, the platform must support the API as specified, and the application must use no
more than the specified API.
• the API specifies a complete interface between an application and one or more services offered by the
underlying Application Platform. An application may use several APIs and may even use different APIs for
different implementations of the same service.

TOGAF Ahmad Alharbi 410

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

TRM
TRM Entities and Interfaces
Communications Infrastructure Interface
• The Communications Infrastructure Interface is the interface between the Application Platform and
the Communications Infrastructure.

• N particular, the model emphasizes the importance of focusing on the core set of services that can
be guaranteed to be supported by every IP-based network, as the foundation on which to build
today's interoperable enterprise computing environments.

TOGAF Ahmad Alharbi 411

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

III-RM
Overview

• The III-RM is a model of the major

component categories for developing,
managing, and operating an integrated
information infrastructure. It is a
model of a set of applications that sits
on top of an Application Platform. This
model is a subset of the TOGAF TRM,
and it uses a slightly different
orientation.

TOGAF Ahmad Alharbi 412

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

III-RM
Overview

TOGAF Ahmad Alharbi 413

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

III-RM
Components of the High-Level III-RM
• Business Applications, denoted by the light-brown boxes in the high-level model (corresponding to the light-brown "Business
Applications" box in the TRM graphic). There are three types of Business Application in the model:
❖ Brokering Applications, which manage the requests from any number of clients to and across any number of Information Provider
Applications
❖ Information Provider Applications, which provide responses to client requests and rudimentary access to data managed by a
particular server
❖ Information Consumer Applications, which deliver content to the user of the system, and provide services to request access to
information in the system on the user's behalf

• Infrastructure Applications, denoted by the dark-brown boxes in the high-level model (corresponding to the dark-brown
"Infrastructure Applications" box in the TRM graphic). There are two types of Infrastructure Application in the model:
❖ Development Tools, which provide all the necessary modeling, design, and construction capabilities to develop and deploy applications
that require access to the integrated information infrastructure, in a manner consistent with the standards of the environment
❖ Management Utilities, which provide all the necessary utilities to understand, operate, tune, and manage the run-time system in order
to meet the demands of an ever-changing business, in a manner consistent with the standards of the environment

TOGAF Ahmad Alharbi 414

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

TRM and III-RM

III-RM
Components of
the High-Level III-
RM

TOGAF Ahmad Alharbi 415

 Module 10

Architecture Views
and Viewpoints
Architecture Views and Viewpoints

TOGAF Ahmad Alharbi 416

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Views and Viewpoints

Architecture Views and Viewpoints
Overview

• The purpose of this module is to help understand the concepts of views and
viewpoints, and their role in communicating with stakeholders as well as applying
them to the Architecture Development Cycle. Also, how to apply the Stakeholder
Management technique using Stakeholder Maps.
• Views and Viewpoints are the crucial elements that determine how you represent
Architecture.

TOGAF Ahmad Alharbi 417

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Views and Viewpoints

Architecture Views and

Viewpoints
Example

TOGAF Ahmad Alharbi 418

 Module 11

Architecture
Maturity Model
Architecture Maturity Model

TOGAF Ahmad Alharbi 419

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Maturity Model

Architecture Maturity Model
Overview

• The Architecture Capability

Maturity Model (ACMM) developed
by US Dept. of Commerce.

• Defines six maturity levels and

nine elements (processes)

TOGAF Ahmad Alharbi 420

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

Architecture Maturity Model

Architecture Maturity Model
Maturity Assessments

• If desired an organization can go through a formal assessment called SCAMPI (Standard

CMMI Appraisal Method for Process Improvement).

• Used to measure Capability and Maturity

• Three types of assessment

- Class A: Formal and Official
- Class B: Interim assessment (semi-informal)
- Class C: Self-assessments (totally informal)

TOGAF Ahmad Alharbi 421

 Module 12

DGA
Requirements for EA Certificate from DGA

TOGAF Ahmad Alharbi 422

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

DGA
Main Requirements

➢ EA Structure

➢ EA Framework

➢ EA Services, Process, Standards and Principles

➢ Roadmap

➢ Governance Structure

➢ EA Objectives, KPIs and the alignment with the Strategy objectives

➢ Reports

➢ EA Tool

TOGAF Ahmad Alharbi 423

Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12

DGA
Readiness
Assessment
Approach

TOGAF Ahmad Alharbi 424

Thank You

TOGAF Ahmad Alharbi 425