TOGAF V92 Part2

TOGAF® Standard Courseware V9.
2 Edition
Preliminary
Phase
TOGAF is a registered trademark of The Open

Group in the United States and other countries
210
Copyright © The Open Group 2018
Preliminary Phase: Objectives in detail

» 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
Continued…
211
Copyright 2009-2018, The Open Group 1

TOGAF® Standard Courseware V9.2 Edition
Preliminary Phase: Objectives in detail

» 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
– Define the Architecture Principles
212
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
213

Architecture
Maturity
Models

214
Capability Maturity Models
» Capability Maturity Models (CMMs) provide an effective

method for control and improvement of change
processes
» Benefits of such models include:
– They describe the practices that any organization must perform
in order to improve its processes
– They provide measures for improvement
– They provide a framework for managing the improvement
efforts
– They organize the various practices into levels, each level
representing an increased ability to control and manage the
development environment
215

» An evaluation of the organization’s practices against

the model (an “assessment”) is performed to find the
current level at which the organization currently stands
» This shows the organization’s maturity and the areas to
focus on for the greatest improvement and the highest
ROI
216
» The original CMM was developed in the early 1990s by

CMU and is still widely used today.
» CMMs have also been developed for other areas such
as:
– People: the P-CMM (People Capability Maturity Model), and the
IDEAL Life Cycle Model for Improvement
– Systems Engineering: the SE-CMM (Systems Engineering
Capability Maturity Model)
– Software Acquisition: the SA-CMM (Software Acquisition
Capability Maturity Model)
– CMMI: Capability Maturity Model Integration
217

There are templates available to assess:

» The state of the IT architecture process
» The IT architecture
» The organization’s buy-in to both
CMM models can also be used to assess a wide range of
domains:
» e-Commerce maturity
» Process implementation and audit
» Quality measurements
» People competencies
» Investment management
218
The CMMI
» CMMI stands for Capability Maturity Model Integration.

» CMMI is a framework used to manage the complexity of
multiple different models:
– IPD-CMM (Integrated Product Development Capability Maturity
Model)
– P-CMM (People Capability Maturity Model)
– SA-CMM (Software Acquisition Capability Maturity Model)
– SE-CMM (Systems Engineering Capability Maturity Model)
– SW-CMM (Capability Maturity Model for Software)
219

The CMMI
According to the SEI, the use of the CMMI models improves on best
practices by enabling organizations to:
» Explicitly link management and engineering activities to business
objectives
» Expand the scope of and visibility into the product lifecycle and
engineering activities
» Incorporate lessons learned from additional areas of best practice
(e.g., measurement, risk management etc.)
» Implement more robust high-maturity practices
» Address additional organizational functions
» Comply with ISO standards
CMMI has been adopted worldwide.
220
The CMMI
SCAMPI, the Standard CMMI Appraisal Method for

Process Improvement, is used to identify strengths,
weaknesses, and ratings relative to CMMI reference
models.
It incorporates best practice and is based on the features of
several appraisal methods.
It is applicable to a wide range of appraisal usage modes,
including both internal process improvement and
external capability determinations.
221

US Department of Commerce ACMM
The enterprise Architecture Capability Maturity Model

(ACMM) was developed for conducting internal
assessments. It is a framework that represents the key
components of a productive EA process. The goal is to
identify weak areas and provide a way to improve the
overall architecture process.
The ACMM has 3 sections:
» The enterprise architecture maturity model
» EA characteristics of processes at different maturity
levels
» The EA CMM scorecard
222
ACMM Maturity Levels
5: Measured
» The DoC ACMM
consists of
4: Managed – 6 maturity levels
– 9 architecture elements
3: Defined
2: Under Development
1: Initial
0: None
223

ACMM Enterprise Architecture Elements
1. Architecture process:
• Is there an established Enterprise Architecture process?
2. Architecture development:
• To what extent is the development and progression of the Operating
Units' Enterprise Architecture documented?
3. Business linkage:
• To what extent is the Enterprise Architecture linked to business
strategies or drivers?
4. Senior management involvement:
• To what extent are the senior managers of the Operating Unit involved
in the establishment and ongoing development of an IT Architecture?
5. Operating unit participation
• To what extent is the Enterprise Architecture process accepted by the
Operating Unit?
• To what extent is the Enterprise Architecture process an effort
representative of the whole organization?
224
ACMM Enterprise Architecture Elements
6. Architecture communication
• To what extent are the decisions of Enterprise Architecture practice
documented?
• To what extent is the content of the Enterprise Architecture made available
electronically to everybody in the organization?
• To what extent is architecture education done across the business on the
Enterprise Architecture process and contents?
7. IT security
• To what extent is IT Security integrated with the Enterprise Architecture?
8. Architecture governance
• To what extent is an Enterprise Architecture governance (governing body)
process in place and accepted by senior management ?
9. IT investment and acquisition strategy
• To what extent does the Enterprise Architecture influence the IT Investment and
Acquisition Strategy?
225

Example: ACMM Scoring Criteria

Score Element Architecture Process
0 No EA Not established or does not exist.
1 Initial Exists in ad-hoc or localized form or early draft form may exist. Some Enterprise
Architecture processes are defined. There is no unified architecture process
across technologies or business processes. Success depends on individual
efforts.
2 Developing Being actively developed. Basic Enterprise Architecture Process program is
documented based on OMB Circular A-130 and Department of Commerce
Enterprise Architecture Guidance. The architecture process has developed clear
roles and responsibilities.
3 Defined The architecture is well defined and communicated to IT staff and business
management with Operating Unit IT responsibilities. The process is largely
followed.
4 Managed Enterprise Architecture process is part of the culture, with strong linkages to
other core IT and business processes. Quality metrics associated with the
architecture process are captured. These metrics include the cycle times
necessary to generate Enterprise Architecture revisions, technical environment
stability, and time to implement a new or upgraded application or system.
5 Measured Continuous improvement of Enterprise Architecture processes. 226
Maturity Assessments in the ADM
» Maturity Assessments are referred to in the Preliminary

Phase, Phase A, and Phase E of the ADM
» The approach to the Preliminary Phase recommends
their use as part of developing the Organizational Model
for Enterprise Architecture
» In Phase A, a maturity assessment is part of the
Capability Assessment used to determine the baseline
and target capability of the enterprise
» This Capability Assessment is also revisited in Phase E,
when preparing the Implementation and Migration Plan
227

