Soa best practice
0 likes•993 views
There are three key hurdles to enterprisewide SOA: 1. Lack of governance from the start of initiatives which can lead to project failures. 2. Choosing the wrong technologies which can derail even the best run SOA projects. 3. Resistance to federation which is the most natural approach to implementing SOA across an entire enterprise. To overcome these hurdles, the document recommends focusing on governance from day one while avoiding too much governance initially, carefully selecting enabling technologies, and proactively adopting a federated approach to diffuse SOA benefits organization-wide.
Soa best practice
- 1. Notes accompany this presentation. Please select Notes Page view. These materials can be reproduced only with written approval from Gartner. Such approvals must be requested via e-mail: [email protected]. Gartner is a registered trademark of Gartner, Inc. or its affiliates. Practitioner's Guide: Best Practices in Enterprisewide SOA Initiatives Massimo Pezzini
- 2. Enterprisewide SOA Is Multiowned and Federated Domestic Sales Administration Production International Sales Customer Support Customers Suppliers Contractors Outsourcers Enterprise SOA SOA Federation Enterprise SOA SOA Domains
- 3. Key Issues 1. What will be the technical and business drivers for strategic SOA adoption? 2. How will organizations incrementally approach large-scale SOA initiatives? 3. What are the key hurdles on the way to enterprisewide SOA, and how can organizations get over them?
- 4. Irresistible Forces Push Organizations Toward SOA Adoption SOA User Adoption IT cost reduction Escalating integration needs (A2A, B2B, SaaS) Need for business processes improvement Quest for greater business agility Lowering cost and growing maturity of enabling technology Availability of best practices Packaged- application vendors' pressure Cultural change More- complex application infrastructure Immature standards Heterogeneous technology and conflicting vendors' strategy Lack of governance Drivers Inhibitors
- 5. Adopting SOA-Enabled Packaged Business Applications Registry SOA backplane Registry SOA backplane Wrapped SOA Hybrid SOA Full SOA 2007 2008-2012 Post-2012 Pre-SOA packages/modules Vendor-provided standardized service-wrapped interfaces Packaged and custom processes and composite applications Minimalist SOA backplane Informal registry and governance Coexistence of full-SOA and pre- SOA packages/modules Coexistence of vendor-provided standardized native and wrapped interfaces Packaged and custom processes and composite applications Full SOA backplane Formal registry and governance Full SOA packages/modules Vendor-standardized native interfaces Packaged and custom processes and composite applications Full SOA backplane Formal registry and governance
- 6. Where Will Users Source Their Business Services? TCO Differentiation On-Demand Services (SaaS) Purchased Services (Packaged Applications) Custom Services (Built/Wrapped) Composite Application/Mashup (Packaged/Custom) Composite Process (Packaged/Custom) Business Impact of Services
- 7. SOA hasn't been ordered by the doctor: You can live without it. SOA adoption should be justified by balancing (certain) costs and (potential) benefits. However, most organizations will be forced to SOA by their packaged-application vendors. Investigate the SOA strategy of your packaged-application vendors and plan for a gradual adoption. SOA services and applications will be multisourced. SaaS and SOA go hand in hand. If you're planning for SaaS, you need to plan for SOA as well (and possibly vice versa). Bottom Line What will be the technical and business drivers for strategic SOA adoption?
- 8. Stages of SOA Adoption Stage 1 Introduction Stage 2 Spreading Stage 3 Exploitation Stage 4 Plateau IT Goals Proof of Concept Establish Technology Platform Leverage Services Sharing Enterprise SOA Infrastructure Business Goals Address Specific Pain (for example, Customer Portal) Process Integration (for example, B2B) Process Flexibility (for example, Time to Market) Continuous Adaptation and Evolution Single Application Multiple Applications (Single BU) Multiple Applications (Across BUs) Virtual Enterprise Scope <25 <100 <500 >500 <5 <25 <50 >50 <10,000 <100,000 <1,000,000 >1,000,000 <10 <20 <100 >100 No. of Published Services* No. of Service Consumers* No. of Service Calls/Day* No. of Service Developers* Enabling Technology (cumulative) Application Server, Portal, Adapters ESB, WSM Integration Suite, B2B SOA Reg/Rep BPM Policy Management Enterprise SOA Backplane *These figures represent typical scenarios, but they may vary considerably, depending on the specific organization's requirements.
- 9. Why SOA Initiatives Fail: Technology or Governance? Introduction Spreading Exploitation Plateau Risk of SOA Project Failures Lack of Governance Risk Technology Risk Less Risk More Risk Time
- 10. Enterprisewide SOA is a long journey. Plan for multiyear incremental implementation steps, but look for short- and medium-term payback. At each step, additional technology and organizational capabilities must be put in place. See "Toolkit: Planning for Service-Oriented Architecture With the Gartner SOA Adoption Model," G00143726. SOA success is a 50-50 business between technology and governance (and good old management). Bad technology choices can kill even the best-run SOA initiative. Focus on governance from Day 1, but initially avoid "too much" governance. Bottom Line How will organizations incrementally approach large-scale SOA initiatives?
- 11. The Seven Golden Rules for the Perfect First SOA Project 1. Set Goals and Collect Business-IT Requirements 2. Segregation of Duties Application design teams: • Service consumers • Service implementations Infrastructure Design Team (the future SOA COE) 3. Joint Design/Independent Implementations Services jointly designed by application teams Technically validated by the infrastructure team 4. Deliver Infrastructure (SOA Backplane) First Design, implementation, testing Validation against an agreed proof of concept 5. Deliver Services Before Consumer Applications Plan for services to be available and tested before relevant consumers 6. Test, Test and Test Again Plan for at least 25% of development effort on integration testing 7. Log, Log and Log Again Multiple turn-on/off logs Introduction
- 12. Service-Oriented Architecture Entails Tackling Multiple Technology Challenges Non-SOA Wrapped Application Multichannel Portal Composite Application (Mashup) WrapperWrapper Services Application Logic Native SOA Application Interface Interface Interface SOA backplane BPM Application Wrapper BPM Technology Portal Product, EAS, Composite Application Tools, Mashup Tools Portal Product Adapters, Programmatic Integration Servers TPM, EAS "All-in-One" Application Platform Suite ESB, MOM, XML Appliances Introduction
- 13. The SOA Backplane Unveiled: Web Services and More = Common Features = Advanced Features= Minimal Features Security Management Adapters Development Tools Life Cycle Management Tools Orchestration Policies Extensibility Framework Communication (SOAP, IIOP, JMS, MOM, RPC, ORB, TPM) Mediation/ Transformation Routing/ Addressing Naming QOS Registry Spreading
- 14. Standardized Business Objects Enable Interoperability and Reuse B2C E-Commerce Application Branch Office Packaged Application Interface Spreading SAP ERP Oracle Siebel CRM Customer Data (SAP Format) Customer Data (Siebel Format) Customer Data (ISV Format) Customer Data (Custom Format) Customer Data (Standardized Format) Composite "Get Customer Data" Service
- 15. How Do You Know If You Are Doing It Right or Wrong? Spreading Number of Services Deployed Number of Consumer Applications Deployed Number of Services/No. of Consumers Number of Services Shared by at Least Two Applications Average Sharing Ratio Optimal Trend Volume of Service Requests Number of Requests per Service Service Request Response Time Number of New Services Developed per Each New Consumer Application Time to Deployment for New Consumer Applications Cost of Application Maintenance Examples of SOA Technical Metrics Reuse QOS Cost Reduction Goal/Focus
- 16. How Do You Enforce Sharing of Services? Exploitation Service Definition Process Service Registry and Life Cycle Management Tools Reward Policies Shareable Services "Chasing" Team Mainstream Aggressive Standardized Business Objects
- 17. SOA Domain: The Key Conceptual Enabler for Federated SOA Domain SOA Backplane Domain Registry Related set of consumers and services Single business ownership and span of technical management Single SOA center of excellence Common set of governance processes Unified domain SOA backplane (at least logically) Unified domain service registry (at least logically) 30 to more than 300 services (depending on domain scope) >80% of service invocations are intradomain >75% of service consumer apps call only intradomain services Up to 35% of domain services shared by multiple consumers Up to 75% of domain services needed by a new domain application are already available SOA Domain Definition Typical Characteristics* *Figures are indicative of a mature domain in which most required consumer applications and service providers have already been implemented. Domain SOA COE Exploitation
- 18. Federated SOA Backplane Topologies Point-to-Point Uber-SOA Backplane Intermediary SOA Backplane Characteristics: • SOA backplanes connect to each other via point-to-point links. • Each link can be implemented using different protocols. Pros: • Simple to implement. • Low cost. Cons: • Accountability/responsibility. • Scalability. Best when: • Small number of SOA backplanes. • Semiautonomous, peer domains. Characteristics: • One specific domain SOA backplane also acts as a central "broker" linking all the other backplanes. Pros: • Simple to implement. • Well-defined responsibility. Cons: • Risk of uber-backplane overload. • Security/privacy. Best when: • One large domain and multiple smaller domains. • Hierarchical company organization. Characteristics: • Each SOA backplane links into a central, enterprisewide backplane supporting only interbackplane mediation (routing, transformation). Pros: • Well-defined responsibility. • Noninvasiveness. Cons: • Higher costs. • Single point of failure. Best when: • Large number of SOA backplanes. • Semiautonomous, peer domains. Exploitation
- 19. Coordinating Multiple SOA Centers of Excellence Virtual Hierarchical (Uber-COE) Mediator Characteristics: Each SOA COE is independent, but there is a form of coordination to agree on a common set of technologies, standards and governance processes. Pros: • Technically noninvasive. • Minimal organizational impact. Cons: • Vaguely defined responsibilities. • Lowest common denominator approach. Best when: • Small number of SOA COEs. • Semiautonomous, peer domains. Characteristics: One domain SOA COE drives other COEs through recommendations for standards, technologies, products and governance and by providing support. Pros: • Well-defined responsibilities/roles. • Minimizes technical and governance processes variations. Cons: • Risk of political resistance. • Conflicting priorities for the uber-COE Best when: • One large domain and multiple small domains. • Hierarchical company organization. Characteristics: A dedicated Enterprise SOA COE mediates between COEs by reconciling standards and by providing an interdomain SOA backplane. Pros: • Well-defined responsibilities/roles. • Noninvasiveness. Cons: • Higher costs. • Organizational complexity and inertia. Best when: • Several strong and established COEs. • Semiautonomous, peer domains. Exploitation
- 20. Even in SOA, "Well begun is half done." Leverage the first project to lay down the foundation for the SOA backplane, SOA governance and SOA center of excellence. SOA doesn't happen by magic. Use a sound combination of "stick" and "carrot" to achieve alignment with SOA goals and principles. Federation is the most-natural approach to systematic, enterprisewide SOA. Proactively adopt a federated approach to diffuse SOA benefits across the entire enterprise. Bottom Line Which are the key hurdles on the way to enterprisewide SOA, and how can organizations get over them?