Practitioner's Guide - Moving Toward Enterprise-wide SOA: Do's and Don’ts

1. Practitioner's Guide - Moving Toward Enterprise-wide SOA: Do's and Don’ts Massimo Pezzini

2. Service Oriented Architecture Entails Tackling Multiple Technology Challenges “All-in-one” Application Platform Suite Native SOA Application Non-SOA Wrapped Application Services Application Logic Wrapper Wrapper Wrapper Interface Interface Interface TPM, EAS SOA Backplane Adapters, Programmatic Integration Servers ESB, IS, MOM, XML Appliances BPM Application BPM Suite Composite Application (Mash Up) Portal Product Multichannel Portal Portal Product, EAS, Presentation Integration Server

3. Key Issues • What are the technical and business drivers for enterprise-wide SOA? • What are the critical stages organizations will go through in implementing SOA? • What users should and shouldn’t to succeed in large scale SOA initiatives?

4. Irresistible Forces Push Organizations Toward SOA Adoption Cultural change Conflicting packaged apps vendors' SOA strategy Lack of governance More complex application infrastructure SOA User Adoption Immature standards Packaged application vendors' pressure Quest for greater business agility Availability of best practices Lowering cost and growing maturity of enabling technology BPM popularity Escalating integration needs (A2A, B2B, SaaS) IT cost reduction

5. Adopting SOA-enabled Packaged Business Applications Wrapped-SOA Hybrid-SOA Full-SOA SOA Backplane SOA Backplane Registry Registry 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 From? Business Impact of Services TCO Differentiation On-Demand Services (SaaS) Purchased Services (Packaged Applications) Custom-Built Services Composite Process (Packaged/Custom) Composite Application/Mash-up (Packaged/Custom)

7. Stages of SOA Adoption Stage 1 Introduction Stage 2 Spreading Stage 3 Exploitation Stage 4 Plateau Address Specific Pain (e.g., Customer Portal) Process Integration (e.g., B2B) Process Flexibility (e.g., Time to Market) Continuous Adaptation & Evolution Business Goals Leverage Services Sharing Establish Technology Platform Proof of Concept Enterprise SOA Infrastructure IT Goals Multiple Applications (Cross BUs) Multiple Applications (Single BU) Single Application Virtual Enterprise Scope No. of Published Services* No. of Service Consumers* No. of Service Calls/Day* No. of Service Developers* <25 <100 <500 >500 <5 <25 <50 >50 <10,000 <100,000 <1,000,000 >1,000,000 <10 <20 <100 >100 Enabling Technology (cumulative) Application Server, Portal, Adapters ESB, WSM Integr. Suite, B2B SOA Reg/Rep BPM Policy Mgmt. Enterprise SOA Backplane * =These figures represent typical scenarios, but they may vary considerably depending on the specific organization's requirements.

8. Why SOA Initiatives Fail:Technology or Governance? Introduction Spreading Exploitation Plateau More Risk Technology Risk Risk of SOA Project Failures Lack of Governance Risk Less Risk Time

9. The Six Golden Rulesfor the Perfect First SOA Project Introduction • Set Goals and Collect Business/IT Requirements • Segregation of Duties • Infrastructure Design Team (the future SOA COE) • Application Design Teams: • Service consumers • Service implementations • Joint Design/Independent Implementations • Services jointly designed by Application Teams • Validated by the Infrastructure Team • Deliver Infrastructure (SOA Backplane) First • Design, implementation, testing • Validation against an agreed proof-of-concept • Deliver Services before Consumer Applications • Plan for services to be available and tested before consumers • Test, Test and Test • Plan for at least 25% of development effort on integration testing • Log, Log and Log • Multiple turn on/off logs on the "borderlines"

10. Life-Cycle Management Tools Development Tools Registry Orchestration Policies Security Management Adapters Routing/ Addressing Mediation/ Transformation Extensibility Framework Naming QOS Communication (SOAP, IIOP, JMS, MOM, RPC, ORB, TPM) The SOA Backplane Unveiled:Web Services and More Spreading = Minimal Features = Common Features = Advanced Features

11. Life-Cycle Management Tools Development Tools Registry Orchestration Policies Security Management Adapters Routing/ Addressing Mediation/ Transformation Extensibility Framework Naming QOS Communication Which Piece of InfrastructureDo You Need to Get Started With? Spreading Primary concern How do I regain controlof my "Wild West SOA"? Primary concern How do I manage my Web services network? 25% of cases 5% of cases SOA Backplane 70% of cases Primary concern How do I make my new SOA and old pre-SOA apps work together?

