Enterprise ArchitectureTJTSE25 2009

Yrityksen kokonaisarkkitehtuuri

J u k k a ( J u p s ) H e i k k i l äP r o f e s s o r , I S ( e B u s i n e s s )

F a c u l t y o f I n f o r m a t i o n T e c h n o l o g y

U n i v e r s i t y o f J y v ä s k y l ä

e - m a i l : j u p s @ c c . j y u . f i

t e l : + 3 5 8 5 0 5 8 1 8 3 6 1

h t t p : / / w w w . c s . j y u . f i / e l

1

Preliminary phase: objectives

1/2To review the organizational context for conducting enterprise architecture (Current processes, models, frameworks; capabilities, stakeholders; business strategies, business principles, etc.)

To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive

To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process

To enable the architecture sponsor to create requirements for work across the affected business areas

To identify and scope the elements of the enterprise organizations affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment)

To define the ‘‘architecture footprint’’ for the organization — the people responsible for performing architecture work,where they are located, and their responsibilities

Getting ready for the journey

2

Preliminary phase: objectives 2/2

To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)

To confirm a governance and support framework that will provide business process and resources for architecture governance through the ADM cycle; these will confirm the fitness-for-purpose of the Target Architecture and measure its ongoing effectiveness (normally includes a pilot project)

To select and implement supporting tools and other infrastructure to support the architecture activity

To define the architecture principles that will form part of the constraints on any architecture work

Getting ready for the journey

3

Preliminary phase: Main aspects

Defining the enterprise

Identifying key drivers and elements in the organizational context

Defining the requirements for architecture work

Defining the architecture principles that will inform any architecture work

Defining the framework to be used

Defining the relationships between management frameworks (wait a minute)

Evaluating the enterprise architecture maturity (with e.g. Capability Maturity Models), or EAMM (will return to this later))

Deciding upon the terrain, route, pace

and equipment

4

Steps

Scope the enterprise organizations impacted

Confirm governance and support frameworks

Define and establish enterprise architecture team and organization

Identify and establish architecture principles

Select and tailor architecture framework(s)

Implement architecture tools

The game and the rules

5

The architecture vision 1/2 (thin?)

Establish the architecture project

Identify stakeholders, concerns, and business requirements

Steps in the Stakeholder Management Process Stakeholder Management

24.3.4 Tailor Engagement Deliverables

Identify viewpoints, matr ices, and views that the architecture engagement needs to produce and

validate with each stakeholder group to deliver an effective architecture model.

It is important to pay par ticular attention to stakeholder interests by defining specific viewpoints,

matr ices, and views of the enterpr ise architecture model. This enables the architecture to be

communicated to, and understood by, all the stakeholders, and enables them to ver ify that the

enter prise architecture initiative will address their concerns.

24.4 Template Stakeholder Map

The following table provides an example stakeholder map for a TOGAF architecture project.

Relevant

Stakeholder Involvement Class Viewpoints

CxO

(Cor porate

Functions);

e.g., CEO, CFO,

CIO, COO

This stakeholder group is

interested in the high-level

dr ivers, goals, and

objectives of the

organization, and how these

are translated into an

effective process and IT

architecture to advance the

business.

KEEP SATISFIED Business Footpr int

Goal/Objective/

Ser vice Model

Organization Chart

Program

Management Office

(Cor porate

Functions);

e.g., Project

Portfolio Managers

This stakeholder group is

interested in prior itizing,

funding, and aligning

change activity. An

understanding of project

content and technical

dependencies between

projects adds a further

dimension of richness to

por tfolio management

decision-making.

KEEP SATISFIED Roadmaps

Business Footpr int

Application

Communication

Functional

Decomposition

286 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

Steps in the Stakeholder Management Process Stakeholder Management

Corporate Functions

CxO

End-userOrganization

ProjectOrganization

SystemOperations

Suppliers Regulatory Bodies

External

EnterpriseSecurity

Data/VoiceCommunications

InfrastructureManagement

ApplicationManagement

Service Desk

IT ServiceManagement

Technical Specialist

Product Specialist

Business Process/Functional Experts

Line Management

ExecutivesExecutives

Line Management

Business DomainExperts

Data Owners

HRProcurementQA/Standards

GroupsProgram

Management Office

