EAdirections Fundamental Concepts 6 15 2010

971 views
838 views

Published on

EAdirections Managing Directors George Paras and Tim Westbrock present some of the fundamental concepts of Enterprise Architecture.

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
971
On SlideShare
0
From Embeds
0
Number of Embeds
61
Actions
Shares
0
Downloads
46
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

EAdirections Fundamental Concepts 6 15 2010

  1. 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. 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. 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. 4. Question What do you think of when you hear the term “Enterprise Architecture?” © EAdirections 2010. All Rights Reserved. 4
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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
  14. 14. What Senior Execs Don‟t Want to See © EAdirections 2010. All Rights Reserved. 14
  15. 15. Or This © EAdirections 2010. All Rights Reserved. 15
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  26. 26. © EAdirections 2010. All Rights Reserved. 26
  27. 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

×