8/09/2020

Part II
ADM

1
 8/09/2020

The ADM

 The ADM supports the concept of iteration at three levels:

 Cycling around the ADM: The ADM is presented in a circular manner
indicating that the completion of one phase of architecture work directly
feeds into subsequent phases of architecture work.
 Iterating between phases: TOGAF describes the concept of iterating across
phases (e.g., returning to Business Architecture on completion of
Technology Architecture).
 Cycling around a single phase: TOGAF supports repeated execution of the
activities within a single ADM phase as a technique for elaborating
architectural content.

Preliminary

The TOGAF ADM is 9 Phases

framework-agnostic, and
helps IT architects fill in the 4 Domains (B.D.A.T)
framework they might A.
Architecture
already have in use. Vision
H. B. 1.Business
Architecture Business
Change Architecture
Management

2.Data
G. C.
Requirements I.S
Implementation
Management Architectures
Governance 3.Application

F. D.
Migration Technology
Planning Architecture 4.Technology
E.
Opportunities
&
Solutions

2
 8/09/2020

ADM

Preliminary

The Preliminary Phase describes

the preparation and initiation
activities required to prepare to
meet the business directive for a
new enterprise architecture,
including the definition of an
Organization-Specific
Architecture framework and the
definition of principles.
6

3
 8/09/2020

Defining the Enterprise

“How big is this animal?”

 The enterprise scope will determine those stakeholders who will derive most
benefit from the new or enhanced enterprise architecture.
 It is important to appoint a sponsor at this stage.
 The enterprise may include many organizations and the duty of the sponsor is
to ensure that all stakeholders are included in some part of the architecture
work.

Identifying key drivers and elements in

the organizational context
It is necessary to understand the context surrounding the architecture. For example,
considerations include:
 The commercial models and budget for the enterprise architecture.
 The stakeholders.
 The intentions and culture of the organization.
 Current processes that support execution of change and operation of IT.
 The Baseline Architecture landscape. including the state of the enterprise and also how the landscape is
 currently represented in documentation form.
The skills and capabilities of the enterprise.

4
 8/09/2020

Objectives
 Determine the Architecture Capability desired by the Organization:
 Review the organizational context for conducting enterprise architecture
 Identify and scope the elements of the enterprise organizations affected by
the Architecture Capability
 Identify the established frameworks, methods, and processes that intersect
with the Architecture Capability
 Establish a Capability Maturity target

 Establish the Architecture Capability:

 Define and establish the Organizational Model for Enterprise Architecture
 Define and establish the detailed process and resources for architecture
governance
 Select and implement tools that support the Architecture Capability
Continued…
 Define the architecture principles

Approach
 Define the Enterprise
 Identify key drivers and elements in the organizational context
 Define the requirements for architecture work
 Define the architecture principles that will inform any architecture work
 Define the framework to be used
 Define the relationships between management frameworks
 Evaluate the enterprise architecture maturity

10

5
 8/09/2020

Preliminary Phase: Main inputs

 TOGAF
 Other architecture frameworks
 Business strategies and board
business plans, IT strategy
 Business principles, business
goals, and business drivers
 Governance and legal
frameworks
Any existing:
 organizational model
 architecture framework
 architecture principles
 architecture repository

11

Preliminary Phase: Outputs

 Organizational model for
enterprise architecture
 Tailored Architecture
Framework, including
architecture principles
 Initial Architecture Repository
 Restatement of business
principles, goals and drivers
 Architecture Governance
Framework
 Request for Architecture Work

12

6
 8/09/2020

Request for Architecture Work

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

13

Request for Architecture Work

 Sent from the Sponsor to the Architecture Organization

 This initiates a cycle of the ADM
 Created as an output from
 the Preliminary Phase
 or an approved architecture Change Request from Phase H
 or from Phase F when generating Architecture landscape

14

7
 8/09/2020

Defining The Requirements For

Architecture Work
Business imperatives drive the requirements and performance metrics. One or more of the
following requirements need to be articulated so that the sponsor can identify the key
decision-makers and stakeholders and generate a Request for Architecture Work:
 Business requirements
 Cultural aspirations
 Organization intents
 Strategic intent
 Forecast financial requirements

15

15

Defining Architecture Principles

 Why
 Architecture principles provide a framework for decision making

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

16

8
 8/09/2020

Defining The Architecture Principles

 Architecture work is informed by business principles as well as architecture
principles.
 The architecture principles themselves are also normally based in part on
business principles.
 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.
 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. They
reflect a level of consensus across the enterprise, and embody the spirit and thinking
of existing enterprise principles.

17

17

Example Principle
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. The enterprise business functions must be capable of operating on alternative
information delivery mechanisms.
Implications:
 Dependency on shared system applications mandates that the risks of business
interruption must be established in advance and managed.
 Management includes but is not limited to periodic reviews, testing for vulnerability
and exposure, or designing mission-critical services to ensure business function
continuity through redundant or alternative capabilities.
 Recoverability, redundancy, and maintainability should be addressed at the time of
design.
 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. 18

18

9
 8/09/2020

Architecture Principles
 An initial output of the Preliminary Phase
 A set of general rules and guidelines for the architecture being developed
 TOGAF contains guidelines for developing principles and a detailed set of
generic principles
 Principles are generally established in two key domains:
 Enterprise principles provide a basis for decision-making throughout an enterprise
and dictate how the organization fulfills its mission
 Architecture principles are a set of principles that relate to architecture work.

19

Defining Architecture Principles

 Why
 Architecture principles provide a framework for decision making
 Who
 Developed by the Enterprise Architects
 In conjunction with key stakeholders
 The Enterprise CIO
 Architecture Board
 Other key business stakeholders

20

10
 8/09/2020

The Need for Architecture Principles

• They inform and support the way in which an organization

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

21

Template
Should represent the essence of the rule and be
Name easy to remember

Should be succinct and unambiguously

Statement communicate the rule

Should highlight the business benefits of adhering

Rationale to the principle using business terminology.

Should highlight the requirements, both for the

business and IT for carrying out the principle, in
Implications
terms of resources, costs, and activities/tasks.

22

11
 8/09/2020

Example: Primacy of Principles

Statement Principles apply throughout the enterprise and override all
other considerations when decisions are made

Rationale The only way we can provide a recognized, consistent

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

Implications Without this principle, short-term consideration,

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

23

An Example Statement of Principles

The following set of principles have been approved by the Internal
Architecture Board.

 Business Principles:
1. Primacy of Principles
2. Maximize Benefit to the Enterprise
3. Compliance with the Law
4. Availability at Anytime from Anywhere
5. Business Continuity
6. Citizenship