Figure 24-1 Categor ies of Stakeholder

Consider both the Visible team — those obviously associated with the project/change — and the

Invisible team — those who must make a real contribution to the project/change for it to be

successful but who are not obviously associated with it (e.g., providers of support ser vices).

24.3.2 Classify Stakeholder Positions

Develop a good understanding of the most important stakeholders and record this analysis for

reference and refresh during the project. An example stakeholder analysis is shown in Table

24-1.

Ability to Current Required Current Required

Stakeholder Disrupt Under- Under- Commit- Commit- Required

Group Stakeholder Chang e standing standing ment ment Suppor t

CIO John Smith H M H L M H

CFO Jeff Brown M M M L M M

Table 24-1 Example Stakeholder Analysis

284 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()Important to

include all stakeholders to participate

and review every stage!

6

Confirm and elaborate business goals, business drivers, and constraints

Evaluate business capabilities

Assess readiness for business transformation

Define scope

Confirm and elaborate architecture principles, including business principles

Develop Architecture Vision

Define the Target Architecture value propositions and KPIs

Identify the business transformation risks and mitigation activities

Develop enterprise architecture plans and Statement of Architecture Work; secure approval

The architecture vision 2/2 (thin?)

7

Creating the Business Scenario Business Scenarios

Figure 26-2 Phases of Developing Business Scenarios

26.3.2 Gathering

The Gathering phase is where infor mation is collected on each of the areas in Figure 26-1. If

infor mation gather ing procedures and practices are already in place in an organization — for

example, to gather infor mation for strategic planning — they should be used as appropriate,

either during business scenario wor kshops or in place of business scenario wor kshops.

Multiple techniques may be used in this phase, such as infor mation research, qualitative

analysis, quantitative analysis, sur veys, requests for infor mation, etc. As much infor mation as

possible should be gathered and preprocessed ‘‘off-line’’ prior to any face-to-face wor kshops

(descr ibed below). For example, a request for infor mation may include a request for strategic and

operational plans. Such documents typically provide great insights, but the infor mation that they

contain usually requires significant preprocessing. The infor mation may be used to generate an

initial draft of the business scenario prior to the wor kshop, if possible. This will increase the

understanding and confidence of the architect, and the value of the wor kshop to its participants.

A ver y useful way to gather infor mation is to hold business scenario wor kshops, whereby a

business scenario consultant leads a select and small group of business representatives through

a number of questions to elicit the infor mation surrounding the problem being addressed by the

architecture effor t. The wor kshop attendees must be carefully selected from high levels in the

business and technical sides of the organization. It is important to get people that can and will

provide infor mation openly and honestly. Where a draft of the business scenario already exists

— for example, as a result of preprocessing infor mation gathered during this phase, as

descr ibed above — the wor kshop may also be used to review the state of the business scenario

draft.

Sometimes it is necessary to have multiple wor kshops: in some cases, to separate the gathering

of infor mation on the business side from the gathering of infor mation on the technical side; and

in other cases simply to get more infor mation from more people.

304 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

Info is processed and documented. The models are created to represent that information,typically visually

by e.g. qualitative and quantitative analysis, surveys, business scenario workshops

Multiple business scenario workshops or ‘‘readout’’ meetings with the sponsors and involved parties are recommended.

Better approach?

CMU SEI’s Architecture

Tradeoff Analysis Method

(ATAM)

8

ATAM (CMU SEI, 2003)

9

Business architecture:

ObjectivesTo describe the Baseline Business Architecture as-isTo develop a Target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and

strategic drivers (to-be, thin or fat)

To analyze the gaps between the Baseline and Target Business Architectures as-is and to-be fat) -> Gap AnalysisTo select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture

To select the relevant tools and techniques to be used in association with the selected viewpoints

10

Gap AnalysisGap Analysis Example

TargetArchitecture

BaselineArchitecture

VideoConferencing

Services

EnhancedTelephonyServices

Mailing ListServices

EliminatedServices

BroadcastServices

VideoConferencing

Services

EnhancedTelephonyServices

Shared ScreenServices

New

Included

Potential match

Gap: Enhancedservices to bedeveloped orproduced

Gap: To bedeveloped orproduced

Unintentionallyexcluded -a gap in TargetArchitecture

Intentionallyeliminated

