Post on 07-Dec-2014
description
© EAdirections 2010. All Rights Reserved.
EA Fundamentals:Core Concepts, Best Practices, & Winning Approaches
Tim Westbrock & George Paras
Managing Directors
twestbrock@eadirections.com
gparas@eadirections.com
June 15, 2010
© EAdirections 2010. All Rights Reserved.
Why We Are Here – As Leaders
• Aligning IT to business strategy
• Planning for major IT and business transformations
• Creating an effective "Office of the CIO"
• Executing global standards and reuse programs
• Manage complexity to maximize business value
• Implement ongoing enterprise optimization programs
• Etc.
2
© EAdirections 2010. All Rights Reserved.
Why We Are Here
• Make our businesses and IT organizations better…
– More cost effective
– More responsive and faster at solutions delivery
– More nimble/agile to realign to changing business needs
– More innovative
– More reliable, accurate and consistent – no surprises
• This is what many call “value delivery” and “being aligned”
• How we can do it – by making better decisions
– By being more informed
• About why, what, how and even when and where we deploy solutions
• Everyone!
– By working together instead of at cross-purposes
• By taking the long view and rationalizing the short view against it
• By taking the big (enterprise) view and rationalizing the small with it
(department, project, application, service, asset, capability, component,
etc.)
3
© EAdirections 2010. All Rights Reserved. 4
Question
What do you think of when you
hear the term
“Enterprise Architecture?”
© EAdirections 2010. All Rights Reserved. 5
Enterprise Architecture vs. Architecture
• EA often mistaken
for/positioned as:
– Systems Architecture
– Solutions Architecture
– Infrastructure Architecture
– SOA
– ??? Architecture
• EA is a separate and distinct
discipline that is higher-level,
more strategic, and longer-
term focused, but still must
be integrated with other
architecture disciplines
Enterprise Strategy
Enterprise Architecture
Bus
Arch
Info
Arch
App
Arch
Tech
Arch
Project 1 Project 2 . . . Project n
© EAdirections 2010. All Rights Reserved. 6
How to Get There? - The Problem
• How can an enterprise establish a reasonable idea for all
that has to happen in a complex organization to
accommodate necessary change in support of business
transformation?
Business
Operations
Business
Information
IT
Infrastructure
Business
Solutions
Strategy
© EAdirections 2010. All Rights Reserved. 7
By creating an Enterprise Architecture that …
• Expresses the impact of Business Strategy on the operations of
your business, the information you need, the applications that
support your business, and the infrastructure upon which they are
built
• Establishes a set of principles that drives consistent decision
making across disparate groups of decision makers
• Establishes/Publishes/Evolves a set of standards from which
projects and other implementation activities take direction
• Creates models that provide a broad context for impact analysis,
scenario planning, reuse opportunity identification
• Compares the future state against the current state and develops
a Roadmap that shows how to migrate from As-Is to To-Be
• Creates an environment of collaboration and consensus-building
between management, architects, SMEs, analysts, developers and
business sponsors
© EAdirections 2010. All Rights Reserved. 8
EA – Challenge of Overcoming the Inhibitors
Business Strategy
Current Objectives
Pro
ce
ss
es
Systems & Infrastructure
Inhibitors:
– Complexity
– Rate of Change
– Misalignment of Operations from Business Strategy
– Enterprise vs. Project Perspective
– Limited Reuse/Reusability
How can we:
– Reduce Complexity
– Decrease Delivery Time
– Align Business Strategy and Operations
– Reconcile Enterprise and Project Perspectives and
– Increase Reuse and Reusability?
Data & Information
© EAdirections 2010. All Rights Reserved.
So What Is This Thing Called EA?
9
Enterprise Architecture is a set of
artifacts/methods that help
BUSINESS LEADERS
make decisions about
DIRECTION
and communicate the
CHANGES
that need to occur in their enterprise to
achieve their vision.
© EAdirections 2010. All Rights Reserved. 10
Driving Business Transformation
Business Vision & Strategy
Bu
sin
es
s V
alu
e
Time
Bus. Info.
Tech. Sol.
Future State
Transformed
Enterprise
Transformationthrough Asset Portfolio Improvements,
Retirements, Consolidations,
Rationalizations, etc.
EA Creation
Current State
Bus. Info.
Tech. Sol.
Transformationthrough New Business Projects
Roadmaps & Lifecycles
© EAdirections 2010. All Rights Reserved. 11
Driving Business Transformation
Business Vision & Strategy
Bu
sin
ess V
alu
e
Time
Bus. Info.
Tech. Sol.
Future StateTransformed
Enterprise
Transformationthrough Asset Portfolio
Improvements, Retirements, Consolidations, Rationalizations, etc.
EA Creation
Current State
Bus. Info.
Tech. Sol.Transformation
through New Business Projects
Roadmaps & Lifecycles
Strategic Direction
Project Support
Portfolio Transformation
© EAdirections 2010. All Rights Reserved. 12
Enterprise Architecture Development (HL)
Identify
Business
Vision
Identify
Strategic
Capabilities
Define
Enterprise
Principles
Determine
Future
State
Identify
& Analyze
Gaps
Conduct
Impact
Analysis
Develop
Transformation
Roadmap
EnterpriseBusinessStrategy
TransformationRoadmap
• Identify Strategic Capabilities– Understand business strategy
– Decompose into more specific, applicable language
• Identify the capabilities that are required to support enterprise business strategies
– Models Help!
• Principle-Based
• Future State Definition– Standards/Guidelines/Rules
– Models – of all types, contexts, scope, audience and depth
• Comparison to Current State
• Linkage to Project Portfolio
• Lifecycle, Evolutionary
© EAdirections 2010. All Rights Reserved.
Create Artifacts that Speak Business
• Artifacts must to be at a high enough level of abstraction
that executives can fully understand them
– This means one page
• Content is Business-Oriented not Tech-Oriented
– Applications are a Business entity – understood by execs
– Infrastructure Complexity is best left out of the pictures
• Business Context Diagrams
– Shows the breadth of the business operations in one page
• HL Relationship Maps – provides further context for the
strategic conversation (examples in appendix)
– Function to Organization
– Function to Application
– Application to Information
– etc.
• EA is full of different views – Don‟t be afraid to create
multiple versions of an artifact aimed at different audiences
13
© EAdirections 2010. All Rights Reserved.
What Senior Execs Don‟t Want to See
14
© EAdirections 2010. All Rights Reserved.
Or This
15
© EAdirections 2010. All Rights Reserved. 16
Mapping the Application Systems to the FH
In the diagram below, the Application Systems are mapped to the FH. This can be very effective in understanding which applications support which functions as well as possible overlap. The Application Systems use the same color coding in this map as in the previous slide.
1.1
P
ublic
Re
latio
ns &
Co
mm
un
icatio
ns
1.2
A
dve
rtis
ing &
Bra
nd
Ma
nage
me
nt
1.3
M
ark
eting O
ps &
Lead G
enera
tion
2.1
P
rospectin
g &
Lead M
an
ag
em
en
t
2.2
Q
ualif
ica
tio
n
2.3
S
ale
s P
ropo
sals
2.4
S
ale
s N
ego
tiatio
ns &
Co
ntr
acts
3.1
R
ese
arc
h &
De
ve
lopm
en
t
3.2
P
roduct D
eve
lopm
en
t &
De
sig
n
3.3
P
roduct E
ngin
ee
ring
4.1
P
rocu
rem
ent
4.2
M
anufa
ctu
ring
4.3
In
vento
ry
4.4
S
hip
pin
g
4.5
C
usto
me
r S
erv
ice
4.6
R
etu
rns
5.1
P
urc
hasin
g
5.2
A
cco
un
ts R
ecie
va
ble
5.3
A
cco
unts
Pa
ya
ble
5.4
F
inancia
l R
epo
rtin
g
5.5
In
tern
al A
udit
5.6
H
um
an R
eso
urc
es
5.7
In
form
ation S
yste
ms (
IT)
5.8
Legal
Customer Relationship Management (CRM)
Leads
Contacts
Accounts
Campaigns
Financial System
General Ledger
Cash Management
Accounts Payable
Accounts Receivable
Fixed Assets
Supply Chain Management
Order Entry
Purchasing
Inventory
Forecasting
Manufacturing
Bill of Materials
Scheduling
Cost Management
Quality Control
Capacity Planning
Freight Management & Shipping
Freight Management & Shippping
Human Resources
Personnel
Payroll
Benefits
Time & Attendance
Content Managent
Content Management
etc.
etc.
etc.
System function
Co
mp
an
y A
BC
's I
nfo
rma
tio
n S
yste
ms
LEGEND
Company ABC
High Level Functional Hierarchy
4.0 Operations 5.0 Finance & Administration3.0 Engineering1.0 Marketing 2.0 Sales
© EAdirections 2010. All Rights Reserved. 17
ExecutiveManagement
ExistingOperations
EnterpriseArchitecture
BusinessStrategy
ProjectPortfolio
Mgt.
New/ChangedCapabilities
RequiredModels of theFuture StateEnterpriseModels of the
Current StateEnterprise
Object
ObjectObject
Object
Standard Service Request
Standard Service Response
CLIENT(Service
Requestor)
ServiceProviderWORK
Project B
Build &Integrate
Object
ObjectObject
Object
Standard Service Request
Standard Service Response
CLIENT(Service
Requestor)
ServiceProviderWORK
Object
ObjectObject
Object
Standard Service Request
Standard Service Response
CLIENT(Service
Requestor)
ServiceProviderWORK
Project C
Build &Integrate
Object
ObjectObject
Object
Standard Service Request
Standard Service Response
CLIENT(Service
Requestor)
ServiceProviderWORK
Project A
Build &Integrate
PopulateNew/Changed
Capabilities Delivered
TacticalProject
Requests
Input
GOVERNANCE
Annual, TacticalGoals, Objectives
& Targets
Represents
Transforms
EA becomes the driver of EPfM
EA Roadmap• Project Requests• Adds/Changes to Applications,
Infrastructure, Information, &
Business Processes
• Timeline/Interdependencies
© EAdirections 2010. All Rights Reserved. 18
Enterprise Governance
• Enterprise Governance is a consistent and interdependent system of people, process, and policy throughout the organization intended to ensure the intentions of the enterprise leadership are reflected in all decisions.
• Must be delegated authority by senior leadership
• Must understand strategy, EA and EPM; participation improves understanding
• Defines (approves) standards, policy, guidelines
• Must define consequences and apply them
© EAdirections 2010. All Rights Reserved. 19
Sample Organization Structure
• Combination EA/Governance org
structure
• Issue Resolution Groups are
chartered as needed by Architecture
Council
• Architecture Council members
should be delegated authority by
Steering Committee
– Mix of IT and business resources
• Decisions get escalated to Steering
Committee from Architecture
Council
• Architecture Council ≠ EA Core
Team
– EA Core Team is represented on ARB
• EPMO takes on responsibility for EA
compliance checks within SDLC
ExecutiveSteering
Committee
ArchitectureCouncil
IssueResolution
Groups
CIO
EACore Team
DomainTeam (s)
EPMO
© EAdirections 2010. All Rights Reserved. 20
EA vs. Subject Area Architect vs. Project ArchitectE
nte
rpri
se S
trate
gy
En
terp
rise A
rch
itectu
re
Bu
s
Arc
h
Info
Arc
h
Ap
p
Arc
h
Tech
Arc
h
Pro
jec
t 1
Pro
jec
t 2
. . .
Pro
jec
t n
InterpretedBy
Provides
Facilitates
Collaborates
• Principles• Standards• Patterns• Policy• Models• Services Needed
• Strategic Context• Best Practices• Research• Guidance• Leadership
Consults / Advises / Reviews
Collaborates
SubjectAreas Projects
Provides
• Principles• Standards• Design Patterns• Integration Approach• Models
• Project Design• Tech Selection• Service Design• Integration Design• Models
FEEDBACK
FEEDBACK
FEEDBACK
© EAdirections 2010. All Rights Reserved. 21
Governance Best Practices - Approval
• Authority Flows Down
– Must be granted, cannot be assumed
– EA Team has none
• Committees are not debate societies
– Up/Down votes required
• Establish committee protocols
– Membership Requirements/Proxy Rules
– Notification/Comment/Action Periods
– Quorum/Voting/Table/Veto Rules
• Consensus, Majority (Simple, ¾, etc.)
– Meeting Frequency
• Areas of Responsibility
– ESC vs. Architecture Council
– Escalation Rules
• Formal Sign-off Ceremony
• Publish Results
Perform
Analysis
Make
Recommendation
Review &
Deny or
Approve
Escalation
EA Approval
Stages
ArchitectureReviewBoard
ExecutiveSteering
Committee
EACore Team
DomainTeam (s)
© EAdirections 2010. All Rights Reserved. 22
Project Linkage
• EA must be defined from the Big-Picture perspective, but
realized at the project level
• Over time, the project level achieves more and more of the
strategic vision
• Project reviews must consider EA impact and guidance
• Proper checkpoints identified and criteria applied
– Including the transition of project documentation into the EA
repository
• Too many projects for EA to review; EPM must own project
review process and apply EA effectively
• Adherence to EA must be mandated; compliance expected;
deviation must be explained and approved
© EAdirections 2010. All Rights Reserved. 23
Governance Best Practices - Compliance
• EA Team Informs/Advises Process
– PROACTIVE - Coaches/Consults Project Teams EARLY
– Examines Projects for Compliance and identifies non-compliance concerns
– No Authority to Grant Exceptions• Informs EPMO of concerns/implications
• Projects request Exceptions/Variances from EPMO
– Should have the support of the EA Team
• Governance Body (EPMO?) Manages Exception Process
– Integrates Compliance Process with SDLC(s)
– Presents findings to Architecture Council
– Council Escalates to ESC
– Directs Project as to Outcomes
• EA Team uses results of process to improve EA Content
• Metrics kept by EPMO, analyzed by EA Core Team
Project
Proposal
HL
Design
Review
Detailed
Design
Review
Post-Project
Project Life
Cycle Gates
© EAdirections 2010. All Rights Reserved. 24
Conclusion: The Demands of Enterprise-ishness
• Our perspective: EA must be driven by the overarching business strategy of the „Enterprise‟
– Reflective of the desired operating model*
– Take a holistic view
– Identifying and enabling requirements for business capabilities that are enterprise-wide in scope (often not clearly articulated by the business)
– Make decisions that are optimal for the enterprise not a specific project or LOB
• Consequently, EA efforts must emphasize an „E‟-view– The scope of EA is THE ENTERPRISE
• “Solidify the Abstract” and “Simplify the Complex”
– Gaining stakeholder support
– EA team structure and participants
– Governance
– Communication
• EA must demonstrate clear & unambiguous enterprise-wide linkages; and, as appropriate, explicit decomposition
– Enterprise Business Strategy to EA & Project Portfolio Management
– Business Architecture to Information Architecture to Application Architecture to Technology Architecture
* Enterprise Architecture as Strategy: Creating a Foundation for Business Execution by Peter Weill, David C. Robertson and Jeanne W. Ross
© EAdirections 2010. All Rights Reserved. 25
OVERVIEW
10 Requirements for Enterprise Adoption
1. Analyzing and presenting an „Enterprise View‟
2. Linking EA to overall Business Strategy
3. Optimizing for the Enterprise not the Project
4. Addressing Culture, Politics & Leadership
5. EA Team Structure & Participants („E‟-level)
6. Approval of EA strategies and artifacts
7. Communicating „E‟ deliverables to leadership
8. „E‟ requirements of a federated business model
9. Sequencing and prioritizing EA tasks
10. Proactive & holistic planning
© EAdirections 2010. All Rights Reserved. 26
© EAdirections 2010. All Rights Reserved.
About EAdirections
27
Tim Westbrock
George S. Paras
We Work WITH You To:• Improve the value of IT to your enterprise
• Improve Enterprise Architecture (EA) programs
• Refine/Tune Governance Mechanisms
• Create a Portfolio-Based Culture
• Integrate Management Disciplines
• Unify Business/IT Perspectives
• Operate a World-Class Office of the CIO
• Balance the Strategic with the Tactical
How We Do It:• Continuous Mentoring of IT Leaders
• CIO, EA Team, PMO, Office of the CIO, etc.
• Assess Org Structures, People, Teams
• Build Internal Support and Sponsorship
• Analyze and Drive Activity Plans
• Review and Improve Processes & Deliverables
• Contribute Relevant Examples & Research
• Provide Pragmatic, Objective, Unbiased and Prescriptive Feedback on Everything You DoSubscribe to our
Newsletter: http://eepurl.com/bQ4_
www.EAdirections.com
© EAdirections 2010. All Rights Reserved. 28
Our Approach – Build Effective EA Organizations
13© EAdirections 2008. All Rights Reserved.
Mapping the Application Systems to the FH
In the diagram below, the Application Systems are mapped to the FH. This can be very effective in understanding which applications support which functions as well as possible overlap. The Application Systems use the same color coding in this map as in the previous slide.
1.1
P
ublic
Re
latio
ns &
Co
mm
un
ica
tio
ns
1.2
A
dve
rtis
ing &
Bra
nd
Ma
na
ge
me
nt
1.3
M
ark
eting O
ps &
Lead G
enera
tion
2.1
P
rosp
ectin
g &
Lea
d M
an
ag
em
en
t
2.2
Q
ualif
ica
tio
n
2.3
S
ale
s P
ropo
sa
ls
2.4
S
ale
s N
ego
tia
tio
ns &
Co
ntr
acts
3.1
R
ese
arc
h &
De
ve
lopm
en
t
3.2
P
rodu
ct
De
ve
lopm
en
t &
De
sig
n
3.3
P
rodu
ct
En
gin
ee
ring
4.1
P
rocu
rem
ent
4.2
M
anufa
ctu
ring
4.3
In
vento
ry
4.4
S
hip
pin
g
4.5
C
usto
me
r S
erv
ice
4.6
R
etu
rns
5.1
P
urc
hasin
g
5.2
A
cco
un
ts R
ecie
va
ble
5.3
A
cco
un
ts P
aya
ble
5.4
F
inan
cia
l R
epo
rtin
g
5.5
In
tern
al A
udit
5.6
H
um
an R
eso
urc
es
5.7
In
form
ation S
yste
ms (
IT)
5.8
Legal
Customer Relationship Management (CRM)
Leads
Contacts
Accounts
Campaigns
Financial System
General Ledger
Cash Management
Accounts Payable
Accounts Receivable
Fixed Assets
Supply Chain Management
Order Entry
Purchasing
Inventory
Forecasting
Manufacturing
Bill of Materials
Scheduling
Cost Management
Quality Control
Capacity Planning
Freight Management & Shipping
Freight Management & Shippping
Human Resources
Personnel
Payroll
Benefits
Time & Attendance
Content Managent
Content Management
etc.
etc.
etc.
System function
Co
mp
an
y A
BC
's I
nfo
rma
tio
n S
yste
ms
LEGEND
Company ABC
High Level Functional Hierarchy
4.0 Operations 5.0 Finance & Administration3.0 Engineering1.0 Marketing 2.0 Sales
Ongoing Mentoring– Make our clients more effective– IT Strategy, Business/IT Alignment, Business Transformation,
Project Management, Application Portfolio, Enterprise Architecture, IT Governance, Cost Optimization, etc.
– Individuals or Teams– Retainer based
Providing „Jump Start‟ Materials & Other Research– Provide „quick & dirty‟ enterprise-wide templates for demonstrating
Business/IT Alignment , Enterprise Architecture, etc.– Templates for demonstrating Business/IT alignment– Tools for „Business Fit‟ vs. Technical Fit‟, etc.– Perform on-going research
Building the Extended Team– Refine mission, strategy, roles and responsibilities– Establish communications strategy to enroll support– Build a culture of collaboration and effectiveness focused on
„enterprise outcomes‟
Assessing Activities & Review Deliverables– Provide honest feedback and prescriptive advice– Critique documents to improve effectiveness especially for C-level– Guide development of new artifacts– Ongoing review of emerging issues
© EAdirections 2010. All Rights Reserved.
Additional Slides
29
APPENDIX
© EAdirections 2010. All Rights Reserved. 30
Defining Enterprise Principles
• Principles are primarily from 2 sources:
– Best Practices analysis
• What best practices should be adopted
– Current state SWOT analysis
• How do we overcome weaknesses?
• How do we continue our strengths?
• How do we leverage opportunities?
• How do we overcome threats?
• Global Principles
– EA level
• Subject Area Principles
– EBA, EIA, ETA, ESA
• Domain Level Principles
– Network, Application Development, Data Modeling
© EAdirections 2010. All Rights Reserved. 31
What Does a Principle Look Like?
• Principles vs. best practices: What‟s the difference?
• A principle is:
– Title
– Short description
– Rationale/justification
– Implications
• Evaluating principles
– Treat as a set, not just as individual principles
– Resolving conflicts
“Title: CA Principle”
• Description: A bit more detail
• Rationale: Why is this important, and why does it support the requirements?
• Implications: What does this mean to the organization? What happens if you do, or do NOT, do this?
© EAdirections 2010. All Rights Reserved. 32
Example Principles
• EA must be primarily driven to increase business value, while enabling the enterprise to change more and more quickly and reducing complexity wherever possible.
• EA Governance is part of the Overall Enterprise Governance approach.
• Information Is Managed and Leveraged as an Enterprise Asset
• Evolve holistic enterprise architecture that models the business operating model, information environment, solutions portfolio and technology infrastructure.
• Enterprise architecture development must be an insourced effort, supplemented if needed, by outside expertise and resources to develop and support the competency of internal resources dedicated to EA.
• Information will be location transparent.
• All modules and processes will be designed as loosely coupled and highly granular using a component based development process.
• Design applications for platform independence.
© EAdirections 2010. All Rights Reserved. 33
Full Principle Example
• “All solutions must conform to common, enterprise interoperability standards”
– Everyone responsible for developing new IT solutions is required to use standard facilities to ensure
interoperability with other legacy and any newly designed solutions
• Rationale
– To support the “single view of the customer” direction, to freely exchange information, and to permit the agility
necessary to redesign business processes, all solutions must be implemented on a single, standard
interoperability framework
• Implications
– Compromises will be needed from line-of-business development units to adopt enterprise solutions rather than
custom solutions
– In some instances, the cost of adopting a standard solution may be greater than adopting a specialized solution
– Standard data definitions must be established
– Standard message formats and semantics must be agreed to and implemented
© EAdirections 2010. All Rights Reserved. 34
Modeling
• Models have a variety of characteristics determined by:
– Audience
– Purpose (communication vs. analysis)
– Level of detail (enterprise different from project level of detail)
• Don‟t model for the sake of modeling
– Are you modeling something that is likely to change? Why capture
great levels of detail?
– Are you modeling potential future state? What level of detail is
appropriate given the unknowns?
• Increased maturity demands simplification of more complex
relationships (depth and breadth)
© EAdirections 2010. All Rights Reserved. 35
EA Future State Development Context
Value
Network
Analysis
Business
Scenario
Models
Information
Value Chain
Analysis
Business
Event
Analysis
Function/
Process
Decomposition
Integration
Models
Services Level
Enterprise Solutions Architecture
Enterprise Technology Architecture
Enterprise Information Architecture
Enterprise Business Architecture
Capabilities Level
Enterprise Solutions Architecture
Enterprise Technology Architecture
Enterprise Information Architecture
Enterprise Business Architecture
Scenario Level
Enterprise Solutions Architecture
Enterprise Technology Architecture
Enterprise Information Architecture
Enterprise Business Architecture
“The Big Picture”
Enterprise Solutions Architecture
Enterprise Technology Architecture
Enterprise Information Architecture
Enterprise Business ArchitectureEnterprise
Business
Strategy
Enterprise
Intelligence
Service
Catalog
Solutions
Portfolio
Enterprise
Principles
(CA)
Required
Capabilities
(CRV)
Use
Cases
Context
Diagrams
Swimlane
Diagrams
Service
Function
Models
IT
Standards
EA Focus
EA Focus
EA/Project Focus
Project Focus
© EAdirections 2010. All Rights Reserved. 36
Modeling Summary
• While the science (standard notation, terminology, use-
cases, etc.) is growing, there is more art the higher the level
you are modeling at
– Standards like UML, BPMN, BPEL are continuing to gain
momentum, but they are closer to the developer
• Finding ways to get other parts of the organization to
contribute both current and future state models to the EA
Repository is critical
– EA must take responsibility for stewarding modeling tools,
approaches, standards, naming conventions, metadata from top to
bottom
• Use the HL Strategic Context Models to direct/prioritize the
areas in which to invest more detailed modeling effort