Continued…

24

12
 8/09/2020

What makes a good set of Architecture

Principles?
A good set of principles will be founded in the beliefs and values of the
organization.
It must be:
 Understandable: the underlying tenets can be quickly grasped
 Robust: principles must be definitive and precise to support consistent
decision-making
 Complete: principles must cover every situation perceived
 Consistent: principles should not be contradictory
 Stable: principles should be enduring, yet able to accommodate change

25

Management Frameworks

Portfolio, Program, Solution

and Project Development
TOGAF has to co-exist with and enhance the operational capabilities of other
management frameworks thatManagement Methods
are present within any organization either formally or
informally. Methods
The main frameworks suggested to be co-ordinated with TOGAF are:
 Business Capability Management (BusinessArchitecture
Direction and Planning) that
determines what business capabilities Development
are required to deliver business value
including the definition of return on investment
Methodand the requisite
control/performance measures.
 Portfolio/Project Management Methods that determine how a company manages
its change initiatives.
 Operations Management Methods that describe how a company runs its day-to-
day operations, including IT.
Operations
 Solution Development Methods that formalize the way that business systems are
Management
delivered in accordance with the structures developed in the IT architecture.
Methods

26

26

13
 8/09/2020

Preliminary Phase Steps

The order of the steps should be adapted to
the situation. In particular you should
determine whether it is appropriate to do the 1. Scope the Enterprise Organizations Impacted
Baseline Business Architecture or Target
Business Architecture development first
2. Confirm Governance and Support Frameworks

3. Define and Establish Enterprise Architecture Team

and Organization

4. Identify and Establish Architecture Principles

5. Tailor TOGAF and, if any, Other Selected

Architecture Framework(s)

6. Implement Architecture Tools

27

27

Summary

The main objective of the preliminary

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

Continued…

28

14
 8/09/2020

Quick Quiz

Q. Which one of the following is considered during the Preliminary Phase of the
TOGAF ADM?

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

29

Quick Quiz

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

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

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

30

15
 8/09/2020

The Preliminary Phase

31

31

Class Discussion
 Examine the Example Set of Architecture Principles in TOGAF Chapter 23 or
the abstract on Page 16 of the Delegate Handout in your Course Workbook
 Identify one principle which you think is particularly appropriate for your
business or organisation
 Provide an 1 min presentation to the class introducing and explaining your
choice. State:

 Why it appeals to you

 Whether it applies to your organization or not

32

16
 8/09/2020

Case Study Exercise

Principles

Exercise 5
Exercise 6

33

Architecture
Vision

Describes the initial phase of

an Architecture Development
Cycle. It includes information
about defining the scope,
identifying the stakeholders,
creating the Architecture
Vision, and obtaining
approvals.
34

34

17
 8/09/2020

Objective

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

value to be delivered as a result of the proposed enterprise architecture.
 Set the scope, constraints, and expectations for a TOGAF project.
 Create the Architecture Vision.
 Define stakeholders.
 Validate the business context and create the Statement of Architecture
Work.
 Obtain approvals for Statement of Architecture Work.

35

35

Approaches to Architecture Vision

The three approaches of the architecture vision (A) are

 receipt of a request for architecture work,
 creating the architecture vision, and
 business scenarios.

36

18
 8/09/2020

Creating the Architecture Vision

 The Architecture Vision provides the sponsor with a key tool to sell the
benefits of the proposed capability to stakeholders and decision-makers
within the enterprise.
 Architecture Vision describes how the new capability will meet the business
goals and strategic objectives and address the stakeholder concerns when
implemented.
 The Architecture Vision provides a first-cut, high-level description of the
Baseline and Target Architectures, covering the business, data, application,
and technology domains.
 Business scenarios are an appropriate and useful technique to discover and
document business requirements, and to articulate an Architecture Vision
that responds to those requirements.

37

37

Business Scenarios
Identifying, documenting, and ranking the problem driving
1. Problem the scenario.
Identifying the business and technical environment of the
2. Environment scenario and documenting it in scenario models.
Identifying and documenting desired objectives (the results of
3. Objectives handling the problems successfully); get "SMART“.
 Specific
Identifying the human actors (participants)
4. Human Actors and their place in the business model
 Measureable

 Actionable
Identifying computer actors (computing elements)
5. Computer Actors and their place in the technology mode
 Realistic
Identifying and documenting
 &Time-bound
6. Roles Responsibilities roles, responsibilities
Checking for "fitness-for-purpose"
7. Refine and refining only if necessary
38

38

19
 8/09/2020

Statement of
Architecture Work contents
 Title
 Roles, responsibilities and
 Architecture project request and deliverables
background
 Acceptance criteria and procedures
 Architecture project description
 Architecture project plan and
and scope
schedule
 Overview of Architecture vision
 Approvals
 Change of scope procedures

39

Architecture Definition Document

 The deliverable container for the core artifacts

 Business, Data, Application, and Technology architectures

 Includes baseline, transition and target architectures

 Developed through phases A, B, C, D and E

 It provides a qualitative view of the solution

40

20
 8/09/2020

Architecture Definition Document

contents
 Scope
 Goals, Objectives, Constraints
 Architecture Principles
 Rational for architectural approach
 Mapping to architecture repository
 Gap analysis
 Impact assessment
 Transition architecture

41

Phase A: Inputs

 Request for Architecture

Work
 Business principles, business
goals and drivers
 Organization model for
enterprise architecture
 Tailored Architecture
Framework, including
architecture principles
 Populated Architecture
Repository

42

21
 8/09/2020

Phase A: Outputs
 (Enterprise) Capability Assessment
• Tailored Architecture Framework  Architecture Vision
• Architecture principles including  Draft Architecture Definition
Document
business principles
 Communications Plan
 Approved Statement of Architecture
Work including:
 Project description and scope
 Overview of Architecture Vision
 Project plan and Schedule
 Refined statements of business
principles, goals, and drivers
 Additional content populating the
Architecture Repository

43

Architecture Vision

 Purpose: To provide key stakeholders with a formally agreed outcome

 Provides a summary of changes that will accrue from successful deployment

of the Target Architecture

 Provides a summary of the full Architecture Definition

44

22
 8/09/2020

Statement of
Architecture Work contents
 Title  Roles, responsibilities and
 Architecture project request and deliverables
background  Acceptance criteria and procedures
 Architecture project description  Architecture project plan and
and scope schedule
 Overview of Architecture vision  Approvals
 Change of scope procedures

45