Figure 27-1 Gap Analysis Example

Part III: ADM Guidelines and Techniques 323

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

11

Business architecture steps

Select Reference Models, Viewpoints, and Tools

simple documents or spreadsheets, or more sophisticated modeling tools and techniques, such as activity models, business process models, use-case models, etc.

The level and rigor of decomposition needed varies

Develop Baseline Business Architecture Description

Where no such descriptions exist, information will have to be gathered in whatever format comes to hand.

The analysis of the current state often has to be done bottom-up, particularly where little or no architecture assets exist. In such a case, the architect simply has to document the working assumptions about high-level architectures, and the process is one of gathering evidence to turn the working assumptions into facts.

12

Defining relationships between existing and forthcoming methods

Approach Preliminary Phase

domains (also known as People, Processes, and Material/Technology) to deliver a business

capability.

The main frameworks suggested to be co-ordinated with TOGAF are:

! Business Capability Management (Business Direction and Planning) that determines

what business capabilities are required to deliver business value including the definition of

retur n on investment and the requisite control/perfor mance 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.

! Solution Development Methods that for malize the way that business systems are

delivered in accordance with the structures developed in the IT architecture.

As illustrated in Figure 6-2, these frameworks are not discrete and there are significant overlaps

between them and the Business Capability Management. The latter includes the deliver y of

perfor mance measured business value.

The overall significance is that the enterpr ise architect applying TOGAF cannot narrowly focus

on the IT implementation, but must be aware of the impact that the architecture has on the entire

enter prise.

ArchitectureDevelopment

Method

SolutionDevelopment

Methods

OperationsManagement

Methods

BusinessCapability

Management

Portfolio/Project

ManagementMethods

Figure 6-2 Management Frameworks to Co-ordinate with TOGAF

72 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

13

Business architecture steps

Develop Target Business Architecture Description to-be fatlogical extension 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 modeling tools and techniques, such as (presented e.g. in Unified Modeling Language):

Activity Models (also called Business Process Models). The Object Management Group (OMG) has developed the Business Process Modeling Notation (BPMN), a standard for business process modeling that includes a language with which to specify business processes,their tasks/steps,and the documents produced.

Use-Case Models can describe either business processes or systems functions

Class models are similar to logical data models.

14

Business architecture steps

Target Business Architecture (version 1.0) includes

Organization structure — identifying business locations and relating them to organizational units

Business goals and objectives — for the enterprise and each organizational unit

Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions

Business services — the services that the enterprise and each enterprise unit provides to its customers,both internally and externally

Business processes,including measures and deliverables

Business roles,including development and modification of skills requirements

Business data model

Correlation of organization and functions — relate business functions to organizational units in the form of a matrix report

Yawn!

15

Biz Architecture (DOI, 2007)

16

Business architecture steps

Define Roadmap Components

required to prioritize activities over the coming phases.

Resolve Impacts Across the Architecture Landscape

Conduct Formal Stakeholder Review

Finalize the Business Architecture (document, select standards etc)

Create Architecture Definition Document

Are we sure we want to get there?

17

18

Simplified information architecture (Axelrod, 2006)

Addressing Data Quality

32 www.architecturejournal.net • Journal 10 •

and more complex phenomenon that we can call “poor quality of systems engineering in general.” Data quality is just the most tangible and obvious symptom that our business partners observe, not the root cause. (See Resources for an article in The Architecture Journal 8 that provides an example of how an attempt to work with data architecture separately from all the other architectural issues leads to potentially significant problems.) Since data plays such a prominent role in our discussion, let us first agree on what data is. Generally, most agree that data is a state-ment accepted at face value. In this article we are generally talking about the large class of data comprised of variable measurements, although the concepts apply to other types of data.

A notion that data is produced by measurements or observations is very significant. It points to a very important concept—a notion of data context or metadata—that is absolutely critical to the success of any data quality improvement effort. In other words, a number just by itself, stripped of its context, is not really meaningful for busi-ness users. For example, you have a customer. For the billing depart-ment, that customer is defined partially by one address, and for shipping it is likely defined by another. Without the context, you are not sure which locally unique aspects of the data definition apply.

Figure 1 Enterprise architecture three-layered model

