Mais conteúdo relacionado
Semelhante a EAdirections Fundamental Concepts 6 15 2010 (20)
EAdirections Fundamental Concepts 6 15 2010
- 1. 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.
- 2. 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.
© EAdirections 2010. All Rights Reserved. 2
- 3. 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.)
© EAdirections 2010. All Rights Reserved. 3
- 4. Question
What do you think of when you
hear the term
“Enterprise Architecture?”
© EAdirections 2010. All Rights Reserved. 4
- 5. Enterprise Architecture vs. Architecture
• EA often mistaken
for/positioned as:
– Systems Architecture
– Solutions Architecture
– Infrastructure Architecture Enterprise Strategy
– SOA
Enterprise Architecture
– ??? Architecture
Bus Info App Tech
• EA is a separate and distinct Arch Arch Arch Arch
discipline that is higher-level,
more strategic, and longer- Project 1 Project 2 ... Project n
term focused, but still must
be integrated with other
architecture disciplines
© EAdirections 2010. All Rights Reserved. 5
- 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?
Strategy
Business
Operations
Business
Solutions
Business IT
Information Infrastructure
© EAdirections 2010. All Rights Reserved. 6
- 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. 7
- 8. EA – Challenge of Overcoming the Inhibitors
Business Strategy Inhibitors:
– Complexity
– Rate of Change
Current Objectives
– Misalignment of Operations
from Business Strategy
– Enterprise vs. Project
Perspective
– Limited Reuse/Reusability
Processes
How can we:
– Reduce Complexity
– Decrease Delivery Time
– Align Business Strategy and
Data & Information
Operations
– Reconcile Enterprise and
Project Perspectives and
– Increase Reuse and
Reusability?
Systems & Infrastructure
© EAdirections 2010. All Rights Reserved. 8
- 9. So What Is This Thing Called EA?
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. 9
- 10. Driving Business Transformation
Roadmaps & Lifecycles
Business Vision & Strategy EA Creation
Business Value
Bus. Info.
Transformation
through Asset Portfolio Improvements,
Tech. Sol.
Retirements, Consolidations,
Rationalizations, etc.
Future State
Transformed
Enterprise
Bus. Info.
Transformation
Tech. Sol. through New Business Projects
Current State
Time
© EAdirections 2010. All Rights Reserved. 10
- 11. Driving Business Transformation
Roadmaps & Lifecycles
Business Vision & Strategy EA Creation
Strategic
Portfolio Direction
Business Value
Transformation
Bus. Info.
Transformation
through Asset Portfolio
Tech. Sol.
Improvements, Retirements,
Consolidations, Rationalizations, etc.
Future State
Transformed
Enterprise
Bus. Info.
Transformation
Tech. Sol. through New Business Projects
Project Support
Current State
Time
© EAdirections 2010. All Rights Reserved. 11
- 12. Enterprise Architecture Development (HL)
Identify
Enterprise Business
Business
Vision
Strategy
Identify Define Determine Identify
Strategic Enterprise Future & Analyze
Capabilities Principles State Gaps
• Identify Strategic Capabilities Conduct
– Understand business strategy Impact
– Decompose into more specific, applicable Analysis
language
• Identify the capabilities that are required to
support enterprise business strategies
– Models Help! Develop
• Principle-Based Transformation
• Future State Definition Roadmap
– Standards/Guidelines/Rules
– Models – of all types, contexts, scope,
audience and depth
• Comparison to Current State Transformation
• Linkage to Project Portfolio Roadmap
• Lifecycle, Evolutionary
© EAdirections 2010. All Rights Reserved. 12
- 13. 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
© EAdirections 2010. All Rights Reserved. 13
- 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.
Company ABC
High Level Functional Hierarchy
1.0 Marketing 2.0 Sales 3.0 Engineering 4.0 Operations 5.0 Finance & Administration
1.1 Public Relations & Communications
1.3 Marketing Ops & Lead Generation
1.2 Advertising & Brand Management
2.1 Prospecting & Lead Management
3.2 Product Development & Design
2.4 Sales Negotiations & Contracts
3.1 Research & Development
5.7 Information Systems (IT)
5.2 Accounts Recievable
3.3 Product Engineering
5.4 Financial Reporting
5.6 Human Resources
5.3 Accounts Payable
4.5 Customer Service
2.3 Sales Proposals
4.2 Manufacturing
5.5 Internal Audit
4.1 Procurement
2.2 Qualification
5.1 Purchasing
4.3 Inventory
4.4 Shipping
4.6 Returns
5.8 Legal
Customer Relationship Management (CRM)
Leads
Contacts
Accounts
Campaigns
Financial System
General Ledger
Cash Management
Accounts Payable
Company ABC's Information Systems
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.
LEGEND
System function
© EAdirections 2010. All Rights Reserved. 16
- 17. EA becomes the driver of EPfM
Executive Business
Management Strategy Enterprise New/Changed
Architecture Capabilities Models of the
Required
Future State
Annual, Tactical Models of the Input Enterprise
Goals, Objectives
& Targets
Current State G
Enterprise
O
V
Represents
Existing Tactical
Project EA Roadmap
• Project Requests
Portfolio
Operations
E
Project • Adds/Changes to Applications,
Requests
Mgt. Infrastructure, Information, &
Business Processes
New/Changed
Populate
• Timeline/Interdependencies
R
N
Capabilities Delivered
A
N
Project A Project B Project C
C
E
Standard Service Request Standard Service Request Standard Service Request Standard Service Request
CLIENT Service CLIENT Service CLIENT Service CLIENT Service
(Service Provider (Service Provider (Service Provider (Service Provider
Requestor) WORK
Standard Service Response Requestor) WORK
Standard Service Response Requestor) Standard ServiceWORK
Response Requestor) Standard ServiceWORK
Response
Transforms
Object Object Object Object
Object Object Object Object
Build & Object
Object Build & Object
Object Build & Object
Object
Object
Object
Integrate Integrate Integrate
© EAdirections 2010. All Rights Reserved. 17
- 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. 18
- 19. Sample Organization Structure
• Combination EA/Governance org
structure
• Issue Resolution Groups are
chartered as needed by Architecture Executive
Steering
Council Committee
• Architecture Council members
Architecture
should be delegated authority by Council
CIO
Steering Committee
– Mix of IT and business resources Issue
EA
Resolution EPMO
Core Team
• Decisions get escalated to Steering Groups
Committee from Architecture
Council Domain
Team (s)
• Architecture Council ≠ EA Core
Team
– EA Core Team is represented on ARB
• EPMO takes on responsibility for EA
compliance checks within SDLC
© EAdirections 2010. All Rights Reserved. 19
- 20. EA vs. Subject Area Architect vs. Project Architect
Subject
Areas Projects
Facilitates
Tech
Arch
Provides
Project n
FEEDBACK
• Principles
• Standards
Arch
Enterprise Architecture
App
Provides • Design Patterns
Enterprise Strategy
• Integration Approach
• Models
• Strategic Context
...
• Best Practices FEEDBACK
Arch
• Research
Info
Project 2
Interpreted • Guidance
By • Leadership
Collaborates
Arch
Collaborates • Project Design
Bus
• Tech Selection
• Principles
• Service Design
Project 1
• Standards
• Integration Design
• Patterns
• Models
• Policy
• Models
• Services Needed
Consults / Advises / Reviews
FEEDBACK
© EAdirections 2010. All Rights Reserved. 20
- 21. Governance Best Practices - Approval
• Authority Flows Down EA Approval
– Must be granted, cannot be assumed Stages
– EA Team has none
Perform Domain
• Committees are not debate societies Analysis Team (s)
– Up/Down votes required
• Establish committee protocols
– Membership Requirements/Proxy Rules
– Notification/Comment/Action Periods Make EA
Recommendation Core Team
– Quorum/Voting/Table/Veto Rules
• Consensus, Majority (Simple, ¾, etc.)
– Meeting Frequency
• Areas of Responsibility Review & Architecture
– ESC vs. Architecture Council Deny or Review
Board
– Escalation Rules Approve
• Formal Sign-off Ceremony
• Publish Results
Executive
Escalation Steering
Committee
© EAdirections 2010. All Rights Reserved. 21
- 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. 22
- 23. Governance Best Practices - Compliance
• EA Team Informs/Advises Process Project Life
– PROACTIVE - Coaches/Consults Project Teams EARLY Cycle Gates
– Examines Projects for Compliance and identifies non-
compliance concerns Project
– No Authority to Grant Exceptions Proposal
• Informs EPMO of concerns/implications
• Projects request Exceptions/Variances from EPMO
– Should have the support of the EA Team
• Governance Body (EPMO?) Manages Exception HL
Process Design
– Integrates Compliance Process with SDLC(s) Review
– Presents findings to Architecture Council
– Council Escalates to ESC
– Directs Project as to Outcomes Detailed
• EA Team uses results of process to improve EA Design
Content Review
• Metrics kept by EPMO, analyzed by EA Core Team
Post-Project
© EAdirections 2010. All Rights Reserved. 23
- 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. 24
- 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. 25
- 27. About EAdirections
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
Tim Westbrock • 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
George S. Paras • Review and Improve Processes & Deliverables
• Contribute Relevant Examples & Research
• Provide Pragmatic, Objective, Unbiased and
Subscribe to our Prescriptive Feedback on Everything You Do
Newsletter:
http://eepurl.com/bQ4_
www.EAdirections.com
© EAdirections 2010. All Rights Reserved. 27