12. How do You Know if You are Doing It Right or Wrong? Spreading Optimal Trend Examples of SOA Technical Metrics • # of Services Deployed • # of Consumer Applications Deployed • # of Services/Number of Consumers • # of Services Shared by at Least Two Applications • Average Sharing Ratio • Volume of Service Requests • Amount 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

13. Flow Management in SOA:One Size Doesn't Fit All Spreading Service Composition Straight-Through Process Microflows Workflow SOA Enables Process Integration Flow Management Enables SOA Goal Implement services by executing flows among software components Goal Implement coarse-grained services by executing flows among fine-grained services Goal Automate business processes involving multiple services Goal Automate business processes involving human tasks and services Scope Single application Scope Usually single domain Scope Single/multiple domains Scope Single/multiple domains • Key Features • Subsecond execution cycle • Transaction support • Usually nondistributed, single platform • State is not persisted • Key Features • Subsecond to minutes execution cycle • Compensation flows (automated or manual) • Distributed/multiplatform • State may or may not be not persisted • Key Features • Minutes to hours execution cycle • Compensation flows (automated or manual) • Distributed/multiplatform • State must be persisted • Key Features • Minutes to months execution cycle • Compensation flows (automated or manual) • Distributed/multiplatform • State must be persisted "Orchestration"

14. How Do You Know Which Services You Actually Need (and How Large They Are)? Exploitation Process Model Process-Centric (Top-Down) Business Services Business Services Data-Centric (Bottom-Up) CRUD Services Data Model Established Apps. Wrapped Services Application-Centric (Meet-in-the-middle) New Composite App.

15. How Do You Enforce Sharing of Services? Exploitation Service Definition Process Standardized Business Objects Mainstream Service Registry Rewarding Policies Aggressive Service "Chasing" Team

16. Domain Registry Domain SOA Backplane 'Divide and Conquer': Taming SOA Complexity Through SOA Domains Plateau • 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 • Unified Domain Service Registry Clues SOA Domain • 30 to 300 services (depending on domain scope) • >80% of service invocations are intra-domain • >75% of consumers invoke only intra-domain services • Up to 35% of domain service shared by multiple consumers • Up to 75% of domain services needed by a new domain application are already available Domain SOA CoE Characterization* * = figures indicative of a mature domain where most of the requiredconsumers and services have been already implemented

17. Enterprisewide SOA is Federated, Multi-owned and Multi-layered Plateau Domain SOA CoE SOA Domain "C" Domain SOA CoE Domain Registry Local Services Domain SOA Backplane Domain SOA Backplane Domain Registry Local Services SOA Domain "B" Enterprise SOA Backplane Enterprise Registry Domain SOA CoE Public Services Enterprise SOA CoE Private service = consumed by one application Domain SOA Backplane Local service = consumed by more applications in the same SOA domain Domain Registry Local Services Public service = consumed by more applications from multiple SOA domains SOA Domain "A"

18. Different Styles of Implementing SOA Initiatives: Pick Your Own One Basic Core Extended Federated One or Few Related Applications Multiple and Related Applications One or Multiple Unlinked SOA Domains Multiple and Federated SOA Domains Scope Formally Defined Formally Defined Formally Defined Formally Defined Service Interfaces Formally Defined within each SOA Domain Formally Defined Cross-domain Business Objects Informally Defined Informally Defined Business Objects Minimal and Common Features Full Features in each SOA Domain Interoperable Domain Specific SOA Backplanes Minimal Features SOA Backplane Formally Managed in each SOA Domain Enterprise-wide Federated SOA Domain Registries Informally Managed Formally Managed within a Dev. Team Service Registry Established Domain CoEs (Governance Focus) Domain CoEs and Enterprise CoE Established (Technology-Focus) SOA CoE Informal Informal and CoE-Enforced Formally Defined and CoE-Enforced Enterprise Federated Governance Minimal Governance Primary Goal within Dev.Teams Primary Goal within each Domain Cross-Domains and Enterprise-Wide Secondary Goal Service Sharing

19. Recommendations • SOA is a journey. Plan for multiyear incremental implementation steps, but look for short- and medium-term payback. • SOA initiatives pose technology challenges that would be dangerous to underestimate. • Avoid a “Wild West SOA”. Establish governance processes focused on meeting measurable objectives. • Choose the SOA implementation style that best fit with your business and IT goals. • Beware of SOA "extremism." SOA principles should be applied with a grain of salt.