Architecture Vision contents

 Problem Description
 Stakeholders & Concerns
 List of issues/scenarios to be addressed
 Objective of the Statement of Architecture Work
 Summary of views necessary for the Request for Architecture Work and the
Version 0.1 Architecture Domains created typically including:
 Value Chain diagram
 Solution Concept diagram
 Mapped Requirements
 Reference to Draft Architecture Definition Document

46

23
 8/09/2020

1. Establish the Architecture Project

Phase A Steps 2. Identify Stakeholders, Concerns, and Business Requirements

The order of the steps should be adapted to 3. Confirm and Elaborate Business Goals, Business Drivers, and
the situation. In particular you should
determine whether it is appropriate to do the
Constraints
Baseline Business Architecture or Target
Business Architecture development first 4. Evaluate Business Capabilities

5. Assess Readiness for Business Transformation

6. Define Scope

7. Confirm and Elaborate Architecture Principles, including

Business Principles

8. Develop Architecture Vision

9. Define the Target Architecture Value Propositions and KPIs

10. Identify the Business Transformation Risks and Mitigation

Activities 47

11. Develop Statement of Architecture Work; Secure Approval

47

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 performs an Enterprise Capability
assessment and conducts Stakeholder
Analysis
 It creates
 Statement of Architecture Work
 Architecture Vision,
 Draft Architecture Definition Document
 Communications Plan

48

24
 8/09/2020

Phase A
revisit -

49

49

Quick Quiz
Q. Complete the following sentence: Phase A Architecture Vision is
intended to do all the following except:

A Validate the business principles and goals of the organization

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

50

25
 8/09/2020

Business
Architecture
Describes the development
of a Business Architecture to
support an agreed
Architecture Vision.

51

51

Objective

 Develop the Target Business Architecture that describes how the

enterprise needs to operate to achieve the business goals, and
respond to the strategic drivers set out in the Architecture Vision,
in a way that addresses the Request for Architecture Work and
stakeholder concerns
 Identify candidate Architecture Roadmap components based upon
gaps between the Baseline and Target Business Architectures

52

52

26
 8/09/2020

Approach (1)
 Knowledge of the Business Architecture is a prerequisite for
architecture work in the other domains (Data, Applications,
Technology)
 and so is the first activity that needs to be undertaken.

 This Phase is often required to demonstrate business value of

subsequent work to key stakeholders
 Scope depends on existing strategy and planning
 Update and verify
 bridge between high-level business drivers, strategy, and
 goals on the one hand, and specific business requirements
 Existing architecture discovery must include all relevant detail
 If there is no existing strategy or planning:
 Identify any existing architecture definitions, then verify and update
 New process definitions may require detailed work

53

Approach (2)

 Business Strategy defines what to achieve

 Business Architecture describes how to achieve it
 In both cases, use business scenarios to identify key
business objectives and processes

54

27
 8/09/2020

Developing the Baseline Description

 If an enterprise has existing architecture descriptions, they should be used as
the basis for the Baseline Description.
 The normal approach to Target Architecture development is top-down.
 In the Baseline Description, however, the analysis of the current state often
has to be done bottom-up, particularly where little or no architecture assets
exist.
 Whatever the approach, the goal should be to re-use existing material as much
as possible, and to gather and analyze only that information that allows
informed decisions to be made regarding the Target Business Architecture.

“It is important to build a complete picture without going

into unnecessary detail.”
55

55

Business Modelling
 Business models should be logical extensions of the business scenarios from the
Architecture Vision, so that the architecture can be mapped from the high-level
business requirements down to the more detailed ones.
A variety of modelling tools and techniques may be employed:
Activity Models (also called Business Process Models) : describe the functions
associated with the enterprise's business activities, the data and/or information
exchanged between activities.
Use-Case Models: can describe either business processes or systems functions,
depending on the focus of the modelling effort.
Class Models : describes static information and relationships between information.

56

56

28
 8/09/2020

Architecture Repository
 As part of Phase B, the architecture team will need to consider what relevant
Business Architecture resources are available from the Architecture Repository.
In Particular:
 Generic business models relevant to the organization's industry sector.
These are "Industry Architectures", in terms of the Enterprise Continuum.
 Business models relevant to common high-level business domains.
 Enterprise-specific building blocks (process components, business rules, job
descriptions, etc.).

57

57

The 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.
The major components within an Architecture Repository are as follows:
 The Architecture Metamodel describes the organizationally tailored application of an
architecture framework, including a metamodel for architecture content.
 The Architecture Capability defines the parameters, structures, and processes that
support governance of the Architecture Repository.
 The Architecture Landscape shows an architectural view of the building blocks that are
in use within the organization today (e.g., a list of the live applications). The landscape
is likely to exist at multiple levels of abstraction to suit different architecture objectives.
 The Standards Information Base (SIB) 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. 58

 The Governance Log provides a record of governance activity across the enterprise.

58

29
 8/09/2020

The Architecture Repository

59

59

Phase B Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to
the situation. In particular you should
determine whether it is appropriate to do the 2. Develop Baseline Business Architecture Description
Baseline Business Architecture or Target
Business Architecture development first
3. Develop Target Business Architecture Description

4. Perform gap analysis

5. Define roadmap components

6. Resolve impacts across the Architecture Landscape

7. Conduct formal stakeholder review

8. Finalize the Business Architecture

9. Create Architecture Definition Document60

60

30
 8/09/2020

Phase B
Inputs
Tailored Approved Draft
Organizational Architecture Enterprise Architecture Architecture Architecture
Architecture Statement of
Model for EA principles Continuum Repository Vision Definition
Framework Architecture Document

Steps
Select Develop Develop
Perform Define Resolve Impacts Conduct Formal Finalize the Create
Reference Baseline Target
Models, Business Business Gap Candidate Across the Stakeholder Business Architecture
Roadmap Architecture Definition
Viewpoints, & Architecture Architecture Analysis Review Architecture
Components Landscape Document
Tools Description Description

Outputs
Refined and updated versions of the
Draft Architecture Definition Draft Architecture Requirements Business Architecture components
Architecture Vision phase 61
Document Specification of an Architecture Roadmap
deliverables,

61

Business Scenarios (Technique)

Part III
ADM Guidelines and Techniques

62

31
 8/09/2020

Business Scenarios: Introduction

Key factors in the success of any enterprise architecture are:

 Its support for business objectives.

and

 The extent to which it is linked to business requirements,

Business scenarios help us to identify and

understand the business requirements that the
architecture development must address.

63