’d)
Maturity Assessments in the ADM (Cont’
» When using CMMs with the ADM, it is recommended

that they be customized and discussed in workshops
involving the major stakeholders within the organization
» The actual levels of maturity can provide a strategic
measure of the organization’s ability to change, as well
as a series of sequential steps to improve that ability
228
Exercise
» Provide an assessment of your own company’s EA

process maturity, on a scale from Level 0 to Level 5
using the templates provided with the DoC ACMM 1.2
document (provided as a handout)
229

Preliminary Phase: Main inputs
» The TOGAF Library

» Other architecture frameworks
» Business strategies and board
business plans, IT strategy
» Business principles, business
goals, and business drivers
» Major frameworks operating in
the business
» Governance and legal
frameworks
Any existing:
» Organizational model
» Architecture framework
» Architecture Principles
» Architecture Repository
230
Steps
6. Develop Strategy and Implementation Plans for

Tools and Techniques
5. Tailor TOGAF, and other Architecture Frameworks,
if any
4. Identify Architecture Principles
3. Define & Establish the Enterprise Architecture Team
2. Confirm Governance and Support Frameworks
1. Scope the Enterprise Organizations Impacted
231

1. Scope the enterprise organizations impacted
» Identify core enterprise

» Identify soft enterprise
» Identify extended enterprise
» Identify communities
» Identify governance involved
232
2. Confirm governance and support

frameworks
» The major output of this phase is a framework for

architecture governance.
» The existing governance and support models of an
organization will probably need to change
» The current governance and support models need to be
assessed to understand their content.
» Sponsors and stakeholders will need to be consulted
concerning the potential impact
As a result of Step 2 the architecture touch-points and likely

impacts should be understood and agreed by relevant
stakeholders.
233

The Importance of Governance
» An Enterprise Architecture is
only as good as the decision
making framework that is
established around it
”governance” framework
» The Governance Framework
depends on
– Clear authority structure
– The right participants
234
What do we mean by Governance?
» The way in which decisions are made
» Who is responsible?
» Who is involved?
» Who is accountable?
235

Introduction to Governance
Governance is the practice by which Enterprise

Architectures are managed and controlled.
This includes:
• controls on the creation and monitoring of
components and activities – ensuring introduction,
implementation, and evolution of architectures
• ensuring compliance with internal and external
standards and regulatory obligations
• supporting management of the above
• ensuring accountability to external and internal
stakeholders
236
Governance and the ADM
» Governance should be established in the Preliminary

Phase
– Usually an adaptation of existing governance and
support models
» The Architecture Board should ensure that the ADM is
being applied correctly
– Compliance to the ADM is fundamental to the
governance of the Architecture
» Governance plays a key role in Phases G and H
– The implementation and then change management
activities
237

Governing the ADM
» The ADM, whether adapted or used as is, is a key

process to be managed and governed
» The Architecture Board should be satisfied that the
method is being applied correctly
» The management of all architectural artifacts,
governance and related process should be supported by
a controlled environment such as a repository
238
Governance Repository
» Reference Data
» Process Status
» Audit Information
239

Nature of Governance
» Governance ensures business is conducted properly.
» It is about effective and equitable usage of resources to

ensure sustainability of strategic objectives.
Continued
240
Nature of Governance
» Basic principles of corporate governance:

– Focus on the rights, roles and equitable treatment of
shareholders
– Disclosure and transparency
– Accountability of the Board to the shareholders
• Responsibilities of the board:

• Reviewing and guiding corporate strategy
• Setting and monitoring management’s
performance objectives
241

Governance – Basic Principles
[Governance is] "... the system by which business

corporations are directed and controlled.
The corporate governance structure specifies
the distribution of rights and responsibilities
among different participants [ …] and spells out
the rules and procedures for making decisions
on corporate affairs. […] it also provides the
structure through which company objectives are
set, and the means of attaining those objectives
and monitoring performance" [OECD (1999)].
242
Levels of Governance
The hierarchy of governance domains includes:

• Technology Governance
• IT Governance
• Architecture Governance
Each domain may exist at multiple geographic levels:
• Global
• Regional
• Locals
243

An IT Governance Framework - COBIT
» COBIT is an open standard for control of IT.

» It was developed and promoted by the IT Governance
Institute.
» COBIT provides a generally accepted standard for good
IT security and control practices
» There is also a set of Management Guidelines for
COBIT, including Maturity Models, Critical Success
Factors, Key Goal Indicators, and Key Performance
Indicators.
» The framework can help managers to control and
measure IT resources.
244
TOGAF Architecture Governance Framework
» Phase G of the TOGAF ADM is about Implementation

Governance - the realization of architecture through change
projects.
» Architecture Governance covers management and control of
all aspects of the development and evolution of
Enterprise Architectures
» The Architecture Governance Framework is generic and
can be adapted to an existing governance environment.
It helps to identify effective processes and organizational
structures, so that the business responsibilities can be
elucidated, communicated, and managed.
245

Conceptual Structure
246
Architecture Governance Framework -

» Architecture Governance is an approach, a series of

processes, a cultural orientation and a set of
responsibilities that ensure the integrity and
effectiveness of architectures.
» The split of process, content and context is key to

supporting an architecture governance initiative. It allows
introduction of new governance material without
impacting the processes and ensures framework
flexibility.
247

» The Architecture Governance Framework is integral to

the Enterprise Continuum, and manages all content for
both the architecture and the architecture governance
processes.
248
Organizational Structure
249

Organizational Structure
» Governance is the management and control of

architectures.
» To ensure effective control, it is necessary to have the
correct organizational structures to support all
governance activities.
» Effective implementation requires IT governance
processes, organizational structures, and capabilities
including (e.g.):
– Global governance board
– Local governance board
– Design authorities
– Working parties
250
Benefits of Architecture Govenance
» Links processes, resources, and information to

organizational strategies and objectives
» Integrates and institutionalizes best practices
» Aligns with industry frameworks
» Enables the organization to take full advantage of its
assets
» Protects the underlying digital assets of the organization
» Supports regulatory and best practice requirements
» Promotes visible risk management
251

Architecture Governance in Practice
Key success factors include:

» Best practices for 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
Continued
252
Architecture Governance in Practice
» Tools and processes to procedurally and culturally

promote take-up
» Management of criteria to control architecture
governance processes, dispensations, compliance
assessments, SLAs, and OLAs
» Meet internal and external requirements for
effectiveness, efficiency, confidentiality, integrity,
availability, compliance, and reliability of architecture
governance-related information, services, and processes
253

Architecture Board
» The Board oversees implementation of the governance

strategy
» Board comprises of representative stakeholders
responsible for review and maintenance of architecture
typically at 2 levels:
– Local (domain experts, line responsibility)
– Global (organization-wide responsibility)
Board has identifiable and articulated:
• Responsibilities and decision-making capabilities
• Remit and authority limits
254
Architecture Board Value
» Cost is offset by preventing one-off solutions and

unconstrained developments which lead to:
– High costs of development, operation and support,
due to numerous run-time environments, languages,
interfaces, protocols ...
– Lower quality
– Higher risk
– Difficulty in replicating and re-using solutions
255

Architecture Board Responsibilities
» Providing the basis for all decision-making with regard to changes to

the architectures
» Ensuring consistency between sub-architectures
» Establishing targets for re-use of components
» Ensuring flexibility of Enterprise Architecture:
– To meet changing business needs
– To leverage new technologies
» Enforcement of Architecture Compliance
» Improving the architecture maturity level within the organization
» Ensuring that the discipline of architecture-based development is
adopted
» Supporting a visible escalation capability for out-of-bounds decisions
256
Architecture Board Operations
» TOGAF provides guidance on operations of the Board

» These are primarily focused on best practice for meeting
management
» For example:
– Meetings should be conducted with clearly defined agendas
– Each participant attending a meeting should be fully prepared
» TOGAF provides a sample outline agenda
257

Architecture Contracts
» Joint agreements between development

partners and sponsors on the deliverables,
qualify and fitness-for-purpose of an architecture
258
Architecture Contracts
» Use of Architecture Contracts ensures

– Continuous monitoring to check integrity, changes, decision-
making, and audit of all architecture-related activities
– Adherence to the principles, standards, and requirements of the
existing or developing architectures
– Identification of risks
– A set of processes and practices that ensure accountability,
responsibility, and discipline with regard to the development and
usage of all architectural artifacts
– A formal understanding of the governance organization
259

Architecture Contracts and the ADM
» The Statement of Architecture Work created in

Phase A
» Architectures Domains (Business, Data,
Application, Technology)
» Phase G
» Implementation projects
260
Test Yourself Question
Q. Which of the following is an example of an IT

governance framework?
A. ITIL
B. Prince 2
C. COBIT
D. TOGAF
E. ATAM
261

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 Enterprise
Architecture capability management and governance
» Write requests for change for existing projects
» Scope new Enterprise Architecture work
» Determine constraints on Enterprise Architecture work
» Review and agree with sponsors and board
» Assess budget requirements
262
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 relate to architecture work, and
include:
– Architecture process principles
– Architecture implementation principles
263

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
264
TOGAF Template for Principles
Name
» Should represent the essence of the rule, and be
memorable
» Should not mention specific technology platforms
» Should avoid ambiguous words
Statement
» Should succinctly and unambiguously communicate the
fundamental rule
Continued…
265

TOGAF Template for Principles
Rationale
» Should highlight the business benefits of adhering to the
principle, using business terminology
» Should describe the relationship to other principles
Implications
» Should highlight the requirements for the business and

for IT for carrying out the principle.
» Should state the business impact and consequences of
adopting the principle
266
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…
267

An Example Statement of Principles
7. Custodianship
8. De-Customization
9. Painless User Experience
10. Self-Serve
11. Sharing of Information
Architecture Principles:
1. De-Skill The Open Group Case Study: Y082
2. One Source
https://publications.opengroup.org/y082
3. Content Management
268
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.
269

Example: Self-Serve
Statement Customers should be able to serve themselves
Rationale Applying this principle will improve customer satisfaction,

reduce administrative overhead, and potentially improve
revenue.
Implications There is an implication to improve ease-of-use and

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

1. Understandable: they can be quickly grasped. Intent
is clear and unambiguous.
2. Robust: they enable good decisions about
architectures and plans, and enable enforceable
policies and standards to be created. A principle must
be precise to support consistent decision making in
complex situations.
3. Complete: every potentially important principle
governing the management of IT is defined.
Principles cover every situation perceived.
Continued…
271

Five Qualities of Principles
4. Consistent: strict adherence to one principle may

require loose interpretation of another. Principles
must be expressed in a way that allows a balance of
interpretations and should not be contradictory.
5. Stable: Principles must be enduring, yet able to
accommodate change.
An amendment process should be established for
adding, removing, or altering principles after they
are ratified.
272
Principles and the Metamodel
» Information related to
Principles can be modeled, if
the right information is
captured
» The metamodel relates
Principles back to specific
drivers, goals and objectives
273

5. Tailor the TOGAF framework and, if any,

other Selected Architecture Frameworks
» Terminology Tailoring: it is best to use terminology that is
understood across the enterprise.
» Process Tailoring: the ADM is a generic process. Process
tailoring allows us to remove tasks that are done elsewhere,
add organization-specific tasks and align the ADM
processes with external process frameworks.
» Content Tailoring: using the TOGAF Architecture Content
Framework, this allows adoption of third-party content
frameworks and customization of the framework to support
organization-specific requirements
274
Terminology Tailoring
» Lack of agreement on the precise meanings of terms can
cause problems of communication during the Architecture
Engagement.
» Define and agree standard terminology
» Provide a Glossary, if appropriate
275

Process Tailoring
» Re-order the phases of the ADM

» Only use a subset of the phases
» Complete the Information Systems or Technology
Architecture first
276
Content Tailoring
277

What is a metamodel?
» A metamodel is a precise definition of the constructs and

rules needed for creating models
– Source www.metamodel.com
» A model that describes how and with what the

architecture will be described in a structured way.
– TOGAF Standard, Version 9.2, Chapter 3 Definitions
278
Why a metamodel?
279

Benefits of the Metamodel
The content metamodel provides a number of benefits:

» It formalizes the definition of an Enterprise Architecture
» It formalizes the relationship between objects
» It enables an EA tool mapping
280
Formal and Informal Modeling
» When defining architecture content there are choices to

be made on the level of structure and formality
» In some cases very formal specific language is needed
in order to articulate and govern in a precise or detailed
way
» In other cases the use of formal engineering discipline
will result in architecture content that is:
– inappropriate for the audience
– difficult to communicate
281

Core Content Metamodel Concepts
» A TOGAF architecture is based on

– Defining architectural building blocks within architecture
catalogs
– Specifying the relationships between those building blocks in
architecture matrices
– And presenting communication diagrams that show in a precise
way what the architecture is
» The metamodel is structured into Core and Extension
content
– Core content is designed not to be altered
282
Core and Extension Content
» In order to support many scenarios the metamodel has

been partitioned into core and extension content
» The core provides a minimum set of architectural
content to support traceability across artifacts
» The extension content allows for more specific or more
in-depth modeling
283

TOGAF Content Metamodel and its Extensions
284
Core Metamodel Entities
» Actor: A person, organization, or system that is outside the

consideration of the architecture model, but interacts with it.
» Application Component: An encapsulation of application functionality
that is aligned to implementation structuring.
» Business Capability: A particular ability that a business may possess
or exchange to achieve a specific purpose
» Business Service: Supports business capabilities through an explicitly
defined interface and is explicitly governed by an organization.
» Course of Action: Direction and focus provided by strategic goals and
objectives, often to deliver the value proposition characterized in the
business model
» Data Entity: An encapsulation of data that is recognized by a business
domain expert as a discrete concept. Data entities can be tied to
applications, repositories, and services and may be structured
according to implementation considerations.
» Function: Delivers business capabilities closely aligned to an
organization, but not explicitly governed by the organization.
285

’d)
Core Metamodel Entities (Cont’
» Information System Service: The automated elements of a business

service. An information system service may deliver or support all of one
or more business services.
» Organization Unit: A self-contained unit of resources with line
management responsibility, goals, objectives, and measures.
Organization units may include external parties and business partner
organizations.
» Role: An actor assumes a role to perform a task.
» Technology Component: An encapsulation of technology
infrastructure that represents a class of technology product or specific
technology product.
» Technology Service: A technical capability required to provide
enabling infrastructure that supports the delivery of applications.
» Value Stream: a representation of an end-to-end collection of value-
adding activities that create an overall result for a customer,
stakeholder, or end-user
286
Core Entities and their Relationships
287

Stakeholder Needs
Executive CxO
Programme
Management Office
Line
Management
Executive
Application
HR Line Management
Management
Infrastructure Procurement
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications
Stakeholder Types
QA / Standards Product Enterprise Technical

Groups Specialists Security Specialists
Corporate System End - User Project
288
The Content Metamodel
The content metamodel provides definitions of all the types

of building blocks that may exist, showing how they can
be described and related to one another.
» When creating and managing architectures, it is
necessary to consider concerns such as business
services, actors, applications, data entities, and
technology.
» The metamodel highlights these concerns, shows their
relationships and identifies artifacts that can be used to
represent them in a consistent way.
» The metamodel can also be used to provide guidance
to organizations that wish to implement their
architecture using an architecture tool.
289

Content Metamodel (Simplified)
290
Content Metamodel (Detailed)
291

Core Content Metamodel
292
TOGAF Standard, Version 9.2 Core Artifacts
293
293

Full Content
Metamodel
294
Full Content Metamodel with Relationships
295
Slide 295

Full Content Metamodel Artifacts
296
Metamodel Extensions
297

Governance
Extension
298
Governance Extension
» Scope:
– The ability to apply measures to
objectives and then link those
measures to services
– 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
» Additional diagrams to be created:
– Enterprise Manageability diagram
299

Governance Extension
» 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
300
Services Extension
301

Services Extension
» Scope:
– Creation of IS services as an extension of business service
– Business Use-Case Diagram
– Organization Decomposition Diagram
302
Services Extension
» 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 303

Process Modeling Extension
304
» Scope:
– 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
– Process Flow diagrams
– Event diagrams
305


– 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
306
Data Extension
307

Data Extension
» Scope:
– 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; analogous to
databases, registries, repositories,
schemas, and other techniques of
segmenting data
– Creation of data lifecycle, data
security, and data migration
diagrams to show data concerns in
more detail
» Additional diagrams to be created: :
– Data Security diagram
– Data Migration diagram
– Data Lifecycle diagram
308
Data Extension
» 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
309

Infrastructure Consolidation Extension
310
» Scope:
– 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 additional diagrams
• Additional diagrams to be created:
focusing on the location of assets,
• Process/System Realization diagram compliance with standards, structure
• Software Engineering diagram of applications, application
• Application Migration diagram migration, and infrastructure
• Software Distribution diagram configuration
• Processing diagram
• Networked Computing/Hardware diagram
• Network and Communications diagram
311


» 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
312
Motivation Extension
313

» The scope of this extension is as
follows:
– Creation of a new metamodel entity
for Driver that shows factors
generally motivating or constraining
an organization
for Goal that shows the strategic
purpose and mission of an
organization
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, and objectives
through to services
– Goal/Objective/Service diagram
314

– 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
315

Summary
The TOGAF standard provides a rich metamodel

This provides a number of benefits:
» It supports both formal and informal modeling
» It formalizes the definition of an Enterprise Architecture
» It formalizes the relationship between objects
» It enables an EA tool mapping
316
Exercise
» Determine which of the Metamodel extensions is most

appropriate for the following situations:
1. Where organizations have conflicting objectives
2. Where service levels are unknown
3. Where many applications are in use with overlapping
functionality
4. Where management of information is complex
5. Where business process has to support regulatory compliance
317

318
6. Develop Strategy and Implementation Plans for

Tools and Techniques
Develop a tools strategy to support the architecture activity.

» This should reflect the understanding and level of
formality required by the enterprise’s stakeholders.
» The implementation of the tools may range from a trivial
task to a more involved system implementation activity
utilizing the TOGAF Content Metamodel
319

Preliminary Phase
» The following security

artifacts should be
integrated into architecture
documentation:
– Business Drivers/Business
Objectives affecting security
– Security Principles
– Risk Appetite
– Key Risk Areas/Business
Impact Analysis
– Security Resource Plan
320
Preliminary Phase: Outputs
» Organizational model for

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

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

TOGAF Standard, Version 9.2 Artifacts
324
324
Catalogs P
Catalog Purpose
Principles The Principles catalog captures principles of the business and Architecture
Principles that describe what a "good" solution or architecture should look like.
Catalog Principles are used to evaluate and agree an outcome for architecture decision
points. Principles are also used as a tool to assist in architectural governance of
change initiatives.
The Principles catalog contains the following metamodel entities:
* Principle
325

Preliminary Phase
» The following security

artifacts should be
integrated into architecture
documentation:
– Business Drivers/Business
Objectives affecting security
– Security Principles
– Risk Appetite
– Key Risk Areas/Business
Impact Analysis
– Security Resource Plan
326
Exercises
» Select 7 principles at random from the Example Set of

Architecture Principles in the TOGAF Standard, Version
9.2 Chapter 20
» For each selected principle state whether it applies to
your organization or not, and give your reasons.
327

Q. Which one of the following is completed during the

Preliminary Phase of the TOGAF ADM?
A. Architecture Principles
B. Gap Analysis
C. Impact Analysis
D. Statement of Architecture Work
E. Requirements Gathering
328
Q. Which one of the following is a reason to adapt the

ADM?
A. The use of TOGAF is being integrated with another

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

Phase A:
Architecture
Vision

330
Architecture Vision – Objectives

» Develop a high-level aspirational vision of the
capabilities and business value to be delivered as a
result of the proposed Enterprise Architecture
» Obtain approval for a Statement of Architecture Work

that defines a program of works to develop and deploy
the architecture outlined in the Architecture Vision
331

Approach
» Phase A defines what is in and what is outside of the

architecture effort, and the constraints
» Constraints are informed by principles, business goals
and strategic drivers
» Creates the Architecture Vision document
– Clarifying and agreeing the purpose of the architecture
– Demonstrating how it will be achieved
– A first-cut high-level description of the Baseline and Target
architectures
– Integral to the Architecture Vision is an understanding of
emerging technologies and potential impact
– Business models and the business scenarios technique can be
used to develop the Architecture Vision
332
Phase A: Inputs
» Request for Architecture Work

(see next slide)
» Business principles, business
goals and drivers
» Organization Model for
Enterprise Architecture
» Tailored Architecture Framework,
including Architecture Principles
» Populated Architecture
Repository
333

Request for Architecture Work
» Organization Sponsors » External constraints, business

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

Steps Work; secure approval
10. Identify the business transformation risks
and mitigation activities
9. Define the Target Architecture value propositions
and KPIs
8. Develop Architecture Vision
7. Confirm and elaborate architecture principles, including
business principles
6. Define Scope
5. Assess readiness for business transformation
4. Evaluate capabilities
3. Confirm business goals, drivers, and constraints
2. Identify stakeholders, concerns, and business requirements
1. Establish the architecture project

335

Step 1: Establish the architecture project
Conduct the necessary procedures to secure:

• Recognition of the project
• Endorsement of corporate management
• Support and commitment of line management
Refer to other management frameworks:
• Explain how this project relates to those frameworks
336
Step 2: Identify stakeholders, concerns, and

business requirements
» Here we must identify:
– Candidate vision components and requirements
– Candidate scope boundaries for the engagement
– Stakeholder concerns, issues, and cultural factors
– The concerns and viewpoints that are relevant to this project
– The stakeholders that are involved with the project
– The key roles and responsibilities within the project
Another key task will be to consider which architecture views and

viewpoints need to be developed to satisfy the various stakeholder
requirements.
337

Stakeholder
Management

338
Overview
» Stakeholder Management is an important discipline that

successful architecture practitioners can use to win
support from others
» This technique should be used in Phase A to identify key
players and updated throughout each phase
» The output of this process forms part of the
Communications Plan
339

Benefits
» Identifies the most powerful stakeholders early and

ensures their input is used to shape the architecture
» Achieving support from the most powerful stakeholders
can help achieve necessary resources
» Early communication with stakeholders helps with
ensuring all understand the architecture process and are
engaged in it
» Can be used to anticipate likely reactions and develop a
strategy to address them
» Can be used to identify conflicting or competing objectives
amongst stakeholders and develop strategies to manage
340
Stakeholders
Executive CxO
Programme
Management Office
Line
Management
Stakeholders are individuals, teams,
organizations, or classes thereof,
Executive
having an interest in a system.
They are people who have key roles
HR Line in, or concerns about, the system; Application
Management
Management
for example, users, developers, etc.
Management
Functional /
IT Service Business
Business
Management Domain
Process
Experts
Experts
Data /Voice
Communications
Stakeholder Types

341

Stakeholder Management
Executive CxO
Programme
Management Office
The TOGAF standard provides a step by step

Line
Management
approach:
Executive
Step 1: Identify Stakeholders

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

342
Step 1: Identify Stakeholders
» Identify the key stakeholders of the enterprise

architecture.
» Look at who is impacted by the enterprise architecture
project:
– Who gains and who loses from this change?
– Who controls change management of processes?
– Who designs new systems?
– Who will make the decisions?
– Who procures IT systems and who decides what to buy?
– Who controls resources?
– Who has specialist skills the project needs?
– Who has influence?
343

Categories of Stakeholder
344
Step 2: Classify Stakeholder Positions
» Classify and record positions in a Stakeholder Analysis

Matrix
Stakeholder Stakeholder Ability to Current Required Current Required Required
Group Disrupt Understanding understanding commitment commitment support
the
change
CIO John H M H L M H
Smith
CFO Jeff M M M L M M
Brown
345

Step 3: Determine Stakeholder Management

Approach
» Work out stakeholder power, influence and interest, so

as to focus the engagement on the key individuals.
» These can then be mapped onto a power/interest matrix,
which is used to determine the strategy for engaging with
them.
346
Step 3: Determine Stakeholder Management

Approach
» Develop a Power/Interest Matrix and place Stakeholder

groups within it
347

Step 4: Tailor Engagement Deliverables
» For each Stakeholder Group:

– Identify the viewpoints that the architecture engagement needs
to produce and validate with each stakeholder group
– Define specific viewpoints, matrices, and views of the enterprise
architecture model..
348
Example: Stakeholder Map

STAKEHOLDER CLASS EXAMPLE KEY CONCERNS CLASS Catalogs, Matrices and Diagrams
GROUP ROLES
Corporate CxO CEO, CFO, The high level drivers, goals and KEEP Business Footprint diagram
Functions CIO, objectives of the organization, and how SATISFIED Goal/Objective/Service diagram
COO these are translated into an effective Organization Decomposition diagram
process and IT architecture to advance Business Capabilities catalog
the business. Capability/Organization matrix
Strategy/Capability Map
Corporate Program Project Portfolio Prioritizing, funding and aligning KEEP Requirements Catalog
Functions Management Managers change activity. An understanding of SATISFIED
Office project content and technical Business Footprint diagram
dependencies between projects adds a
further dimension of richness to Application
portfolio management decision making. Communication diagram
Functional
Decomposition diagram
Corporate Procurement Acquirers Understanding what building blocks KEY Technology Portfolio catalog
Functions of the architecture can be bought, and PLAYERS
what constraints (or rules) exist that are Technology Standards Catalog
relevant to the purchase. The acquirer
will shop with multiple vendors looking
for the best cost solution while adhering
to the constraints (or rules) applied by
the architecture, such as standards.
The
key concern is to make purchasing
decisions that fit the architecture, and
thereby to reduce the risk of added
costs
arising from non-compliant
components. 349

Summary
» Stakeholder Management is an important discipline that

successful architecture practitioners can use to win
support from others
» Identifies the most powerful stakeholders early and
ensures their input is used to shape the architecture
» Explicitly identifies viewpoints to address stakeholder
concerns
350
Business
Scenarios


Roadmap
352
Introduction
» Key factors in the success of any enterprise

architecture are:
– the extent to which it is linked to business
requirements,
» and
– its support for business objectives.
Business scenarios help us to identify and understand

the business requirements that the architecture
development must address.

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.
Business Scenarios
» The TOGAF Series Guide: Business Scenarios (G176)

defines a method for developing Business Scenarios
– It is positioned as a “method within a method”

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
356
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”

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

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
Developing a Business Scenario
1 - Identify, document and rank the problem 1 - problem

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

Developing a Business Scenario
4 - Identify the human actors and their place in the 1 - problem

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

Contents of 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
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

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

» Business Scenarios are just a technique, not an objective
» Use them, don’t get lost in them
Workshop Follow up
Focus Focus
Brainstorm/ Documentation and Allocate

Requirements
Interview Model of Business
Validation
Requirements to
Scenario Appropriate Forum
Sessions
Business Scenarios Provide Coherence and Consistency

Resources
» The Open Group Library

(http://publications.opengroup.org)
– The TOGAF Series Guide: Business Scenarios
– Examples of completed Business Scenarios

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
Architecture
Views and
Viewpoints

369

Concepts and Definitions
» System
» Stakeholder
» Concern
» Architecture View
» Architecture Viewpoint
370
System
» A system is a combination of interacting elements

organized to achieve one or more stated purposes.
Source: IONA
Source: SGI
371

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

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

373

Architecture View (synonym: View)
» An Architecture View is a representation of a system

from the perspective of a related set of concerns.
– An architect creates architecture models. An architecture view
consists of parts of these, chosen to show stakeholders that their
concerns are being met.
374
Architecture Viewpoint (synonym: Viewpoint)
» An Architecture Viewpoint defines the perspective from

which an architecture view is taken.
– It defines how to construct and use an architecture view, the
information needed, the modeling techniques for expressing and
analyzing it and a rationale for these choices (e.g. by describing
the purpose and intended audience of the view).
375

Source: ISO/IEC/IEEE Std 40210-2011. Used with permission 376
Architecture Views and Viewpoints
The architect uses architecture views and architecture

viewpoints in phases A to D for developing architectures for
each domain (business, data, application, technology).
» An architecture view is what you see.
» An architecture viewpoint is where you are looking from, the
vantage point or perspective that determines what you see
» Every architecture view has an associated architecture
viewpoint that describes it, at least implicitly.
» Architecture viewpoints are generic, and can be stored in
libraries for reuse. An architecture view is always specific to
the architecture for which it is created.
377

What is an Architecture View?
» A representation of an overall architecture with meaning

to one or more stakeholders in the system
» For example: a building architect might create wiring
diagrams, floor plans, and elevations to describe
different facets of a building to its different stakeholders
(electricians, owners, planning officials etc.)
» An enterprise architect might create physical and
security views of an IT system
378
A Simple Example of an Architecture Viewpoint
Architecture Viewpoint Description

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

A Simple Example of an Architecture View
Figure 1: Example View - The Open Group Business Domains 380
Developing Architecture Views in the ADM
The choice of which particular architecture views to

develop is one of the key decisions that the architect has
to make.
The architect has a responsibility for ensuring:
» the completeness of the architecture
– does it address all the concerns of its stakeholders?
» the integrity of the architecture
– can the architecture views be connected to each other?
– can the conflicting concerns be reconciled?
– what trade-offs have been made (e.g. between security and
performance)?
381

The Architecture View Creation Process
1. Refer to any existing libraries of architecture viewpoints.

2. Select key stakeholders.
3. Analyze their concerns and document them.
4. Select appropriate architecture viewpoints (based on
the stakeholders and their concerns).
5. Generate architecture views of the system using the
selected architecture viewpoints as templates.
382
Benefits
» Less work for the architects (the viewpoints have already

been defined and so the views can be created faster)
» Better comprehensibility for stakeholders (the viewpoints
are already familiar)
» Greater confidence in the validity of the views (their
viewpoints have a known track record)
383

The Architecture View Creation Process

(Cont’d)
If no libraries of architecture viewpoints exist then:

1. Select key stakeholders
2. Analyze their concerns and document them
3. Develop new architecture viewpoints (based on the
stakeholders and their concerns).
4. Generate views of the system using the new
architecture viewpoints as templates.
Alternatively create an ad hoc architecture view and then

consider whether a generalized form of the implicit
viewpoint should be defined explicitly and saved.
384
Using TOGAF Artifacts
» The TOGAF standard includes an example set of

recommended artifacts that can be adopted, enhanced
and combined to produce architecture views
» Three classes of artifacts are defined:
– Catalogs
– Matrices
– Diagrams
385

Catalogs
» Catalogs are lists of building blocks of a specific type, or

of related types
» For example
– Principles Catalog created in the Preliminary Phase
– Organization/Actor Catalog created in Phase B
– Driver/Goal/Objective Catalog
386
Matrices
» Matrices show the relationships between building blocks

of specific types
» Matrices are used to represent list-based rather than
graphical-based relationships
» For example
– The Stakeholder Map Matrix created in Phase A
387

Stakeholder Map Matrix

STAKEHOLDER KEY CONCERNS CLASS Catalogs, Matrices and
Diagrams
CxO – CEO, The high level drivers, goals and objectives of the KEEP Business Footprint diagram
CFO, CIO, organization, and how these are translated into an SATISFIED
COO effective process and IT architecture to advance the Goal/Objective/Service
business. diagram
Organization Decomposition
diagram
Program Prioritizing, funding and aligning change activity. KEEP Requirements Catalog
Management An understanding of project content and technical SATISFIED
Office dependencies between projects adds a further dimension Business Footprint diagram
– Project of richness to portfolio management decision making.
Portfolio Application
Managers Communication diagram
Functional
Decomposition diagram
Procurement Understanding what building blocks of the architecture KEY Technology Portfolio catalog
- Acquirers can be bought, and what constraints (or rules) exist that PLAYERS
are relevant to the purchase. The acquirer will shop with Technology Standards
multiple vendors looking for the best cost solution while Catalog
adhering to the constraints (or rules) applied by the
architecture, such as standards. The key concern is to
make purchasing decisions that fit the architecture, and
thereby to reduce the risk of added costs arising from
non-compliant components.
388
Diagrams
» Diagrams representing building blocks in a rich and

visual way, especially suited to stakeholder
communication.
» For example
– Value Chain diagram created in Phase A
– Business footprint diagram created in Phase B
389

Example Business Footprint Diagram
390
391
391

Summary
In general, TOGAF embraces the concepts and definitions of

ISO/IEC/IEEE 42010: 2011, specifically those that guide the
development of an architecture view and make the view
actionable, such as:
» Selecting key stakeholders
» Analyzing their concerns and documenting them
» Understanding how to model and deal with those concerns
The language used to depict the architecture view is the
architecture viewpoint. Viewpoints provide architecture
concepts from different perspectives, including components,
interfaces, and allocation of services critical to the view.
392
Summary
When applying the TOGAF framework a number of tailoring

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

Step 3: Confirm business goals, drivers and

constraints
Identify the business goals and strategic drivers of the

organization.
» If these have been defined elsewhere ensure that the
definitions are current, and clarify any areas of
ambiguity.
» Otherwise, define the goals and secure their
endorsement by management.
Define any constraints that must be dealt with.
394
Step 4: Evaluate capabilities
In this step we:

» Seek to understand the capabilities and desires of the
business
» Identify options to realize those capabilities
» Assess the implications for the organization’s
architecture capability
» Create an initial picture of the new capability that will be
required
» Document the results in a Capability Assessment
395

Value Chain Diagram
Source: Wikipedia.org 396
Capability based planning
Capability-based planning is a technique that focuses on

the planning, engineering and delivery of strategic
business capabilities.
It frames all phases of the architecture development in the
context of business outcomes, clearly linking the IT
vision, architectures (ABBs and SBBs), and the
Implementation and Migration Plans with the corporate
strategic, business, and line of business plans.
397

Capabilities
398
Capabilities are directly derived from the corporate

strategic plan. They must satisfy the enterprise goals,
objectives, and strategies. Most organizations will also
have an annual business plan.
» All of the architectures will be expressed in terms of
business outcomes and value.
» Phase A: the corporate strategic direction must drive
this
» Phases B, C, and D: specific capabilities must be
targeted for completion.
» Phase E: the capability increments must drive this.
399

400
Exercise
» Draw a capability increment Professional 70%

radar diagram to communicate Development
the current capability of an
enterprise which has reached Business 80%
capability increment 2 and has processes
obtained the following scores for
5 capability dimensions: Research & 60%
development
Information 70%
management
Equipment 60%
401

Step 5: Assess readiness for business

transformation
This assessment is based upon the determination and

rating of a series of readiness factors
These results are then used to:
» shape the scope of the architecture,
» identify activities required within the architecture project,
and to
» identify risk areas to be addressed
402
Business Transformation Readiness

Assessment
» Enterprise architecture often involves considerable
change.
» Understanding the readiness of an organization to
accept change, identifying the issues, and dealing with
them in the Implementation and Migration Plans is key to
successful architecture transformation in Phases E and
F. An initial assessment is carried out in Phase A.
» This is a joint effort between corporate (especially
human resources) staff, lines of business and IT
planners.
403

The Business Transformation Readiness

Assessment
Recommended activities when assessing readiness for
business transformation are:
1. Determine the readiness factors
2. Present the readiness factors using maturity models
3. Assess the readiness factors, and determine the
readiness factor ratings
4. Assess the risks for each readiness factor and identify
mitigating actions
5. Work these actions into Phase E and F Implementation
and Migration Plan
404
Readiness Factors
Typical factors that may affect the business transformation include:

» Vision - the ability to clearly define and communicate what is to be
achieved.
» Desire, Willingness, and Resolve
» Need
» Business Case
» Funding
» Sponsorship and Leadership
» Governance
» Accountability
» Workable Approach and Execution Model
» IT Capacity to Execute
» Enterprise Capacity to Execute
» Enterprise Ability to Implement and Operate
405

Assess the Readiness Factors
406
Readiness Factor Rating
407

Readiness Factor Risks & Actions
» Assess each factor using Risk Management techniques

» Identify a series of improvement actions
» Incorporate into the Implementation and Migration Plan
408
Step 6: Define the Scope
Define:
» Breadth of coverage
» Level of detail
» The partitioning characteristics of the architecture
» Domains to be covered
» Schedule project milestones
» Identify Enterprise Continuum assets for use:
– Created from previous ADM cycles
– Existing reference frameworks, models, and so on…
409

Step 7: Confirm and elaborate Architecture

Principles, including business principles
Ensure that any existing definitions are current, and clarify

any areas of ambiguity.
If principles do not exist, go to the body responsible for
architecture governance and together define the
principles.
Secure their endorsement by management.
410
Step 8: Develop Architecture Vision
Create a high-level view of the Baseline and Target

Architectures.
» Informal techniques are often used e.g. a simple
solution concept diagram can illustrate the main
components of the solution and its advantages.
» Business scenarios are useful here for discovering and
documenting business requirements.
» The result is the first, very high-level definition of the
baseline and target environments, from a business, IS
and technology perspective.
» This should be stored in the Architecture Repository.
411

Solution Concept Diagram
» A high-level representation of the solution envisaged

» A pencil sketch of the expected solution at the outset of
the engagement
Membership
Customers Conference Attendance
Certification
Publications
Interest,
consideration, Reliable, 24x7,
self service infrastructure
Join, renew
412
Building Blocks

413

Module Objectives
» To understand the concepts of Building Blocks within

TOGAF
– Architecture Building Blocks
– Solution Building Blocks
» To understand their role within application of the ADM
» A comparison with Architecture Patterns
414
Building Block Characteristics
» A package of functionality defined to meet the business

needs across an organization
» A building block has published interfaces to access
functionality
» A building block may interoperate with other, inter-
dependent building blocks
415

A Good Building Block
» Considers implementation and usage and evolves to

exploit technology and standards
» May be assembled from or a subassembly of other
building blocks
» Is reusable and replaceable
416
Building Blocks
» The way in which functionality, products and custom

developments are assembled into building blocks varies
widely
» Every organization must decide for itself the
arrangement
» A good choice can lead to improvements in system
integration, interoperability and flexibility
Continued
417

Building Blocks
» Systems are built from collections of building blocks

» They can be defined at many levels of detail
– Groupings at the functional such as a customer database are
known as Architecture Building Blocks
– Real products or specific custom developments are known as
Solutions Building Blocks
418
Architecture Building Blocks (ABBs)
» Architecture documentation and models from the

enterprise’s Architecture Continuum.
» They are defined or selecting during application of the
ADM
– Mainly in Phases A, B, C and D
» The characteristics are as follows
– They define what functionality will be implemented
– They capture business and technical requirements
– They are technology-aware
– They direct and guide the development of Solution Building
Blocks
419

ABB Specifications
» Fundamental functionality and attributes: semantics,

unambiguous, including security capability and
manageability
» Interfaces: chosen set, supplied (APIs, data formats,
protocols, hardware interfaces, standards)
» Dependent building blocks with required functionality and
named interfaces
» Map to business/organizations entities and policies
420
Solution Building Blocks (SBBs)
» Solutions Building Blocks relate to the Solutions

Continuum
» They can either be procured or developed
» The characteristics are as follows:
– They define what products and components will implement the
functionality
– They define the implementation
– They fulfil business requirements
– They are product or vendor-aware
421

SBB Specifications
» Specific functionality and attributes

» Interfaces: the implemented set
» Required SBBs used with required functionality and names of
interfaces used
» Mapping from the SBBs to the IT topology and operational policies
» Specifications of attributes shared such as security, manageability,
scalability
» Performance, configurability
» Design drivers and constraints including physical architecture
» Relationships between the SBBs and ABBs
422
Building Blocks and the ADM
» An architecture is a set of building blocks

– Depicted in an architectural model
– A specification of how those building blocks are connected to
meet the overall requirements of an information system
» The various building blocks in an architecture specify the
services required in an enterprise specific system
» The following general principles should apply:
– An architecture need only contain building blocks to implement
those services it requires
– Building blocks may implement one, more than one, or only part
of a service identified in the architecture
– Building blocks should conform to standards
423

Building Block Design
» The process of identifying building blocks includes

looking for collections of functions which require
integration
» Consider three classes of building blocks:
1. Re-usable building blocks such as legacy items
2. Building blocks to be developed (new applications)
3. Building blocks to be purchased (COTS applications)
» Use the desired level of integration to decide how to
bind functions into building blocks
424
In Phase A we start with

abstract entities
A high level model of

candidate building blocks
425


abstract entities In Phases B, C and D:
Building blocks within the
Business, Data, Applications and
Technology Architectures are
evolved to a common pattern of
steps
Step 1: Select Reference Models,

Viewpoints and Tools
The TOGAF standard provides
example catalogs, matrices and
diagrams for use
426

Step 2: Develop Baseline
abstract entities
Architecture Description
Develop a high-level model of

existing building blocks, re-using
definitions from the Architecture
Repository where they are available
427

In Phase A we start with Step 3: Develop Target

abstract entities Architecture Description
Develop view of required building blocks
through the creation of catalogs, matrices
and diagrams
Fully document each building block
Document rationale for building block
decisions
Identify the impacted building blocks
within the Architecture Repository, re-
using where appropriate
Where necessary, define new building
blocks
Select standards for each building block
Document mapping of building blocks to
Architecture Landscape
Identify building blocks for re-use, publish
as either standards or reference models
428
In Phase A we start with Step 4: Perform Gap Analysis

abstract entities
Identify building blocks carried
over
Identify eliminated building
blocks
Identify new building blocks
Identify gaps and determine
realization approach
429

In Phase A we start with Step 5: Define Candidate

abstract entities Roadmap Components
Step 6: Resolve Impacts across

the Architecture Landscape
Step 7: Formal Stakeholder

Review
Step 8: Finalize the Architecture
Step 9: Create the Architecture

Definition Document
430

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

in ABB and SBB forms
Associate building blocks with work

packages that will address the gaps
431

Architecture Patterns
» Pattern: defined as “an idea that has been useful in one

practical context and will probably be useful in others”
» In the TOGAF standard, patterns are considered to be a
technique for putting building blocks into context; for
example, to describe a re-usable solution to a problem.
» Building blocks are what you use: patterns can tell you
how you use them, when, why, and what trade-offs you
have to make in doing so.
432
Interoperability
» Interoperability is ‘‘the ability to share information and

services’’.
» The TOGAF standard provides techniques for

– Defining interoperability
– Refining interoperability
– Determining interoperability requirements
» The determination of interoperability occurs throughout

the ADM cycle
433

Interoperability and the ADM

The determination of interoperability occurs throughout the ADM:
» Architecture Vision: the nature and security considerations of

information and service exchanges are found using business
scenarios.
» Business Architecture: information and service exchanges are
defined in business terms.
» Data Architecture: the content of information exchanges is detailed
using the corporate data and/or information exchange model.
» Application Architecture: the way applications are to share
information and services is specified.
» Technology Architecture: appropriate technical mechanisms to
permit information and service exchanges are specified.
» Opportunities & Solutions: actual solutions are selected.
» Migration Planning: interoperability is implemented logically.
434
Examples
435

Interoperability requirements and solutions
The architect must ensure that there are no interoperability

conflicts, especially if re-using existing SBBs or using
COTS which have their own business processes and
information architectures.
Changes to the business processes will be the most difficult.
The workflow between the various systems must also be
taken into account.
The enterprise architect must also ensure that any change to
the business interoperability requirements is agreed by
the business architects and sponsors in a revised
Statement of Architecture Work.
436
Interoperability requirements and solutions
To find interoperability constraints consider:

» the Architecture Vision
» the Target Architecture
» the Implementation Factor Assessment and Deduction
matrix
» the Consolidated Gaps, Solutions, and Dependencies
matrix
437

Step 9: Define the Target Architecture value

propositions and KPIs
» Develop the business case for the architectures and

changes required
» Produce the value proposition for each of the
stakeholder groupings
» Assess and define the procurement requirements
» Review and agree the value propositions with the
sponsors and stakeholders
» Define the performance metrics
» Assess the business risk
» Incorporate the outputs in the Statement of Architecture
Work
438
Step 10:Identify the business transformation

risks and mitigation activities
» Identify the risks associated with the Architecture Vision,

assess the initial level of risk and its potential frequency.
There are two levels of risk to consider:
– 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)
» Assign a mitigation strategy for each risk. These should

be considered for inclusion within the Statement of
Architecture Work
439

Risk Management
» A technique used to mitigate risk when implementing an

architecture project.
» It is important to identify, classify, and mitigate these
risks before starting so that they can be tracked
throughout the transformation effort.
440
Risk Management in the ADM
There are two levels of risk that should be considered:

1. Initial Level of Risk: Risk categorization prior to
determining and implementing mitigating actions.
2. Residual Level of Risk: Risk categorization after
implementation of mitigating actions
The process for risk management is:
» Risk classification
» Risk identification
» Initial risk assessment
» Risk mitigation and residual risk assessment
» Risk monitoring
441

Risk Management in the ADM
Risks are identified in Phase A as part of the initial

Business Transformation Readiness Assessment
The risk identification and mitigation assessment
worksheets are maintained as governance artifacts and
are kept up-to-date in Phase G (Implementation
Governance) where risk monitoring is conducted.
Implementation governance can identify critical risks that
are not being mitigated and might require another full or
partial ADM cycle.
442
Initial risk assessment
The initial risk assessment is done by classifying risks with

respect to effect and frequency.
Effect can be assessed as:
» Catastrophic: critical financial loss that could result in
bankruptcy.
» Critical: serious financial loss in more than one line of
business leading to a loss in productivity and no ROI
» Marginal: minor financial loss in a line of business and
a reduced ROI on the IT investment.
» Negligible: minimal impact on services and/or
products.
Continued…
443

Frequency can be assessed as:

» Frequent: Likely to occur very often and/or
continuously.
» Likely: Occurs several times over the course of a
transformation cycle.
» Occasional: Occurs sporadically.
» Seldom: Remotely possible and would probably occur
not more than once in the course of a transformation
cycle.
» Unlikely: Will probably not occur during the course of a
transformation cycle.
444
The assessments of effect and frequency can then be

combined:
» Extremely High Risk (E): The transformation will most
likely fail with severe consequences.
» High Risk (H): Significant failure of parts of the
transformation resulting in certain goals not being
achieved.
» Moderate Risk (M): Noticeable failure of parts of the
transformation, threatening the success of some goals.
» Low Risk (L): Some goals will not be wholly successful.
445

Risk Classification Scheme
446
Risk Identification and Mitigation Worksheet
447

Step 11: Develop Statement of Architecture

Work; Secure approval
Assess the work products that are required to be produced

against the set of business performance requirements.
Activities will include:

» Identify new work products that need to be changed
» Provide direction on which existing work products,
including building blocks, need to be changed. Ensure
that all dependencies are coordinated
» Identify the impact of change on other work products
» Choose which architecture domains to develop,
depending on purpose, focus, scope, constraints
Continued… 448
Step 11: Develop Statement of Architecture

Work; Secure approval
» Assess the resource requirements

» Estimate the resources needed, develop a roadmap
and schedule for the proposed development and
document in the Statement of Architecture Work
» Define the performance metrics
» Develop the specific Enterprise Architecture
Communications Plan
» Review and agree the plans with the sponsors, and
secure formal approval of the Statement of
Architecture Work under the appropriate governance
procedures
» Gain sponsor’s sign-off
449

Statement of Architecture Work
» Title » Roles, responsibilities

and deliverables
» Architecture project
request and background » Acceptance criteria and
» Architecture project procedures
description and scope » Architecture project plan
» Overview of Architecture and schedule
vision
» Approvals
» Change of scope
procedures
450
Phase A: Architecture Vision
» Identify the complete list of

all stakeholders, their
concerns, and associated
requirements for approval of
the architecture.
» Satisfy security Stakeholders
» Satisfy business
stakeholders
451

Phase A: Outputs
» 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
» Architecture Principles including
business principles
Continued… 452
Phase A: Outputs
» Capability Assessment
» Tailored Architecture Framework
» Architecture Vision
» Draft Architecture Definition
Document
» Communications Plan
» Additional content populating the
Architecture Repository
453
Slide 453

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

456
456
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
457

TOGAF V92 Part2

Uploaded by

Document Informationclick to expand document informationaa

Document Informationclick to expand document information

Copyright:

Available Formats

TOGAF V92 Part2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TOGAF V92 Part2

Uploaded by

Copyright:

Available Formats

TOGAF® Standard Courseware V9.

TOGAF is a registered trademark of The Open

Copyright © The Open Group 2018

Preliminary Phase: Objectives in detail

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 1

Preliminary Phase: Objectives in detail

Copyright © The Open Group 2018

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 2

TOGAF is a registered trademark of The Open

Copyright © The Open Group 2018

Capability Maturity Models

» Capability Maturity Models (CMMs) provide an effective

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 3

Capability Maturity Models

» An evaluation of the organization’s practices against

Copyright © The Open Group 2018

Capability Maturity Models

» The original CMM was developed in the early 1990s by

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 4

Capability Maturity Models

There are templates available to assess:

Copyright © The Open Group 2018

» CMMI stands for Capability Maturity Model Integration.

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 5

Copyright © The Open Group 2018

SCAMPI, the Standard CMMI Appraisal Method for

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 6

US Department of Commerce ACMM

The enterprise Architecture Capability Maturity Model

Copyright © The Open Group 2018

ACMM Maturity Levels

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 7

ACMM Enterprise Architecture Elements

Copyright © The Open Group 2018

ACMM Enterprise Architecture Elements

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 8

Example: ACMM Scoring Criteria

0 No EA Not established or does not exist.

Copyright © The Open Group 2018

Maturity Assessments in the ADM

» Maturity Assessments are referred to in the Preliminary

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 9

» When using CMMs with the ADM, it is recommended

Copyright © The Open Group 2018

» Provide an assessment of your own company’s EA

Copyright © The Open Group 2018

Copyright 2009-2018, The Open Group 10

Preliminary Phase: Main inputs