Your SlideShare is downloading. ×
Creating An EA Governance Organization
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Creating An EA Governance Organization

37,846
views

Published on

EA governance is the practice by which enterprise architectures are managed and controlled at an enterprise-wide level. Governance processes should be tailored to the particular environment of the …

EA governance is the practice by which enterprise architectures are managed and controlled at an enterprise-wide level. Governance processes should be tailored to the particular environment of the organization, as well as the architectural goals and objectives of that organization, and should never hinder time to market. A centralized governance body can facilitate and drive key functional and architectural decisions across the primary internal stakeholders to ensure that the enterprise architecture addresses customers’ needs.

The presenter has implemented numerous EA governance organizations. As part of a major pharmaceutical distribution company’s corporate-wide SOA adoption program, he adapted the basic governance frameworks such as TOGAF to the organization and the objectives of the SOA adoption program. This session will examine the processes that were used to create an EA Governance organization at a major energy company and lessons learned at this company, as well as at other organizations.

Published in: Technology, Business

0 Comments
13 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
37,846
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
13
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Hello, My name is Chip Wilson. I’m an Enterprise Architect for EMC Consulting. <CLICK> Many of the concepts presented here today come from my book, Transparent IT.
  • Transcript

    • 1. Creating an EA Governance Organization to Manage an SOA Adoption Program Chip Wilson Enterprise Architect EMC Chip Wilson
    • 2. Agenda
      • Context for this Presentation
      • SOA Adoption Approaches
      • SOA Governance
      • Real World Example Rollout of SOA Governance
      • Governance Metrics
      • Governance Roles
    • 3. Four Domains of Enterprise Architecture
    • 4. What is SOA?
      • Service Oriented Architecture is defined by a set of practices and technologies for building IT systems out of parts.
      • Building systems out of parts is a more general concept than SOA, and can be applied to many industries.
      • The two key prerequisites that enable the construction of systems from parts are:
        • A catalog of parts that defines what parts are available for use and their characteristics and interfaces
        • Tools that can be used to assemble parts into systems
    • 5. Adopting an SOA
      • Beginning of a journey for the entire organization
      • Approach may vary
      • Goal – build an agile, loosely coupled suite of business services
      • Execution – process of adopting practices and tools
      • Approaches can be divided into two categories
    • 6. SOA Adoption Two Approaches
    • 7. Getting There: Two Approaches
      • Top Down
        • Executive-driven
        • Initiative-based
        • Inherently inclusive and evolutionary
      • Bottom Up
        • IT-driven
        • Little need for executive “buy-in”
        • Addresses immediate need for point to point integration
    • 8. Bottom-Up Data Replication Tightly Coupled Customer Information Customer Information Customer Information Credit Rules
      • Opportunistic use of web services for new interfaces
        • Existing apps wrapped to make them first-class citizens of the SOA
        • Existing interfaces migrate to SOA
        • New integration projects take SOA approach
      Point to Point Integration Credit Check Fraud Detection Interest Calculation Issue Card Customer Information Credit Check Fraud Detection Interest Calculation Issue Card
    • 9. Benefits of Bottom-Up New Functionality Increasing percentage of systems will be delivered on the new architecture Legacy Functionality Sunset Functionality
      • Little or no executive buy-in required
      • Organization gains experience
      • Solution delivers iterative, incremental value
      • Reuse of existing assets yields higher ROI
      Iterative Development Cycles
    • 10. Shortcomings of Bottom-Up
      • Design of interface contracts often an afterthought
      • Underlying schemas often developed in isolation
        • limited reuse
        • duplicated effort
      • Integration often “hard-coded” in point-to-point manner
      • Web services technology used inappropriately
      • Failures attributed to technology
      • Some services not used, wasting dev resources
    • 11. Shortcomings of Bottom-Up Increasing value of services No enterprise-wide approach to Development Deployment Management Leads management to begin top-down effort
    • 12. Top-Down
      • Management clearly sets SOA as strategic direction and creates initiatives to implement
        • Communicate decision throughout IT
        • Implement in phases
        • Inclusive and Evolutionary
      SOA
    • 13. Benefits of Top-Down
      • Executive buy-in and prioritization allow organization to focus on delivering the most critical functionality early
      • Forces companies to think about and address enterprise architecture
      • Overcomes the shortcomings of bottom-up
      SOA
    • 14. Pitfalls of Top-Down
      • Getting stuck in “analysis paralysis”
      • Falling back into waterfall approach to development
      • Falling victim to political in-fighting or cultural impediments
      SOA
    • 15. EA Governance Top Down SOA Adoption
    • 16. Requirements for Success
      • Executive Sponsorship
      • Communication between Business and IT
      • Business Focused IT
    • 17. Goals of SOA Governance
      • Build an integrated platform and ensure best practices are in place for enabling an integration architecture, including:
        • Integration with existing core systems (ERP, CRM, etc.)
        • Integration of applications with each other
        • Assimilation of new applications
      • Reduce development times, enhance software quality, and ensure a successful integration of applications
      • Provide centralized integration governance
      • Lead integration working groups and teams
      • Establish, document, and evangelize best practices
      • Manage continued change to existing service definitions
      • Recommend policies, procedures, and tools for the development, test, and deployment of services
    • 18. Integration Competency Center ICC ICC ICC ICC ICC Development Group C Development Group B Development Group A ICC ICC ICC
    • 19. Role of the ICC Monitor COTS purchases Evaluate app portfolio Select monitoring and mgmt platform Integration Competency Center Ongoing consulting Select infrastructure standards Define best practices Identify industry standards Drive standards adoption
    • 20. Executive Sponsorship
      • An SOA adoption program needs appropriate sponsorship
      • Requires a strong vision grounded in SOA best practices
      • Must be led from the top down
      • Create a common vocabulary between business and IT
      • Capability Modeling creates tremendous synergies – aligns the entire Enterprise Architecture stack from top to bottom
      SOA
    • 21. Communication Between Business and IT
      • IT must understand the strategic business direction
      • An ongoing dialogue on business process will:
        • Provide a business context for Enterprise Architecture
        • Give the business community a suite of tools to automate, improve, or even redesign business processes
      • Business processes:
        • Are an important part of the alignment of IT and business
        • Should not be the basis for a common understanding
    • 22. Ensuring IT is Business Focused
      • The technical organization needs to:
        • Have a solid grounding in the company’s history
        • Understand why the business operates the way it does
        • Identify opportunities for greater efficiency
      • Technical community must be willing and able to keep communication channels open to:
        • Keep abreast of the competitive landscape and the operation of the business
        • Identify opportunities to leverage technology to further business strategy
    • 23. Creating an EA Governance Organization A Real World Example
    • 24. Phased Rollout
      • Phase I: Assessment, Planning and Strategy
      • Phase II: Pragmatic Roll-Out
      • Phase III: Execution
    • 25. Phase I: Portfolio Inventory and Analysis
      • Gather project data on active and proposed projects including:
        • schedules
        • cost estimates
        • budgets
        • dependencies
        • strategic initiatives
        • expected benefits (e.g., ROI)
        • risks
        • resources assigned
      • Prioritize and rank all projects based on
        • alignment with strategic direction
        • ROI
        • utility
      • Maximize the value to the organization given budget and resource constraints
    • 26. Phase I: Current State Integration Assessment
      • Assess and understand the architectural attributes of the top ranked applications, along with any existing, planned, or needed interfaces between them
      • Gather information and formulate best practices and a roadmap for migrating these applications from the current state to the desired future state.
      • Key activities include:
        • Process
          • Take inventory of all other integration efforts occurring to assess the cost/benefit of applying SOA best practices to those projects
          • Work with the Portfolio Manager to determine the priority of integration projects
        • Architecture
          • Inventory the existing systems and their respective components to develop an architectural technology roadmap
          • Understand and document the architectural and technical issues that all integration efforts should know
    • 27. Phase II: Governance and Optimizing the Portfolio
      • Some projects will be shut down and others initiated based on the results of the integration assessment, strategic alignment, and ROI ranking
      • Resources need to be re-assigned based on skills and timing
      • Detailed schedules are created for new projects
      • Existing projects that are impacted by the new integration direction are re-scheduled
      • The Portfolio Manager must now define the ongoing governance process for accepting, prioritizing, and ranking new projects against the current portfolio
      • Standard meetings are scheduled and ROI models are defined and agreed upon
    • 28. Phase II: Collaborative Governance
      • Members of the ICC advise and work as integrated members of the project teams
    • 29.
      • Industry best practices stress the importance of liaising with project teams to communicate the goals of the ICC and to ensure that the needs of the project are reflected in the integration plan
      • By keeping this relationship collaborative, the ICC and project teams can work together to efficiently apply the best practices brought to the table by the ICC while maximizing the capabilities of each project within the SOA
      • At the same time that members of the ICC are working with specific projects, they must maintain a community of their own for sharing knowledge, information schemas, and even code and development/test techniques across the organization
      • Infrastructure and processes for community knowledge sharing should be put in place
      Phase II: Collaborative Governance
    • 30. Phase II: Architectural Governance
      • Early projects explore the use of SOA compliant technologies and the creation of information and interface schemas
      • The ICC is part of the projects to:
        • Gain experience regarding the design and implementation of the company’s first services
        • Assist in the creation of one or more consistent information schemas for use across all service interfaces, facilitating the efficient integration of systems
        • Capture and document best practices to streamline future development of SOA compliant products and service wrappers
    • 31. Phase II: Architectural Governance
      • Service definition
        • Lead integration and service definition meetings between project teams and other stakeholders
        • Communicate service definitions to all parties concerned to ensure consistency of use and coordinate feedback
      • Process (SDLC)
        • Promote an iterative software development lifecycle (SDLC) for integration projects
        • Manage change to service definitions as new requirements are brought into scope
        • Recommend policies and procedures for development, testing, and deployment
      • Education
        • Document best practices for the development of services
        • Develop materials and content to evangelize SOA and ICC guidelines
        • Plan and deliver brief seminars and presentations to evangelize SOA, the work of the ICC, and incorporate success cases
    • 32. Phase III: Integrated Governance
      • The ICC community shares service definitions, best practices, architecture, and other knowledge between members
    • 33. Phase III: Portfolio Tracking and Re-planning
      • Tracking mechanisms ensure the governance process is working correctly and resources are assigned appropriately
      • Metrics need to be defined and reviewed regularly
      • Determine corrective actions, re-rank, and re-prioritize projects
      • Define metrics and facilitate improvements
      • Project, program and portfolio review happen on a regular basis
      • The portfolio is not static -- projects are re-ranked and prioritized regularly
    • 34. Phase III: ICC Activities and Responsibilities
      • Consulting
        • Act as consultants to project teams, assisting in the proper formation of information models and service descriptions, and convey techniques for efficient development, test, and deployment of the new services
        • Coordinate with other teams to maintain the integrity of the service definitions shared between projects
      • Education
        • Actively share knowledge within the ICC to improve collaboration with the project teams
        • Evangelize the practices and benefits experience to all project groups
        • Host briefings on the architecture, tools, and techniques for service development, test, and deployment
      • Community and Governance
        • Interface with the relevant industry governance bodies to keep abreast of the latest technology developments, standards, and recommendations that affect the company
        • Establish community knowledge sharing processes and infrastructure
        • Host intra-ICC discussions and reviews to discover and promote best practices and other knowledge within the team
    • 35. EA Governance Metrics and Roles
    • 36. Metrics: Operational Effectiveness (is EA doing anything?)
      • Number of
        • standards
        • reference architectures
      • Compliance - Percent of projects
        • using/reusing standards
        • following reference architectures
      • Compliance efficiency –
        • number of projects with signoff on first try divided by total number of projects
        • average number of tries to get signoff
      • Oversight efficiency – average effort and duration required to get project signoff
      • Exception/deferral frequency - number of architecture exceptions and deferrals granted per business domain
    • 37. Metrics: Risk Management (is EA managing risk?)
      • Architecture risk count - An architecture risk is a technical characteristic of a solution that has a potential negative impact on that solution’s chances of success
        • vendor risk
        • new technology risk
        • security risk
        • supportability risk
      • Severe architecture risk ratio - Calculate ratio of high probability and severe risks to total architectural risks per project
      • Technology lifecycle risk - Calculate percentage of lifecycle risks attributed to each piece of the technology lifecycle (e.g. emerging technology, mature outside your company, obsolete technology)
    • 38. Metrics: IT/Business Alignment (are we building the right things?)
      • Spend per business goal - Cost of all IT projects associated with delivery of a business goal
      • Number of projects involved with each business goal
      • Change agenda - Identifies the traceability between
        • business strategy
        • business objectives
        • strategic technology investments
    • 39. Metrics: Value Creation (are we delivering business value?)
      • Blueprint value measurement - Metric that provides quantitative view of advancement towards a blueprint
        • Metric is created by tracing back from
          • initiative (technology project)
          • business capability
          • objective
          • corresponding performance indicator (yearly target)
      • Architecture coverage - Comparison of the top 10 architecturally complex projects versus the top 10 high business priority projects
      • Percent of innovation ideas converted into production - Captures the success rate of ideas explored by architecture
    • 40. Portfolio Manager
      • Responsible for aligning the business strategy with the project prioritization and selection process
      • Key activities include:
        • Inventory the projects within the portfolio
        • Define the governance process
        • Define the membership of the portfolio review board
        • Determine the project assessment and selection processes
        • Create a portfolio tracking process
        • Implement a process improvement effort using organizational change management principles
    • 41. Enterprise Architect
      • Responsible for setting the architectural direction and designing the key interfaces between systems
      • Ensure proper implementation and alignment with the architectural direction
      • Key activities include:
        • Work with developers and architects to determine the current state of the projects and systems
        • Work with key individuals to determine the future state that aligns with the business strategy, including a roadmap for transitioning from the current state to the future state
        • Oversee the development, maintenance, and dissemination of libraries and code templates for use in various projects
        • Define and communicate the architectural direction within the company
        • Consult with the product teams to ensure adherence to good design principles that alight with the architectural direction
    • 42. Solution Architect
      • Work on development teams to implement the solutions as defined by the Enterprise Architect
      • Key activities include:
        • Oversee application development, technical design, and architectural direction
        • Ensure all developers are using good design principles and adhering to organizational coding standards
        • Perform code reviews
        • Provide architectural design diagrams and documentation for projects
        • Work with the Project Manager to ensure on-time delivery and exceptional quality
    • 43. Creating an EA Governance Organization Chip Wilson Enterprise Architect EMC Chip Wilson

    ×