Business Scenarios
 TOGAF defines a method for developing Business Scenarios
 A “method within a method”
 Documented in Part III, ADM Guidelines and Techniques

64

32
 8/09/2020

What is a Business Scenario?

A business scenario describes:
 a business process, application or set of applications that can be enabled
by the architecture
 the business and technology environment;
 the people and computing components (the “actors”) who execute it;
 the desired outcome of proper execution.

65

What to expect in a Business Scenario

 Business Scenario models should:
 Capture business and technology views
graphically to help comprehension
 Provide a starting point for requirements,
 Relate actors and interactions
 Business Scenario descriptions should:
 Capture the critical steps between actors in
the right sequence
 Partition the responsibility of the actors
 List pre-conditions that have to be met prior
to proper system functionality, and
 Provide technical requirements to ensure the
service is of acceptable quality

66

33
 8/09/2020

Template for a Business Scenario

 Business scenario problem description
 Detailed objectives
 Views of environments and processes
 Actors, their roles and responsibilities
 Principles and constraints
 Requirements
 Next steps
 Glossary of terms and abbreviations
 References

67

Business Scenarios and the ADM

 Used prominently in Phase A

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

 Business Requirements are referred

to throughout all phases of the ADM

68

34
 8/09/2020

What is a Good Business Scenario?

A good business scenario:

 Is representative of a significant business need or problem
 Enables vendors to understand the value of a developed solution to a
customer
 Is “SMART”

69

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

70

35
 8/09/2020

The Benefits of Business Scenarios

A business scenario should be a complete description of a business problem

Without this:
 There is danger that the requirements will not be complete
 The business value to solving the problem will be unclear
 The relevance of potential solutions will be unclear
A scenario:
 Can play an important role in engaging the stakeholders
 Can help to establish good communication with vendors early on.

71

Who Contributes to a Business Scenario?

 The creation of a business scenario is not solely the province of the architect
 Business line management and other stakeholders for the enterprise must be
involved
 It may also involve an organization’s IT vendors
 Typically involvement of management is greatest in the early stages whereas
the involvement of the architect is greatest in later stages

72

36
 8/09/2020

Developing a Business Scenario

1 - Identify, document and rank the 1 - problem

problem driving the scenario
2 - Identify the business and technical
2 - environment
environment of the scenario and
document it in scenario models
3 - Identify and document desired 3 - objectives
objectives - the results of handling the
problems successfully - using SMART

Continued

73

Developing a Business Scenario

4 - Identify the human actors and their place 1 - problem
in the business model
5 - Identify computer actors (computing 2 - environment
elements), and their place in the
technology model
3 - objectives
6 - Identify and document roles,
responsibilities and measures of success
per actor 4 - human actors
7 - Check for “fitness for purpose” and refine
if necessary
5 - computer actors

6 - roles & responsibilities

7 - refine

74

37
 8/09/2020

Getting Business Scenarios Right

 Customers almost always know what they want
 But it is often not written down, especially the link to business
 So we help write it down
 Customers sometimes do not know what they really need
 So we observe and probe to help discover what’s needed
 We help bring out critical business rules
 We also focus on the “what” not the “how”
 Business Scenarios are part of a larger process. They are a technique, not an
end in themselves

75

Some Reminders

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

 Business Scenarios are just a technique, not an objective
 Use them, don’t get lost in them

Workshop Follow up
Focus Focus

Brainstorm/ Documentation and Allocate

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

Slide of 24
76
Business Scenarios Provide Coherence and Consistency

76

38
 8/09/2020