If we know the context in which the customer interfaced with the enterprise, we now have a much better understanding of the business circumstances surrounding this number. This notion is at the crux of the poor data quality problem—lack of sufficient data context. We typically do not have enough supporting information to understand what a particular number (or a set of numbers) means, and we thus cannot make an accurate judgment about validity and applicability of the data. IT consultant Ellen Friedman puts it this way: “Trying to understand the business domain by understanding individual data elements out of context is like trying to understand a community by reading the phone book.” The class of data that is the subject here always exists within a context of a business process. To solve the poor data quality prob-lem, data context should always be well defined, well understood, and well managed by data producers and consumers. For example, from credit approval, legal approval, servicing approval, appraisal approval, custodial review, and investor review perspectives we have multiple subprocesses labeled “approval.” This context means there must be an agreement on the information architecture that gives the common aspects of the data and some way to negotiate and share local enhancements.

Data Quality AttributesAccording to Joseph M. Juran, a well-known authority in the quality control area and the author of the Pareto Principle (which is commonly referred to today as the “80–20 principle”), data are of high quality “if they are fit for their intended uses in operations, decision making, and planning. Alternatively, data are deemed of high quality if they

“WHAT IS COMMONLY CALLED THE ‘POOR

DATA QUALITY PROBLEM’ SHOULD BE MORE

APPROPRIATELY CALLED THE ‘DATA QUALITY

DEFICIENCY SYNDROME’”

Business strategy

Conceptual/businesscapabilities and

process layer

Capability1

processes

Capability2

processes

Capability3

processes

Capability4

processes

Enterprisegovernanceframework

Principlesand

heuristics

Conceptual enterprise information model

Logical enterprise information model

Logical/specification

layerTechnology

standards andguidelines

Enterpriseintegration

model

LOB-levelsystems

interfaces

Physicial/implementation

layer

Enterprisesystem A

specification

Services sourcecode

Componentssource code

Databaseschema/table 1

Databaseschema/table 2

XML schema

Enterprisesystem B

specification

19

Building block?

A building block is a package of functionality defined to meet the business needs across an organization.

A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)

Abuilding block has a defined boundary and is generally recognizable as ‘‘a thing’’

A building block’s boundary and specification should be loosely coupled to its implementation; i.e., it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block.

Component?20

Determine/confirm key corporate change attributes

Determine business constraints for implementation

Review and consolidate gap analysis results from Phases B to D

Review IT requirements from a functional perspective

Consolidate and reconcile interoperability requirements

Refine and validate dependencies

Confirm readiness and risk for business transformation

Formulate high-level Implementation and Migration Strategy

Identify and group major workpackages

Identify Transition Architectures

Create portfolio and project charters and update the architectures

Chapter 28: Migration Planning Techniques

This chapter contains a number of techniques used to support migration planning in Phases E and F.

28.1 Implementation Factor Assessment and Deduction Matrix

The technique of creating an Implementation Factor Assessment and Deduction matrix can be

used to document factors impacting the architecture Implementation and Migration Plan.

The matrix should include a list of the factors to be considered, their descriptions, and the

deductions that indicate the actions or constraints that have to be taken into consideration when

formulating the plans.

An example matrix is shown in Figure 28-1.

Change in Technology Shut down the messagecenters, saving 700personnel, and havethem replaced by email.

• Need for personneltraining, re-assignment

• Email has majorpersonnel savings andshould be given priority

Consolidation of Services

Introduction of NewCustomer Service

<Name of Factor>

Factor

Implementation Factor Assessment and Deduction Matrix

Description Deduction

<Description of Factor> <Impact on Migration Plan>

Figure 28-1 Implementation Factor Assessment and Deduction Matrix

Part III: ADM Guidelines and Techniques 325

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

Consolidation,

constraints/rules

and transition

21

Enterprise Architecture State Evolution Table Migration Planning Techniques

! Green: Service SBB in place (either new or retained).

! Yellow: Service being transitioned into a new solution.

! Red: Service to be replaced.

28.5 Business Value Assessment Technique

A technique to assess business value is to draw up a matr ix based on a value index dimension

and a risk index dimension. An example is shown in Figure 28-5. The value index should include

cr iter ia such as compliance to principles, financial contribution, strategic alignment, and

competitive position. The risk index should include criter ia such as size and complexity,

