This action might not be possible to undo. Are you sure you want to continue?
Core Concepts, Best Practices, & Winning Approaches
Tim Westbrock & George Paras Managing Directors firstname.lastname@example.org email@example.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.
© 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.)
© EAdirections 2010. All Rights Reserved.
Question What do you think of when you hear the term “Enterprise Architecture?” © EAdirections 2010. 4 . All Rights Reserved.
but still must be integrated with other architecture disciplines Enterprise Strategy Enterprise Architecture Bus Arch Project 1 • Info Arch Project 2 App Arch . and longerterm focused..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. Tech Arch Project n © EAdirections 2010. All Rights Reserved. 5 .. more strategic.
6 .How to Get There? . All Rights Reserved.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 Information IT Infrastructure © EAdirections 2010.
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.By creating an Enterprise Architecture that … • • • • • • Expresses the impact of Business Strategy on the operations of your business. the applications that support your business. analysts. SMEs. 7 . developers and business sponsors © EAdirections 2010. All Rights Reserved. scenario planning. the information you need. 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. architects.
EA – Challenge of Overcoming the Inhibitors Business Strategy Inhibitors: – Complexity – Rate of Change – Misalignment of Operations from Business Strategy – Enterprise vs. Project Perspective – Limited Reuse/Reusability Current Objectives Processes How can we: – Reduce Complexity – Decrease Delivery Time – Align Business Strategy and Operations – Reconcile Enterprise and Project Perspectives and – Increase Reuse and Reusability? 8 Data & Information Systems & Infrastructure © EAdirections 2010. All Rights Reserved. .
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. All Rights Reserved. © EAdirections 2010.
Rationalizations. Consolidations. etc. 10 . Sol. All Rights Reserved. Tech.Driving Business Transformation Roadmaps & Lifecycles Business Vision & Strategy EA Creation Business Value Bus. Info. Transformation through Asset Portfolio Improvements. Future State Transformed Enterprise Bus. through New Business Projects Current State Time © EAdirections 2010. Info. Retirements. Transformation Tech. Sol.
Sol. through New Business Projects Transformation Current State Project Support Time © EAdirections 2010. Consolidations. Transformation Tech. Retirements. Rationalizations. All Rights Reserved. Strategic Direction Info.Driving Business Transformation Roadmaps & Lifecycles Business Vision & Strategy EA Creation Business Value Portfolio Transformation Bus. Info. Future State Transformed Enterprise Tech. Bus. etc. Sol. through Asset Portfolio Improvements. 11 .
contexts. 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. scope.Enterprise Architecture Development (HL) Enterprise Business Strategy Identify Business Vision Identify Strategic Capabilities Define Enterprise Principles Determine Future State Identify & Analyze Gaps Conduct Impact Analysis • Identify Strategic Capabilities – – Understand business strategy Decompose into more specific. 12 . Evolutionary Transformation Roadmap © EAdirections 2010. All Rights Reserved. audience and depth Develop Transformation Roadmap • • • Comparison to Current State Linkage to Project Portfolio Lifecycle.
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. 13 . All Rights Reserved.
14 . All Rights Reserved.What Senior Execs Don‟t Want to See © EAdirections 2010.
All Rights Reserved. 15 .Or This © EAdirections 2010.
2 Manufacturing 5. etc.1 Research & Development 5.3 Marketing Ops & Lead Generation 1. This can be very effective in understanding which applications support which functions as well as possible overlap.2 Advertising & Brand Management 2. 16 5. the Application Systems are mapped to the FH.4 Shipping 4.0 Marketing 2.2 Accounts Recievable 3.6 Returns 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.Mapping the Application Systems to the FH In the diagram below.0 Finance & Administration 1.0 Operations 5.3 Accounts Payable 4.3 Product Engineering 5.5 Customer Service 2.0 Engineering 4.1 Purchasing 4.6 Human Resources 5. The Application Systems use the same color coding in this map as in the previous slide.3 Inventory 4.1 Procurement 2. All Rights Reserved.1 Prospecting & Lead Management 3.2 Product Development & Design 2.3 Sales Proposals 4.1 Public Relations & Communications 1.0 Sales 3.7 Information Systems (IT) 5.5 Internal Audit 4. Company ABC's Information Systems LEGEND System function © EAdirections 2010.4 Sales Negotiations & Contracts 3.2 Qualification 5. etc.8 Legal . Company ABC High Level Functional Hierarchy 1.4 Financial Reporting 5.
Infrastructure. & Business Processes • Timeline/Interdependencies Represents Project A CLIENT (Service Requestor) Standard Service Request Service Provider WORK Standard Service Response Project B CLIENT (Service Requestor) Standard Service Request Service Provider WORK Standard Service Response Project C CLIENT (Service Requestor) Standard Service Request Service Provider Standard ServiceWORK Response CLIENT (Service Requestor) Standard Service Request Service Provider Standard ServiceWORK Response Transforms G O V E R N A N C E Object Object Object Object Object Object Build & Integrate Object Object Object Build & Integrate Object Object Object Build & Integrate Object Object Object Object © EAdirections 2010. Objectives & Targets Business Strategy Enterprise Architecture Input New/Changed Capabilities Required Models of the Current State Enterprise Tactical Project Requests Populate Models of the Future State Enterprise Existing Operations New/Changed Capabilities Delivered Project Portfolio Mgt. Tactical Goals. EA Roadmap • Project Requests • Adds/Changes to Applications. 17 . All Rights Reserved. Information.EA becomes the driver of EPfM Executive Management Annual.
Enterprise Governance • Enterprise Governance is a consistent and interdependent system of people. policy. All Rights Reserved. guidelines • Must define consequences and apply them © EAdirections 2010. and policy throughout the organization intended to ensure the intentions of the enterprise leadership are reflected in all decisions. process. participation improves understanding • Defines (approves) standards. • Must be delegated authority by senior leadership • Must understand strategy. 18 . EA and EPM.
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 Executive Steering Committee Architecture Council Issue Resolution Groups • CIO • • Decisions get escalated to Steering Committee from Architecture Council Architecture Council ≠ EA Core Team – EA Core Team is represented on ARB EA Core Team EPMO Domain Team (s) • EPMO takes on responsibility for EA compliance checks within SDLC © EAdirections 2010. All Rights Reserved.
Project 1 20 Project 2 .. Subject Area Architect vs. All Rights Reserved..EA vs. Project n Provides . Project Architect Subject Areas Projects Tech Arch Facilitates FEEDBACK Enterprise Architecture Enterprise Strategy Provides • • • • • Strategic Context Best Practices Research Guidance Leadership • • • • • Principles Standards Design Patterns Integration Approach Models App Arch Info Arch FEEDBACK Collaborates • • • • • Project Design Tech Selection Service Design Integration Design Models Interpreted By Collaborates • • • • • • Principles Standards Patterns Policy Models Services Needed Bus Arch Consults / Advises / Reviews FEEDBACK © EAdirections 2010.
Governance Best Practices . All Rights Reserved.) Make Recommendation EA Core Team – Meeting Frequency • Areas of Responsibility – ESC vs. 21 . etc. Majority (Simple. Architecture Council – Escalation Rules Review & Deny or Approve Architecture Review Board • • Formal Sign-off Ceremony Publish Results Escalation Executive Steering Committee © EAdirections 2010. ¾.Approval • Authority Flows Down – Must be granted. cannot be assumed – EA Team has none EA Approval Stages Perform Analysis Domain Team (s) • • 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.
All Rights Reserved.Project Linkage • EA must be defined from the Big-Picture perspective. 22 . EPM must own project review process and apply EA effectively • Adherence to EA must be mandated. deviation must be explained and approved © EAdirections 2010. 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. compliance expected. but realized at the project level • Over time.
Compliance • EA Team Informs/Advises Process – – – PROACTIVE . All Rights Reserved.Coaches/Consults Project Teams EARLY Examines Projects for Compliance and identifies noncompliance concerns No Authority to Grant Exceptions • Informs EPMO of concerns/implications Project Life Cycle Gates Project Proposal • • 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 HL Design Review • • EA Team uses results of process to improve EA Content Metrics kept by EPMO. analyzed by EA Core Team Detailed Design Review Post-Project © EAdirections 2010.Governance Best Practices . 23 .
Ross © EAdirections 2010.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. David C. as appropriate. Robertson and Jeanne W. and. 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. 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. All Rights Reserved. 24 .
Sequencing and prioritizing EA tasks 10. 25 . Addressing Culture. Politics & Leadership 5. EA Team Structure & Participants („E‟-level) 6. Approval of EA strategies and artifacts 7. „E‟ requirements of a federated business model 9. All Rights Reserved. Linking EA to overall Business Strategy 3. Proactive & holistic planning © EAdirections 2010. Analyzing and presenting an „Enterprise View‟ 2. Optimizing for the Enterprise not the Project 4.OVERVIEW 10 Requirements for Enterprise Adoption 1. Communicating „E‟ deliverables to leadership 8.
© EAdirections 2010. All Rights Reserved. 26 .
Unbiased and Prescriptive Feedback on Everything You Do George S. PMO. etc.com/bQ4_ www. People. . Teams Build Internal Support and Sponsorship Analyze and Drive Activity Plans Review and Improve Processes & Deliverables Contribute Relevant Examples & Research Provide Pragmatic. Objective.EAdirections. Assess Org Structures. Office of the CIO.com 27 © EAdirections 2010. EA Team. All Rights Reserved. Paras Subscribe to our Newsletter: http://eepurl.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 Operate a World-Class Office of the CIO Balance the Strategic with the Tactical Tim Westbrock How We Do It: • • • • • • • Continuous Mentoring of IT Leaders • CIO.
Enterprise Architecture. etc.4 Shipping 4. Company ABC's Information Systems LEGEND System function © EAdirections 2008.0 Finance & Administration 3.3 Accounts Payable 4. etc.6 Human Resources 5.2 Manufacturing 5. Cost Optimization.7 Information Systems (IT) 5.6 Returns 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.2 Accounts Recievable 3. IT Governance.2 Advertising & Brand Management 2.1 Research & Development 5.1 Prospecting & Lead Management Providing „Jump Start‟ Materials & Other Research – – – – Provide „quick & dirty‟ enterprise-wide templates for demonstrating Business/IT Alignment .3 Product Engineering 5. Application Portfolio. strategy. Business Transformation. etc.0 Operations 5. etc. roles and responsibilities Establish communications strategy to enroll support Build a culture of collaboration and effectiveness focused on „enterprise outcomes‟ Mapping the Application Systems to the FH In the diagram below. 5.3 Sales Proposals 4. Enterprise Architecture.3 Marketing Ops & Lead Generation 1. Technical Fit‟. etc. Templates for demonstrating Business/IT alignment Tools for „Business Fit‟ vs.8 Legal .0 Engineering 3. This can be very effective in understanding which applications support which functions as well as possible overlap.3 Inventory 4. All Rights Reserved. Perform on-going research 28 2.5 Internal Audit 4.1 Procurement 2. Business/IT Alignment. Project Management.2 Product Development & Design 4.0 Marketing 1.1 Public Relations & Communications 1.4 Sales Negotiations & Contracts 3. The Application Systems use the same color coding in this map as in the previous slide. the Application Systems are mapped to the FH.2 Qualification 5.5 Customer Service 2.Our Approach – Build Effective EA Organizations Ongoing Mentoring – – – – – – – – Make our clients more effective IT Strategy. Company ABC High Level Functional Hierarchy 1. 13 © EAdirections 2010.4 Financial Reporting 5.1 Purchasing 4. All Rights Reserved.0 Sales 2. Individuals or Teams Retainer based 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 Assessing Activities & Review Deliverables Building the Extended Team – – – Refine mission.
All Rights Reserved.APPENDIX Additional Slides © EAdirections 2010. 29 .
ETA. 30 . Data Modeling © EAdirections 2010. All Rights Reserved. Application Development.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. ESA • Domain Level Principles – Network.
or do NOT. All Rights Reserved. and why does it support the requirements? this mean to the organization? What happens if you do. best practices: What‟s the difference? • A principle is: – – – – Title Short description Rationale/justification Implications “Title: CA Principle” • Description: A bit more detail • Evaluating principles – Treat as a set. 31 . not just as individual principles – Resolving conflicts • Rationale: Why is this important. do this? • Implications: What does © EAdirections 2010.What Does a Principle Look Like? • Principles vs.
Example Principles • • • • • EA must be primarily driven to increase business value. All modules and processes will be designed as loosely coupled and highly granular using a component based development process. while enabling the enterprise to change more and more quickly and reducing complexity wherever possible. by outside expertise and resources to develop and support the competency of internal resources dedicated to EA. supplemented if needed. Information Is Managed and Leveraged as an Enterprise Asset Evolve holistic enterprise architecture that models the business operating model. All Rights Reserved. Design applications for platform independence. • • • © EAdirections 2010. solutions portfolio and technology infrastructure. 32 . Enterprise architecture development must be an insourced effort. Information will be location transparent. information environment. EA Governance is part of the Overall Enterprise Governance approach.
33 . 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 To support the “single view of the customer” direction.Full Principle Example • • “All solutions must conform to common. standard interoperability framework Compromises will be needed from line-of-business development units to adopt enterprise solutions rather than custom solutions In some instances. all solutions must be implemented on a single. and to permit the agility necessary to redesign business processes. 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 Rationale – • Implications – – – – © EAdirections 2010. All Rights Reserved. to freely exchange information.
34 . All Rights Reserved.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.
EA Future State Development Context Enterprise Intelligence Enterprise Business Strategy Enterprise Solutions Architecture Enterprise Technology Architecture Enterprise Information Architecture Enterprise Business Architecture Value Network Analysis Information Value Chain Analysis Context Diagrams EA Focus “The Enterprise Solutions Architecture Big Picture” Enterprise Technology Architecture Enterprise Information Architecture Enterprise Business Architecture Required Capabilities (CRV) Enterprise Principles (CA) EA Focus Scenario Level Architecture Enterprise Solutions Enterprise Technology Architecture Enterprise Information Architecture Business Scenario Models Business Event Analysis Function/ Process Decomposition IT Standards Swimlane Diagrams EA/Project Enterprise Business Architecture Focus CapabilitiesSolutions Architecture Level Enterprise Enterprise Technology Architecture Enterprise Information Architecture Integration Models Service Project Function Focus Models Enterprise Business Architecture Service Catalog Use Cases Services Level Solutions Portfolio © EAdirections 2010. 35 . All Rights Reserved.
etc. BPEL are continuing to gain momentum. metadata from top to bottom • Use the HL Strategic Context Models to direct/prioritize the areas in which to invest more detailed modeling effort © EAdirections 2010. 36 . terminology. 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. All Rights Reserved.Modeling Summary • While the science (standard notation. approaches. naming conventions. there is more art the higher the level you are modeling at – Standards like UML. BPMN.) is growing. usecases. standards.