Accelerating Your SOA Implementation

1,688 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,688
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • This slide describes the fact that the SOAMM is in fact a roadmap with different states that map to the different levels. This slide also shows an example of a potential mapping of the services that are created to the organization dimension at the different levels. In this particular case, we are taking the example of an enterprise that would be comprised of divisions with the IT organization structure mapping very closely the lines of business. A division is a business unit that is comprised of other business units. Business units would in turn run projects. In this case in SOA ad Hoc, you may have some services built at the project level. In SOA defined, you would at least have a couple of SOA based projects under way with the vision of shared services across a single division. In SOA repeatable a single division could have implemented successfully an SOA strategy with the vision to start offering services to other divisions. From this graph you can see the importance of repeatability to define a firm enterprise wide SOA strategy rollout plan. You would usually define the roll out plan in SOA defined but this plan would not be stabilized until you have a certain level of repeatability. From an enterprise wide standpoint, building applications, or services crossing organization boundaries is always more difficult because of the inherent risk that come with the Organization crossing (This risk comes from Politics, data and business process ownership etc). So to reach the repeatability level from an enterprise standpoint one has to mitigate that risk, I.e offer services that go across organizations. To make a parenthesis, reuse from one project to another already has its own challenges. Reuse from a division to another is even more difficult. Every time you cross an organization (whether it is project, Business unit, Division or company) boundary, leveraging assets to maximize reuse and eliminate duplicates presents a challenge. The more decoupled the organizations are from a domain point of view the less likely we are to find duplicates. However the more decoupled the organizations are from a reporting (under a different umbrella) standpoint and the harder it is to come to a consolidation of assets. It is often the case for customer related assets and horizontal processes. Among other CRM processes (ex: customer update) go across different lines of business.  
  • Intro of GCR Survey Survey respondents include over 150 SOA decision makers and influencers across N.America and Europe. Survey conducted by GCR research, independent 3rd party firm, sponsored by BEA. To qualify respondents need to be a) personally responsible for SOA and b) companies must be over $1B in annual rev and must have started SOA projects. These are preliminary results. Note: There is a statistically significant difference between the North American and EMEA response to deployment status. 45% of EMEA indicated they were enterprise-wide vs. 19% in NA.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • Measuring metrics is not the problem as 62% of companies have agreed on SOA metrics and are measuring today. But are they the right metrics? The heavy reliance on measuring IT costs savings could be causing issues, as far greater benefits can be realized from top-line business benefits/agility. The top 5 blue bars are all financial inhibitors! What people are looking for is POSITIVE ROI! Difficult because business metrics are more difficult to quantify (for IT) and seem to be expected over a longer period of time.
  • Note: There is a statistically significant difference between the North American and EMEA response to IT Cost Savings. 21% of NA reported IT Cost Savings as primary driver for SOA vision while 40% of EMEA respondents did. 10% of NA respondents named new products or services compared to 1% in EMEA. Europe and N.America differed significantly; Europe indicates more focus on IT optimization, whereas N.America on business transformation. In reality, most companies will have a both metrics included in a business plan.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • Determine current state by Interview and review architecture collateral (logical, physical, network, data, and others; non-functional requirements, standards, principles, policies and guidelines) Architecture Review document
  • Determine current state by Interview and review architecture collateral (logical, physical, network, data, and others; non-functional requirements, standards, principles, policies and guidelines) Architecture Review document
  • SOA Guiding Principles The hallmark of an effective set of SOA principals is a clear trail of evidence from the business to the SOA principals. High level principals and statements about how SOA is used in the business. Clarifies enterprise objectives for SOA – this will assist in establishing the direction for all other decisions. If principals are not clear it is unlikely that the other decisions will coalesce meaningfully. Companies should not allow SOA principles to be set by IT alone because this will assume significant risk. (Highlight SOA aligns business and IT). This leads to technically sounds principles but not a SOA business enabled architecture. The risk of failure is high as business units will not accept that they have as much to do with getting value from systems as do the IT departments. What principles and guidelines are necessary to optimize the alignment of business and IT? SOA Architecture Architecture, Standards and Guidelines that feed into SOA Roadmap Translate SOA principles into requirements for integration and standardization and then delineate a SOA roadmap for providing needed capabilities (policies, standards and guidelines) IT monarchies choose the SOA architecture. An IT only team often with IT representatives from individual business units – is responsible for designing and managing the architecture, which it then communicates to the entire enterprises SOA Services Infrastructure Layer Shared Business & Common Services SOA Shared Services requires business, technology and political negotiation. This negotiation must be relatively quick and a duopoly is the best approach for such a decision. Senior managers share evolving strategies with IT executives, who can identify deficiencies in existing capabilities and propose how the firm might leverage the technology it has in place. The process makes IT people more business savvy and business people more IT savvy. (SOA Business and IT aligned) SOA Investment SOA investment should not be wholly in the hands of the IT professionals because IT investment decisions involve business tradeoffs. In a business monarchy, IT projects compete for funds with other organizational needs. The competition for funding facilitates an integrated view of the enterprises key assets (physical, human, relationship) and is aided by an enterprise investment committee that looks at all major investments. SOA Organization Structure What organization structures are required to supports SOA governance processes What representation is required What frequency do decisions need to be made SOA Governance Process What processes are needed to support the decision framework Various numbers of processes are required SOA Communication & Tools Communicate and educate continuously regarding the benefits of SOA to drive adoption Continual SOA Process education and SOA technology training SOA Business Service Portfolios Larger organizations should utilize service portfolios Enables a holistic categorization, evaluation, prioritization, investment and management of SOA assets. Eliminate redundancy in duplicate applications and business services IT Governance Complement existing process and structures
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • RA must be authoritative – otherwise, it is merely another architecture organization exercise. It serves to communicate through the organization what SOA is, how it is structured logically and functionally and what the expectations and responsibilities of enterprise constituents are as they adopt SOA. Accordingly, it is a compliance tool, because delivered IT assets (services) can be measured against the RA for correctness and conformity. The RA embodies principles and benefits for SOA that have clear linkage to documented business and IT objectives. Definition of service categories should describe the responsibilities of layers that support each category and the relationships among layers. Requirements for each category should include functional and non-functional requirements, which may be supplied for all categories by infrastructure. Need to be able to show the changes introduced by SOA and the way that they relate to the way that assets for the organization as a whole are organized architecturally. This includes things like information, integration and security.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • The hallmark of an effective set of SOA principals is a clear trail of evidence from the business to the SOA principals. High level principals and statements about how SOA is used in the business. Clarifies enterprise objectives for SOA – this will assist in establishing the direction for all other decisions. If principals are not clear it is unlikely that the other decisions will coalesce meaningfully. Companies should not allow SOA principles to be set by IT alone because this will assume significant risk. (Highlight SOA aligns business and IT). This leads to technically sounds principles but not a SOA business enabled architecture. The risk of failure is high as business units will not accept that they have as much to do with getting value from systems as do the IT departments. Why are you considering SOA ? How will SOA effect the business Have you documented the benefits you expect to achieve ? definition statement, each principle should have associated rationale and implications statements, both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made.
  • Note: There is a statistically significant difference between the North American and EMEA response to the number of projects upon which the justification is based. 51% of NA said more than 3 while 13% in EMEA said the same. This is important because it’s looking at roadmap and portfolio management. Longer term thinking is better.
  • Script: BEA’s unique approach to SOA follows a six domain model that addresses everything from core architectural design to an organizational governance model.
  • The domains and the challenges they address include:           Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy.           Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level.           Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure.           Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution.           Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
  • Accelerating Your SOA Implementation

    1. 1. Accelerating Your SOA Implementation Bret Dixon SVP, Professional Services BEA Systems November 7 th , 2006
    2. 2. Agenda <ul><li>The Market Today </li></ul><ul><li>Moving To The Next Stage of SOA Implementation </li></ul><ul><li>Summary </li></ul>
    3. 3. Agenda <ul><li>The Market Today </li></ul><ul><li>Moving To The Next Stage of SOA Implementation </li></ul><ul><li>Summary </li></ul>
    4. 4. The Debate Is Over: A New Approach For Delivering IT Applications Has Been Embraced Presentation Services Shared Business Services Information and Access Services Services Management Service Bus Common Services Service Infrastructure Layer Sales B2E Engineering B2C Service Partners Customers Composite Applications Enterprise Information Systems Data and Middleware Custom Applications Third Party Products (Erp, CRM, etc.) Databases MiddleWare Interactions (TUXEDO, MQ Series,ect.) “ Role-based” Composite Applications… … connect to business services, built and managed with an integrated suite on open standards, with supporting infrastructure… … using content from “Vanilla” ERP and legacy applications Non-Functional Requirements Standards Development Tools Configuration Management System Management Network Management Provisioning Business Activity Monitoring Directories Patterns
    5. 5. The Stakes Couldn’t Be Higher In Enterprise Software “ It seems that if SOA really takes over, the software that links applications together , rather than the applications themselves, will become the most important strategic decision that CIOs make.” - Christopher Koch Executive Editor, CIO Magazine February 2006
    6. 6. SOA Starting Points Process Projects IT-Led Projects Mega Projects Business Sponsorship High Low Low High SOA Complexity Business-Led Projects
    7. 7. The Next Big SOA Challenge Moving Past the Division No SOA SOA Ad Hoc SOA Defined SOA Repeatable SOA Managed SOA Optimized Exploring SOA Maturity Level Expanding Exploiting No implementations Cross divisional services Enterprise level services Division level services Project level services
    8. 8. Companies Are Moving Forward Now With SOA Enterprise-wide SOA up 200% Department-wide SOA up 300%, Q: What Stage Is Your Company Currently In With Respect to SOA? Don't Know Not Planning to Deploy Evaluation Pilot Projects Department-wide SOA Enterprise-wide SOA 32% 21% 20% 13% 4% 8% 12% 7% 25% 28% 12% 16% 2005 2006
    9. 9. BEA SOA Cost Benefits Deployment Status Indicate the status of SOA deployment in your organization. US High number of Enterprise-wide deployments Europe
    10. 10. Agenda <ul><li>The Market Today </li></ul><ul><li>Moving To The Next Stage of SOA Implementation </li></ul><ul><li>Summary </li></ul>
    11. 11. Plan for SOA in Multiple Dimensions The BEA SOA Domain Model Organization & Governance Costs & Benefits Business Strategy and Process Architecture Building Blocks Projects and Applications Organization & Governance ©
    12. 12. Moving To The Next SOA Stage Six Key Initiatives Organization & Governance Define & Capture Your Benefits Connect the Business to the Capability Establish An Enterprise Architecture Make Service Engineering a Discipline Build A Stream of Connected Projects Align The Organization for Shareholder Value Business Architecture Building Blocks Organization Benefits Projects
    13. 13. Moving To The Next SOA Stage 3 Types Of Leadership Costs & Benefits Organization & Governance Define & Capture Your Benefits Align The Organization for Shareholder Value Requires Operational Leadership Business Strategy & Process Projects & Applications Build A Stream of Connected Projects Connect the Business to the Capability Requires Developmental Leadership Establish An Enterprise Architecture Make Service Engineering a Discipline Requires Architectural Leadership
    14. 14. Moving To The Next SOA Stage Meeting The Operational Challenges <ul><li>How do I justify the costs? </li></ul><ul><li>How do we make SOA O&G work between Business Units, or between countries? </li></ul>Costs & Benefits Organization & Governance Define & Capture Your Benefits Align The Organization for Shareholder Value
    15. 15. BEA SOA Cost Benefits SOA Barriers Which of the following are roadblocks to justifying SOA in your organization? Is SOA justification currently impeding the start or extension of SOA projects? Nearly 40% of SOA projects are impeded due to lack of SOA confidence in big payoff
    16. 16. Define & Capture Your Benefits: Three Levels of Justification <ul><li>SOA as a matter of fundamental business technology strategy </li></ul><ul><li>SOA as core requirement for business agility </li></ul><ul><li>SOA ROI calculated for specific projects </li></ul><ul><li>SOA specific costs quantified and offset by benefits on specific projects </li></ul>Strategic Soft dollar Hard dollar Mix <ul><li>SOA costs and benefits categories identified </li></ul><ul><li>SOA benefits/root causes articulated, savings range indicated </li></ul>Source: Forrester SOA Investment Strategies 2006
    17. 17. BEA SOA Cost Benefits SOA Reuse Expectations What level of reuse do you expect? 75% of companies expect 11- 40% reuse
    18. 18. BEA SOA Cost Benefits SOA Vision What is the primary driver for the SOA vision in your organization? In which areas do you expect to see impact on your business as a result of deployment?
    19. 19. EMEA Financial Services Customer Complex Interdependency Between Costs & Benefits £4.1m Benefit Smooth £200k Benefit Equator NWW Atlas2 Scarlett £325k Benefit DMR £70k Benefit Strategic Vestings £500k Benefit Service Differentiation £250k Benefit Total Investment = £6.2m Total Benefits = £9.7m E-Enablement <ul><li>4 Front Benefits </li></ul><ul><li>Reduction in avg time to handle a call </li></ul><ul><li>Ease in training, outsource-ability </li></ul><ul><li>Increased client satisfaction </li></ul><ul><li>E-Enablement Benefits </li></ul><ul><li>Extended services to Financial Planners </li></ul><ul><li>Extended services to Business Partners </li></ul><ul><li>Reduced IT project costs by 75% </li></ul>£5.1m Benefit MEP Framework Weblogic OCDB SPL 4Front
    20. 20. Moving To The Next SOA Stage Meeting The Operational Challenges <ul><li>How do I justify the costs? </li></ul><ul><li>How do we make SOA O&G work between Business Units, or between countries? </li></ul>Costs & Benefits Organization & Governance Define & Capture Your Benefits Align The Organization for Shareholder Value
    21. 21. Organization and Governance Matters <ul><li>“ In 2006, lack of working governance mechanisms in medium to large (more than 50 services) post-pilot SOA projects will be the most common reason for project failure (0.8 probability) ” </li></ul><ul><li>Paolo Malinverno, Gartner Group </li></ul>
    22. 22. Organization and Governance: Rationalization There is no recognized approach to rationalization of shared components within and across portfolios Organization & Governance <ul><li>Each Portfolio/LOB has its own technology assets that are not used across the enterprise </li></ul><ul><li>Within portfolios there are multiple instances of redundant functionality </li></ul>Business Strategy & Process Architecture Costs & Benefits Projects & Applications Building Blocks Projects & Applications Business Strategy & Process Architecture Costs & Benefits Building Blocks Organization & Governance
    23. 23. Organization and Governance: Funding The funding process IS the governance model Organization & Governance Business Strategy & Process Architecture Costs & Benefits Projects & Applications Building Blocks Projects & Applications Business Strategy & Process Architecture Costs & Benefits Building Blocks Organization & Governance <ul><li>Businesses have their own line of credit to choose and implement ad-hoc solutions </li></ul><ul><li>Most often ad-hoc solution selection does not align well with the future strategy </li></ul>
    24. 24. Enterprise Implementation Requires an Enterprise SOA Governance Framework
    25. 25. Moving To The Next SOA Stage Meeting The Architectural Challenges <ul><li>How do we define an Enterprise SOA Reference Architecture, and what does it contain? </li></ul><ul><li>How do we achieve consistent service engineering? </li></ul><ul><li>What service infrastructure do we need, when? </li></ul>Architecture Building Blocks Establish An Enterprise Architecture Make Service Engineering An Enterprise Discipline
    26. 26. Establish Your Enterprise Architecture <ul><li>Business Context </li></ul><ul><ul><li>Business Drivers </li></ul></ul><ul><ul><li>IT Drivers </li></ul></ul><ul><ul><li>Prioritized SOA Benefits </li></ul></ul><ul><li>Reference Architecture </li></ul><ul><ul><li>Architecture Principles </li></ul></ul><ul><ul><li>Definition of a “service” </li></ul></ul><ul><ul><li>Architectural Views </li></ul></ul><ul><ul><ul><li>Logical view </li></ul></ul></ul><ul><ul><ul><li>Implementation View </li></ul></ul></ul><ul><ul><ul><li>Process View </li></ul></ul></ul><ul><ul><ul><li>Deployment View </li></ul></ul></ul><ul><ul><li>Service Architecture </li></ul></ul><ul><ul><ul><li>Infrastructure Services </li></ul></ul></ul><ul><ul><ul><li>Information & Access Services </li></ul></ul></ul><ul><ul><ul><li>Shared Business Services </li></ul></ul></ul><ul><ul><li>Presentation Services </li></ul></ul><ul><ul><ul><li>Composition </li></ul></ul></ul><ul><ul><li>Data Architecture </li></ul></ul><ul><ul><li>Integration Architecture </li></ul></ul><ul><ul><li>Security Architecture </li></ul></ul><ul><li>Design Guidelines </li></ul><ul><ul><li>Service Design Guidelines </li></ul></ul><ul><ul><li>Information & Access Service Guidelines </li></ul></ul><ul><ul><li>Presentation Service Guidelines </li></ul></ul><ul><ul><li>Service Assembly Guidelines </li></ul></ul><ul><ul><li>Service Security Guidelines </li></ul></ul><ul><li>Technology Mapping </li></ul><ul><li>Patterns of Usage </li></ul>Example SOA Reference Architecture Table of Contents
    27. 27. The Service Engineering Discipline Enterprise Service Engineering Framework (ESEF) Enterprise Service Engineering Framework (ESEF) Common SE Policies, Procedures & Patterns <ul><li>Specific design guidelines, patterns and examples </li></ul><ul><li>Enterprise policies & procedures </li></ul>Common SE Disciplines <ul><li>Enterprise service engineering disciplines </li></ul><ul><li>Lifetime service management </li></ul>Common Service Specifications <ul><li>Service identification, definition, design </li></ul><ul><li>Enterprise interface design </li></ul>
    28. 28. Establish Your Enterprise Architecture <ul><li>What makes up a successful SOA Reference Architecture? </li></ul><ul><ul><li>Authoritative definition of SOA for an organization </li></ul></ul><ul><ul><ul><li>Communication vehicle </li></ul></ul></ul><ul><ul><ul><li>Compliance tool </li></ul></ul></ul><ul><ul><ul><li>Based on well-defined SOA principles and expected benefits </li></ul></ul></ul><ul><ul><li>An architectural blueprint describing </li></ul></ul><ul><ul><ul><li>Organization of support for services into categories </li></ul></ul></ul><ul><ul><ul><li>Definition of principles and requirements to support each category and underlying infrastructure </li></ul></ul></ul><ul><ul><ul><li>Relationship between SOA and existing architectures </li></ul></ul></ul>
    29. 29. Moving To The Next SOA Stage Meeting The Developmental Challenges <ul><li>How do I sell the Business leaders on the need for a major change? </li></ul><ul><li>How can I connect them to the capabilities enabled by SOA? </li></ul>Build A Stream of Connected Projects Connect the Business to the Capability
    30. 30. Alignment of Enterprise SOA Objectives Business Objectives IT Principles <ul><li>Improve Efficiency Ratio </li></ul><ul><ul><li>Lending Process Optimization </li></ul></ul><ul><ul><li>Sourcing </li></ul></ul><ul><ul><li>Call Centre Optimization </li></ul></ul><ul><li>Grow Revenue – Faster Than Peers in a Sustainable Way </li></ul><ul><li>Small to Mid-Size Acquisitions </li></ul><ul><li>Expand Customer Relationships </li></ul><ul><ul><li>Cross-Sell (Internal/External LOB) </li></ul></ul><ul><ul><li>Relationship-based Pricing </li></ul></ul><ul><li>Customer Expansion </li></ul><ul><ul><li>Sales Effectiveness (Wholesale Mortgage & Corporate lending) </li></ul></ul><ul><ul><li>Risk Management </li></ul></ul><ul><li>Move from Transaction/Product Focus to Customer Focus </li></ul><ul><li>Move from Silo LOB Focus to Process/Service Focus </li></ul><ul><li>Move Towards a Collaborative Development Environment </li></ul><ul><li>Expose Loosely-Coupled Business Logic to Achieve Speed and Flexibility </li></ul><ul><li>Reuse Before Extend Before Buy Before Build </li></ul><ul><li>IT Costs Aligns with Business Value </li></ul><ul><li>Adopt a Process View of the Enterprise </li></ul><ul><li>* Inherit / Review Existing COIS IT Principles </li></ul>Prioritized SOA Benefits SOA Architectural Principles <ul><li>Guiding methodology that allows IT to deliver both core system renewals and new solutions in a step-wise fashion. </li></ul><ul><li>Extensible services beyond and across the enterprise </li></ul><ul><li>Rapid development of solutions </li></ul><ul><li>Consistent, accurate and predictable customer data </li></ul><ul><li>Enablement of Business/IT Alignment </li></ul><ul><li>Data is owned by the enterprise </li></ul><ul><li>Comply to enterprise & industry standards </li></ul><ul><li>Use the DAS layer to access disparate data via a single consistent access point </li></ul><ul><li>Security is designed from the outset </li></ul><ul><li>Thou shall Steal & Share – We value reuse </li></ul><ul><li>Separation of business logic from underlying technology and delivery channels </li></ul><ul><li>Separate business process from the service component </li></ul><ul><li>Instrumentation, traceability, ‘ilities’ </li></ul>Example
    31. 31. BEA SOA Cost Benefits SOA Projects When you justify costs for SOA, how many projects is the justification based on? Demonstrate the effects of SOA across multiple projects Europe
    32. 32. Build a Stream Of Connected Projects Incremental Project Harvesting Applications 1 2 3 4 5 6 7 8 9 10 11 12 Services Catalog 1 2 3 1 3 4 5 6 7 5 2 7 8 9 10 11 7 8 12 10 3 11 9 1 7 11 9 Cost Curve Over Time Presentation Services Shared Business Services Information and Access Services Services Management Service Bus Common Services Service Infrastructure Layer Composite Applications 1 2 3 4 5 6 7 9 8 10 11 12 A B C D E F G
    33. 33. Agenda <ul><li>The Market Today </li></ul><ul><li>Moving To The Next Stage of SOA Implementation </li></ul><ul><li>Summary </li></ul>
    34. 34. If You Are Early In Your SOA Journey Business Strategy & Process Architecture Costs & Benefits Building Blocks Organization & Governance Projects and Applications Business Strategy and Process Architecture Costs & Benefits Building Blocks Organization & Governance 1 Pick your starting point 2 Plan with a 2-3 year vision 3 Execute project-by-project 4 Approach SOA on six domains Process Projects IT-Led Projects Mega Projects Business Sponsorship High Low High SOA Complexity Business-Led Projects
    35. 35. SOA – Driving Towards Enterprise Implementation “ Many IT leaders are seeking guidance on how to approach pressing issues related to the business and organizational dimensions associated with SOA, including changing roles in the enterprise, governance procedures and policies, and funding considerations.” Sandra Rogers, Director SOA Research, IDC
    36. 36. Moving To The Next SOA Stage Leadership Required at the Enterprise Level Costs & Benefits Organization & Governance Define & Capture Your Benefits Align The Organization for Shareholder Value Requires Operational Leadership Business Strategy & Process Projects & Applications Build A Stream of Connected Projects Connect the Business to the Capability Requires Developmental Leadership Establish An Enterprise Architecture Make Service Engineering a Discipline Requires Architectural Leadership
    37. 37. SOA Information Available From BEA <ul><li>Detailed Infoworld and GCR Survey Results </li></ul><ul><li>BEA SOA Readiness Survey </li></ul><ul><li>BEA Domain Model Whitepaper </li></ul><ul><li>Customer Case Studies </li></ul><ul><li>Detail on new SOA Service Offerings </li></ul><ul><li>Dev2Dev, Arch2Arch, IT2IT, Exec2Exec </li></ul><ul><li>www.bea.com/soa </li></ul>
    38. 38. Accelerating Your SOA Implementation Bret Dixon SVP, Professional Services BEA Systems

    ×