technology, organizational capacity, and impact of a failure. Each criter ion should be assigned an

individual weight.

The index and its criter ia and weighting should be developed and approved by senior

management. It is important to establish the decision-making criter ia before the options are

known.

Project B

Project E

Project A

Project C

Project D

Project F

Project G

Project H

Value

Risk

On target

At risk

In trouble

(Project size indicated by size of circle.)

Figure 28-5 Sample Project Assessment with Respect to Business Value and Risk

328 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

flaky ideas of migration

Confirm management framework interactions for Implementation and Migration Plan

Assign a business value to each project

Estimate resource requirements, project timings, and availability/ delivery vehicle

Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation

Confirm Transition Architecture increments/phases and update Architecture Definition Document

Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

Establish the architecture evolution cycle and document lessons learned

22

Confirm scope and priorities for deployment with development management

Identify deployment resources and skills

Guide development of solutions deployment

Perform enterprise architecture compliance reviews

Implement business and IT operations

Perform post-implementation review and close the implementation

Implementation’s been never this easy :-)

23

Establish value realization process

Deploy monitoring tools

Manage risks

Provide analysis for architecture change management

Develop change requirements to meet performance targets

Manage governance process

Activate the process to implement change

24

Objective is to define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases

25

Iterative processIf you think you haven’t TOGAFed

enough...

26

Mapping TOGAF Phases to Iteration Cycles Applying Iteration to the ADM

19.4 Mapping TOGAF Phases to Iteration Cycles

Each iteration cycle crosses multiple TOGAF ADM phases. The following tables show at a highlevel which phases should be completed for which iteration cycle, showing activity that is core(i.e., the primar y focus of the iteration), activity that is light (i.e., the secondary focus of theiteration), and activity that may be infor mally conducted (i.e., some activity may be carr ied out,but it is not explicitly mentioned in the ADM).

TOGAF Phase

Preliminary

Architecture Vision

BusinessArchitecture

ApplicationArchitecture

DataArchitecture

TechnologyArchitecture

Opportunities and Solutions

Migration Planning

Implementation Governance

Change Management

Baseline

Target

Baseline

Target

Baseline

Target

Baseline

Target

Informal

Informal

Informal

Informal

Informal

Informal Informal Informal Informal Informal

Informal

Informal Informal Informal

Informal Informal Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Informal

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Light

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

Core

InitialIteration Iteration 1 Iteration 2 Iteration n Iteration 1 Iteration n Iteration 1 Iteration n

ArchitectureGovernance

TransitionPlanning

ArchitectureDefinition

ArchitectureContext

Core: primary focus activity for the iteration

Light: secondary focus activity for the iteration

Informal: potential activity for the iteration, not formally mentioned in the method

Figure 19-2 Activity by Iteration for Baseline First Architecture Definition

218 TOGAF Version 9 (2009)

!"#$%#&'()*+(,-

.*/001*234*5,4)*67(%,8*9$$*:';3&<*:4<47"4=!"#$%#&'()*+(,->*?(&*@(7*74='<&7'A%&'()

27

!

An Introduction to TOGAF™ 9

"""#$%&'()$*%#$)(! A W h i t e P a p e r P u b l i s h e d b y T h e O p e n G r o u p +!

What does TOGAF Contain?

TOGAF reflects the structure and content of an architecture capability within an enterprise, as shown

in Figure 1.

Figure 1: TOGAF Content Overview

!

Central to TOGAF is the Architecture Development Method (documented in TOGAF 9, Part II). The

architecture capability (documented in TOGAF 9, Part VII) operates the method. The method is

supported by a number of guidelines and techniques (documented in TOGAF 9, Part III). This

produces content to be stored in the repository (documented in TOGAF 9, Part IV), which is classified

according to the Enterprise Continuum (documented in TOGAF 9, Part V). The repository is initially

populated with the TOGAF Reference Models (documented in TOGAF 9, Part VI).

Architecture Development Method (ADM)

The ADM describes how to derive an organization-specific enterprise architecture that addresses

business requirements. The ADM is the major component of TOGAF and provides guidance for

architects on a number of levels:

• It provides a number of architecture development phases (Business Architecture, Information

Systems Architectures, Technology Architecture) in a cycle, as an overall process template for

TOGAFsummary

28