Resources

 The Open Group Bookstore (http://www.opengroup.org/bookstore)

 The Managers Guide to Business Scenarios
 Examples of completed Business Scenarios

77

Summary

 Business scenarios help address one of the most common issues facing
businesses
 Aligning the IT with the business
 Business scenarios help to identify and understand business needs
 And thereby derive business requirements
 They are just a technique, not the goal
 They are part of the larger process of architecture development

78

39
 8/09/2020

Exercise
Write a scenario describing how you would choose a new
car. Include the following in your answer:

 Problem description
 Detailed objectives
 Views of environments and processes
 Actors, their roles and responsibilities
 Principles and constraints
 Requirements
 Next steps

Make the objectives SMART

79

Case Study Exercise

Business Scenarios
Exercise #7

80

40
 8/09/2020

Summary
 Phase B is about documenting the
fundamental organization of a
business
 Embodied in its business processes
and people
 Their relationships to each other
and the environment
 The principles governing its design
and evolution
 How the organization meets its
business goals

81

Phase B

revisit -

82

82

41
 8/09/2020

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

83

Information
Systems
Architectures
Describes the development of
Information Systems Architectures
for an architecture project,
including the development of Data
and Application Architectures.

84

84

42
 8/09/2020

Data or Applications first ?

 It is usually necessary to
address both
• Not always the case,
depending on project scope
and constraints
 May be developed in either
order, or in parallel
• Theory suggests Data
Architecture comes first
• Practical considerations
may mean that starting
with Application Systems
may be more efficient
 There will need to be some
iteration to ensure consistency

85

Approach

Phase C involves Data and Applications Architecture,

in either order.
Advocates exist for both sequences:
• Spewak’s Enterprise Architecture Planning recommends a data-driven sequence.

• Major applications systems (ERP, CRM, …) often combine technology infrastructure

and application logic.
An application-driven approach takes core applications (underpinning mission-
critical business processes) as the primary focus of the architecture effort.

• Integration issues often constitute a major challenge.

86

43
 8/09/2020

Objective

 Develop the Target Information Systems (Data and Application) Architecture,

describing how the enterprise's Information Systems Architecture will enable the
Business Architecture and the Architecture Vision, in a way that addresses the
Request for Architecture Work and stakeholder concerns.
 Identify candidate Architecture Roadmap components based upon gaps between
the Baseline and Target Information Systems (Data and Application)
Architectures.

87

87

Data Architecture part of Phase C

(Objectives)
 Develop the Target Data Architecture that enables the Business
Architecture and the Architecture Vision, while addressing the
Request for Architecture Work and stakeholder concerns
 Identify candidate Architecture Roadmap components based upon gaps
between the Baseline and Target Data Architectures

88

88

44
 8/09/2020

Key Considerations for Data Architecture

Data Management
Considerations include:
 A clear definition of which application components in the landscape will serve as the
system of record or reference for enterprise master data.
 Will there be an enterprise-wide standard that all application components, including
software packages, need to adopt?
 Clearly understand how data entities are utilized by business functions, processes, and
services.
 Clearly understand how and where enterprise data entities are created, stored,
transported, and reported.
 What is the level and complexity of data transformations required to support the
information exchange needs between applications?
 What will be the requirement for software in supporting data integration with the
enterprise's customers and suppliers?
89

89

Key Considerations for Data Architecture

Data Migration
Considerations include:

 When an existing application is replaced, there will be a critical need to migrate

data (master, transactional, and reference) to the new application.
 he Data Architecture should identify data migration requirements and also provide
indicators as to the level of transformation, weeding, and cleansing that will be
required to present data in a format that meets the requirements and constraints of
the target application.
 The objective being that the target application has quality data when it is
populated.
 Ensure that an enterprise-wide common data definition is established to support the
transformation.

90

90

45
 8/09/2020

Key Considerations for Data Architecture

Data Governance
Data governance considerations ensure that the enterprise has the necessary dimensions
in place to enable the transformation, as follows:

 Structure: This dimension pertains to whether the enterprise has the necessary
organizational structure and the standards bodies to manage data entity aspects of the
transformation.
 Management System: Here enterprises should have the necessary management system
and data-related programs to manage the governance aspects of data entities
throughout its lifecycle.
 People: This dimension addresses what data-related skills and roles the enterprise
requires for the transformation. If the enterprise lacks such resources and skills, the
enterprise should consider either acquiring those critical skills or training existing
internal resources to meet the requirements through a well-defined learning program.

91

91

Phase C Data Architecture Steps

1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to
the situation.
2. Develop Baseline Data Architecture Description

3. Develop Target Data Architecture Description

4. Perform gap analysis

5. Define roadmap components

6. Resolve impacts across the Architecture Landscape

7. Conduct formal stakeholder review

8. Finalize the Data Architecture

9. Create Architecture Definition Document92

92

46
 8/09/2020

Applications Architecture part of Phase C

(Objectives)
 Develop the Target Application Architecture that enables the Business
Architecture and the Architecture Vision, while addressing the Request for
Architecture Work and stakeholder concerns
 Identify candidate Architecture Roadmap components based upon gaps between
the Baseline and Target Application Architectures

93

93

Phase C
Draft Architecture Definition
Output
Inputs

Steps

Data and Application Document

• Organizational Model for
Enterprise Architecture
• Tailored Architecture
Framework
• Application principles
• Data principles
• Statement of Architecture Work
• Architecture Vision
• Architecture Repository
• Draft Architecture Definition
Document
• Draft Architecture
Requirements Specification
• Gap analysis results (from
Business Architecture)
• Relevant technical
requirements that will apply to
Phase C
• Business Architecture
components of an Architecture
Roadmap
Architecture
• Select Reference Models,
Viewpoints, and Tools
• Develop Baseline Data
Architecture Description
• Develop Target Data
Architecture Description
• Perform Gap Analysis
• Define Candidate Roadmap
Components
• Resolve Impacts Across the
Architecture Landscape
• Conduct Formal
Stakeholder Review
• Finalize the Data
Architecture
• Create Architecture
Definition Document
• Baseline Data Architecture
• Target Data Architecture
• Baseline Application Architecture
• Target Application Architecture
• Data Architecture views
corresponding to the selected
viewpoints addressing key
stakeholder concerns
• Application Architecture views
corresponding to the selected
viewpoints addressing key
stakeholder concerns
Draft Architecture
Requirements Specification
• Gap analysis results
• Relevant technical requirements
that will apply to this evolution of
the architecture development
cycle
• Constraints on the Technology
Architecture about to be designed
• Updated business requirements, if
appropriate
Information systems
components of an Architecture
Roadmap
94

94

47
 8/09/2020

Summary
Data
• The Data Architecture
phase defines the types
and sources of data
needed to support the
business, in a way that
can be understood by
stakeholders.
• The architecture team
should consider existing
relevant data models,
such as the ARTS and
Energistics models.
Application
• This phase defines the
kinds of applications
necessary to process
the data and support
the business.
• The goal is to define
what kinds of
applications are
relevant and what
those applications need
to do.

95

Quick Quiz

Q When presenting to Senior Management, how should the applications best be

presented?

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

96

48
 8/09/2020

Phase C
revisit -

97

97

Technology
Architecture
Describes the development of the
Technology Architecture for an
architecture project.

98

98

49
 8/09/2020

Objectives

 Develop the Target Technology Architecture that enables the logical and physical
application and data components and the Architecture Vision, addressing the Request
for Architecture Work and stakeholder concerns.
 Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Technology Architectures

99

99

Approach

 Review the Technology Architecture Resources available in the Architecture

Repository
 Existing IT Services in the IT Repository or IT Service Catalog
 The TOGAF TRM
 Technology models relevant to the organization

100

50

Phase D: Inputs
 Request for Architecture Work
 Capability Assessment
 Communications Plan
 Organization model for enterprise
architecture
 Tailored Architecture Framework
 Technology principles
 Statement of Architecture Work
 Architecture Vision
 Architecture Repository
 Draft Architecture Requirements
Specification, including gap
analysis results and technical
requirements
101
The Architecture Repository
102
8/09/2020
• Draft Architecture Definition
Document, containing:
– Baseline Business Architecture
(detailed)
– Target Business Architecture
(detailed)
– Baseline Data Architecture
(detailed)
– Target Data Architecture (detailed)
– Baseline Application Architecture
(detailed)
– Target Application Architecture
(detailed)
– Baseline Technology Architecture
(high-level)
– Target Technology Architecture
(high-level)
• Business, Data, and Application
Architecture components of an
Architecture Roadmap
•Existing IT services as
documented in the IT repository
or IT service catalog
•TOGAF Technical Reference
Model (TRM)
•Generic technology models
relevant to the organization's
industry "vertical" sector
102
51
 8/09/2020

Phase D Steps
1. Select reference models, viewpoints, and tools
The order of the steps should be adapted to
the situation.
2. Develop Baseline Technology Architecture
Description

3. Develop Target Technology Architecture Description

4. Perform gap analysis

5. Define roadmap components

6. Resolve impacts across the Architecture Landscape

7. Conduct formal stakeholder review

8. Finalize the Technology Architecture

9. Create Architecture Definition Document

103

103

Phase D: Outputs
 Statement of Architecture Work,
updated if necessary
 Validated technology principles
or new technology principles
 Draft Architecture Definition
Document
 Draft Architecture Requirements
Specification
 Technology Architecture
components of an Architecture
Roadmap

104

52
 8/09/2020

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

105

Gap Analysis
The Gap analysis technique is widely used in the
ADM to validate an architecture that is being
developed. The basic idea is to spot gaps
between the Baseline Architecture and the
Target Architecture; that is, items that have
been deliberately omitted, accidentally left out,
or not yet defined.

106

53
 8/09/2020

Gap Analysis and the ADM

 High level Gap Analysis performed in Phase A

 Detailed Gap Analysis is performed in Phases B, C, D for each of the

domains

 Consolidated Gap Analysis is performed in Phase E

107

Performing a Gap Analysis

Gap analysis highlights services and/or functions that have been omitted or are
yet to be developed; these are the gaps. They should be marked as ‘correctly
eliminated’ or as ‘to be addressed by reinstating, developing or procuring’.

1. Create a matrix of business ABBs:

 Put ‘Current architecture’ + ‘New Services’ on the vertical axis
 Put ‘Target Architecture’ + ‘Eliminated Services’ on the horizontal axis

2. Mark ABBs that are common to both as ‘Included’

Continued…

108

54
 8/09/2020

Performing a Gap Analysis

3. Review blocks missing from current:

 Confirm as ‘Eliminated’

 Else mark for ‘Review’

4. Mark any ‘New Services’ as gap to be filled by acquiring function by either:

 Development

 Procurement

109

Example Gap Analysis

110

55
 8/09/2020

Case Study Exercise

Gap Analysis
Exercise #8

111

Phase D
revisit -

112

112

56
 8/09/2020

Transition Planning
 Phase E
 Phase F

113

Opportunities
& Solutions
Opportunities and Solutions
conducts initial implementation
planning and the identification
of delivery vehicles for the
architecture defined in the
previous phases.
114

114

57
 8/09/2020

Objective
 Generate the initial complete version of the Architecture Roadmap,
based upon the gap analysis and candidate Architecture Roadmap
components from Phases
Stakeholders
Capability-Based B, C, and
Planning D the ADM
and
 •• Specific
DeterminePhase E capabilities
whether an targeted for completion
incremental
is a collaborative effort will berequired
approach
with stakeholders the focus
is required, and if so
of the
identify from Architecture
Transition Definition
Architectures
both the business (Phases
that will deliver based
and IT sides. B, C, and D) and, continuous business
value.• upon the identified
It should include work
both packages
those thatPhase E, projects
implement and willthose
be
conceived.
that operate the infrastructure.
 To confirm
•• The the enterprise’s
capability
It should alsoincrements capability
will
include those be forfor
the drivers
responsible forundergoing
the Transition change.
strategic
Architectures (Phase E) that will structure the project
planning,
 To generate andespecially
increments.
for creating
gain consensus on the
an Transition
outline Implementation and
Architectures.
Migration Strategy.
• The actual delivery will be coordinated through the
Implementation and Migration Plans (Phase F).

115

115

Approach
 This is the first phase concerning implementation

 It takes into account the complete set of gaps between the Target and
Baseline Architectures in all architecture domains
 It logically groups changes into work packages

 It builds a best-fit roadmap based upon:

 Stakeholder requirements

 The enterprise's business transformation readiness

 Identified opportunities and solutions

 Identified implementation constraints.

116

58
 8/09/2020

Phase E: Inputs
 Product Information  Architecture Vision
 Request for Architecture  Architecture Repository
Work
 Draft Architecture Definition
 Capability Assessment Document
 Communications Plan
 Draft Architecture
 Planning Methodologies Requirements Specification
 Governance models and  Change Requests for existing
frameworks programs and projects
 Tailored Architecture
Framework  Candidate Architecture
Roadmap components from
 Statement of Architecture Phases B,C, and D
Work

117

Stakeholders
 Phase E is a collaborative effort
 Stakeholders required from both the business and IT sides
 It should include those that implement and those that operate the
infrastructure
 It should also include those responsible for strategic planning
 especially for creating the Transition Architectures, if required

118

59
 8/09/2020

Top-Down Design – Bottom-up

Implementation
Design:
1. Business Architecture
2. Data (or Applications) Architecture
3. Applications (or Data) Architecture
4. Technology Architecture
Implementation:
1. Technology Architecture
2. Applications (or Data) Architecture
3. Data (or Applications) Architecture
4. Business Architecture

119

1. Determine/Confirm Key Corporate Change

Attributes

Phase E Steps 2. Determine Business Constraints for Implementation

The order of the steps should be adapted to
the situation.
3. Review and Consolidate Gap Analysis Results from
Phases B to D
4. Review Consolidated Requirements Across Related
Business Functions
5. Consolidate and Reconcile Interoperability
Requirements

6. Refine and Validate Dependencies

7. Confirm Readiness and Risk for Business

Transformation

8. Formulate Implementation and Migration Strategy

9. Identify and Group Major Work Packages

10. Identify Transition Architectures

120

11. Create the Architecture Roadmap &

Implementation and Migration Plan
120

60
 8/09/2020

Phase E Outputs
• Statement of Architecture
Work
• Architecture Vision
• Draft Architecture Definition
Document, including:
– Transition Architectures, if
any
• Draft Architecture
Requirements Specification,
including
– Consolidated Gaps,
Solutions and Dependencies
Assessment
• Enterprise Capability
Assessment, including:
– Business Capability Assessment
– IT Capability Assessment
• (Outline) Architecture Roadmap,
including:
– Work Package portfolio
– Identification of Transition
Architectures, if any
– Implementation
Recommendations
• Implementation & Migration
Plan (outline)

121

Summary
 Phase E is the first phase concerned
with implementation
 ABBs are chosen then converted to
SBBs
 The Capability of the Enterprise to
implement and accept the new
architecture is assessed
 It identifies the parameters of
change, the phases (transitions) and
necessary projects
 The output forms the basis of the
Implementation Plan

122

61
 8/09/2020

Phase E
revisit -

123

123

Quick Quiz
Q. Which one of the following is a successful strategy for Phase E?
A Focus on the application systems that are relevant to the enterprise
B Focus on projects that will deliver quick wins
C Focus on top-down implementation
D Reverse engineering
E Trial and error

124

62
 8/09/2020

Migration
Planning
Addresses the formulation of a
set of detailed sequence of
Transition Architectures with a
supporting Implementation and
Migration Plan.

125

125

Objective
 Analyze cost benefits and risk.
 Develop detailed Implementation and Migration Plan.
• The focus of Phase F is the creation of an Implementation
 Finalize the Architecture
and Migration Roadmap
Plan in co-operation and
with thethe supporting
portfolio and Implementation
and Migration Plan.
project managers.
• Phase E provides an incomplete Architecture Roadmap and
 Ensure that the Implementation
Implementation and Migration Planand
thatMigration
address thePlan is coordinated
withRequest
the enterprise's approach
for Architecture Work. IntoPhase
managing and implementing change
F this Roadmap
in the
andenterprise's overalland
the Implementation change
Migrationportfolio.
Plan are integrated
with the enterprise's other change activity.
 Ensure
• Thethat the business
Architecture value
Roadmap, and0.1
Version cost
andof work packages and
Transition Architectures
Implementation is understood
and Migration by0.1
Plan, Version keyfrom
stakeholders.
Phase E will form the basis of the final Implementation
and Migration Plan that will include portfolio and project-
level detail.
126

126

63
 8/09/2020

Approach

 The focus is creation of the Implementation and Migration plan in co-

operation with project and portfolio managers
 Activities include the dependencies, costs, and benefits of the various
migration projects within the context of the enterprise's other activity

127

Phase F: Inputs
• Request for Architecture Work
• Communications Plan
• Organizational model for
enterprise architecture
• Governance Models and
Frameworks
• Tailored Architecture
Framework
• Statement of Architecture Work
• Architecture Vision
• Architecture Repository
• Draft Architecture Definition
Document, including:
– Transition Architectures, if any
• Draft Architecture Requirements
Specification
• Change Requests for existing
programs and projects
• Capability Assessment
• (Outline Architecture Roadmap,
including:
– Identification of work packages
– Identification of Transition
Architectures
– Implementation Factor
Assessment and Deduction
Matrix
• Implementation and Migration
Plan (outline)

128

64
 8/09/2020

Phase F Steps
The order of the steps should be adapted to 1. Confirm Management Framework Interactions for
the situation. the Implementation and Migration Plan

2. Assign a Business Value to Each Work Package

3. Estimate Resource Requirements, Project Timings,

and Availability/Delivery Vehicle
4. Prioritize the Migration Projects through the
Conduct of a Cost/Benefit Assessment and Risk
Validation
5. Confirm Architecture Roadmap and Update
Architecture Definition Document

6. Generate the Implementation and Migration Plan

7. Complete the Architecture Development Cycle and

Document Lessons Learned
129

129

Phase F Outputs
 Implementation and Migration Plan
(detailed)
 Finalized Architecture Definition
Document, including:
 Finalized Transition Architectures, if
any
 Finalized Architecture Requirements
Specification
 Finalized Architecture Roadmap
 Re-Usable ABBs
 Requests for Architecture Work for a
new iteration of the ADM (if any)
 Implementation Governance Model
 Change Requests
 Lessons Learned

130

65
 8/09/2020

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, defining implementation
governance, and recording
lessons
 At the completion of this phase
the preparation for
implementation has been
completed

131

Phase F
revisit -

132

132

66
 8/09/2020

Quick Quiz
Q. When preparing the detailed Migration Plan, which of the following should
NOT be a consideration?
A Risk Assessment
B Priorities of projects
C Availability of Resources
D Cost/value assessment
E Choice of target platform

133

Governance
 Phase G
 Phase H

134

67
 8/09/2020

Implementation
Governance

Provides an architectural oversight

of the implementation.

135

135

Objective
 Provide architectural oversight for the implementation.
 Prepare and issue Architecture Contracts (Implementation
Governance Board).
 Ensure that the implementation project conforms to the
architecture.

136

136

68
 8/09/2020

• Note that, in parallel with Phase G, there is the execution

of an organizational-specific development process, where
the actual development happens.
• To enable early realization of business value and benefits,
and to minimize the risk in the transformation and
migration program, the favoured approach is to deploy the
Target Architecture as a series of transitions.
• Each transition represents an incremental step towards
the target, and each delivers business benefit in its own
right

137

137

Approach
The overall approach in Phase G is to:

 Establish an implementation program that will enable the delivery of the Transition
Architectures agreed for implementation during the Migration Planning phase.
 Adopt a phased deployment schedule that reflects the business priorities embodied
in the Architecture Roadmap.
 Follow the organization's standard for corporate, IT, and architecture 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.

138

138

69
 8/09/2020

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

Project details are developed, including:

 Name, description, and objectives

 Scope, deliverables, and constraints
 Measures of effectiveness
 Acceptance criteria
 Risks and issues

Implementation governance is closely allied to overall architecture governance.

139

139

Architecture Governance
“the practice and orientation by which enterprise architectures and other
architectures are managed and controlled at an enterprise-wide level..”

Domains of Governance within the Enterprise

 Corporate governance
 Technology governance
 IT governance
 Architecture governance
Each of these domains of governance may exist
at multiple geographic levels - global, regional,
and local - within the overall enterprise.

Corporate governance is a broad topic, beyond the scope of an enterprise architecture

framework such as TOGAF.

140

140

70
 8/09/2020

Architecture Governance : Characteristics

Architecture governance is the practice and orientation by which enterprise architectures
and other architectures are managed and controlled at an enterprise-wide level. It
includes the following:

 Implementing a system of controls over the creation and monitoring of all architectural
components and activities, to ensure the effective introduction, implementation, and
evolution of architectures within the organization.
 Implementing a system to ensure compliance with internal and external standards and
regulatory obligations.
 Establishing processes that support effective management of the above processes within
agreed parameters.
 Developing practices that ensure accountability to a clearly identified stakeholder
community, both inside and outside the organization.

141

141

Architecture Governance Framework

“a conceptual and organizational framework for architecture governance.”
Conceptual Structure

142

142

71
 8/09/2020

Architecture Governance Framework

Organizational Structure

143

143

Phase G: Inputs

• Request for Architecture Work • Architecture Requirements

• Capability Assessment
• Organizational model for EA
• Tailored Architecture
Framework
• Statement of Architecture Work
• Architecture Vision
• Architecture Repository
• Architecture Definition
Document
Specification
• Architecture Roadmap
• Implementation Governance
Model
• Architecture Contract
• Request for Architecture Work
from E and F
• Implementation and Migration
Plan

144

72
 8/09/2020

Phase G Steps
The order of the steps should be adapted to
the situation.

1. Confirm Scope and Priorities for Deployment with

Development Management

2. Identify Deployment Resources and Skills

3. Guide Development of Solutions Deployment

4. Perform Enterprise Architecture Compliance

Reviews

5. Implement Business and IT Operations

6. Perform Post-Implementation Review and Close the

Implementation
145

145

Phase G: Outputs
 Architecture Contract (signed)
 Compliance Assessments
 Change Requests
 Architecture-compliant solutions
deployed, including:
 Implemented system
 Populated Architecture Repository
 Recommendations and
dispensations
 Service delivery requirements
 Performance metrics
 SLAs
 Architecture Vision
 Business and IT operating models

146

73
 8/09/2020

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

147

Phase G
revisit -

148

148

74
 8/09/2020

Quick Quiz
Q. Which one of the following provides a foundation for governing the
implementation of the recommended projects?
A Impact Analysis
B Principles
C Strategic Plan
D Architecture Contracts
E Risk Assessment

149

Architecture
Change
Management
Establishes procedures for
managing change to the
new architecture.

150

150

75
 8/09/2020

Objective
 Provide continual monitoring and a change management
process to ensure that the architecture responds to the
needs of the enterprise and maximizes the value of the
architecture to the business.

151

151

Approach
 The goal of an architecture change management process is to ensure
that the architecture achieves its original target business value.

 This can be done by:

1. Ensuring that changes to the architecture are managed properly
2. Supporting a dynamic architecture.

 The process will determine the circumstances under which:

1. The architecture will be permitted to change after deployment, and the process
for this.
2. The ADM will be used again.

152

76
 8/09/2020

• The
In Phase
goal Hofitan
is architecture
critical that the
change
governance
management body process
establishis
to ensure
criteria tothat
judge thewhether
architecture
a Change
achieves
Requestits original
warrantstarget
just
business
an architecture
value. Thisupdate
includes
or whether
managing
it warrants
changesstarting
to the a
architecture
new cycle of inthea Architecture
cohesive andDevelopment
architected way.Method (ADM).
• It
This
is especially
process will important
typicallytoprovide
avoid "creeping
for the continual
elegance",
monitoring
and the governance
of such things
body must
as governance
continue torequests,
look fornew
developments
changes that relate
in technology,
directly to
and
business
changes value.
in the business
environment.
• When changes are identified, change management will
determine whether to formally initiate a new architecture
evolution cycle.

153

153

Drivers for Change

There are three ways to change the existing infrastructure that have to be
integrated:

 Strategic, top-down directed change to enhance or create new capability

(capital)
 Bottom-up changes to correct or enhance capability (operations and
maintenance) for infrastructure under operations management
 Experiences with the previously delivered project increments in the care of
operations management, but still being delivered by ongoing projects

154

154

77
 8/09/2020

Enterprise Architecture Change

Management Process
Architectural changes can be classified into one of three categories:

 Simplification change: A simplification change can normally be handled

via change management techniques.
 Incremental change: An incremental change may be capable of being
handled via change management techniques, or it may require partial
re-architecting, depending on the nature of the change .
 Re-architecting change: A re-architecting change requires putting the
whole architecture through the architecture development cycle again.

155

155

Maintenance versus Redesign

If the change:
 Impacts 2 stakeholders or more, then it is likely to require an architecture
redesign and re-entry to the ADM
 Impacts only 1 stakeholder, then it is likely to be a candidate for change
management
 Can be allowed under a dispensation, then it is likely to be a candidate for
change management

156

78
 8/09/2020

Change Management Process

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

1. Register all events that may impact the architecture

2. Allocate resources and management for the architecture tasks
3. The process (or role) responsible for resources has to make an
assessment of what should be done
4. Evaluate the impact

157

A good rule-of-thumb is:

• If the change impacts two stakeholders or more, then it is
likely to require an architecture redesign and re-entry to
the ADM.
• If the change impacts only one stakeholder, then it is more
likely to be a candidate for change management.
• If the change can be allowed under a dispensation, then it
is more likely to be a candidate for change management.

158

158

79
 8/09/2020

Phase H Steps
The order of the steps should be adapted to the situation.

1. Establish Value Realization Process

2. Deploy Monitoring Tools

3. Manage Risks

4. Provide Analysis for Architecture Change

Management
5. Develop Change Requirements to Meet Performance
Targets

6. Manage Governance Process

6. Activate the Process to Implement Change

159

159

Phase H: Outputs

 Architecture updates
 Changes to architecture
framework and principles
 New Request for Architecture
Work, to initiate another cycle
of the ADM
 Statement of Architecture Work
 Architecture Contract
 Compliance Assessments

160

80
 8/09/2020

Summary

 Phase H Change Management

 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

161

Phase H
revisit -

162

162

81
 8/09/2020

Quick Quiz
Q. Which of the following is NOT part of an architecture change management
process?
A Ensuring that business continues as usual
B Determining whether a change warrants an update to the architecture
C Determining whether a change requires a new cycle of the ADM
D Managing change properly
E Establishing criteria for judging change requests

163

Case Study Exercise

Handling Change

Exercise #4

164

82
 8/09/2020

Requirements
Management
Examines the process of managing
architecture requirements
throughout the ADM.

165

165

Objective
 Ensure that the architecture lifecycle is maintained.
 Ensure that the Architecture Governance Framework is
executed.
 Ensure that the enterprise Architecture Capability meets
current requirements.
 Ensure that the Requirements Management process is
sustained and operates for all relevant ADM phases

166

166

83
 8/09/2020

Approach

 The ability to deal with changes in the requirements is crucial to the ADM
process since architecture deals with uncertainty and change
 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
 It is recommended that a Requirements Repository is used to record and
manage all architecture requirements

167

Requirements Management: Inputs

 Requirements-related outputs
from each ADM phase.
 The first high-level
requirements are produced as
part of the Architecture Vision.
 Each architecture domain then
generates detailed
requirements.
 Deliverables in later ADM phases
contain mappings to new types
of requirements

168

84
 8/09/2020

Steps Overview
Requirements Management Steps ADM Phase Steps

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

5. Identify changed requirement and 6. Assess impact of change

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

169

Requirements Management: Outputs

 Updated Architecture
Requirements Specification
 Requirements Impact Assessment
 Requirements Impact Statement
 When new requirements arise; or
existing ones are changed, a
Requirements Impact Assessment
is performed which results in a
Requirements Impact Statement .
The Requirements Impact
Statement identifies the phase of
the ADM to be revisited. This goes
through various iterations until a
final version is produced.

170

85
 8/09/2020

Summary
 Requirements Management is an
ongoing activity of the ADM.
 The Requirements Repository
contains the current requirements
for the Target Architecture.
 When new requirements arise, or
existing ones are changed, a
Requirements Impact Assessment
is performed resulting in a
Requirements Impact Statement
being generated. The Statement
identifies the phases of the ADM
to be revisited. This goes through
various iterations until a final
version is produced.

171

Requirements Management
revisit -

172

172

86
 8/09/2020

Quick Quiz

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

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

173

87