enterprise architecture tjtse25 2009 yrityksen ... · enterprise architecture tjtse25 2009...
TRANSCRIPT
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