SOA - Aligning Business and IT?

1. SOA - Aligning Business and IT? Ole Rasmussen Senior IT Architect, Business Manager IBM Global Business Services (+45) 2880 9572ora@dk.ibm.com

3. “Through 2010, the biggest barriers to SOA adoption will be non-technical issues related to inadequate governance, lack of clear value metrics, poorly defined requirements and scope, and insufficient business involvement in project prioritization and service identification.” Predicts 2007: Application Strategy and Governance Emerge as Core IT Competencies, Gartner, November 2006

4. Do we all agree on the basics?Service-Oriented Architecture is an architectural style that supports service orientation - a way of thinking in terms of services and service-based development A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data) Is self-contained May be composed of other services Is a “black box” to consumers of the service The Service-Oriented Architecture architectural style has the following distinctive features It's based on the design of the services - which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes. Service representation uses business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration. It places unique requirements on the infrastructure - it's recommended that implementations use open standards to realize interoperability and location transparency. Implementations are environment-specific - they're constrained or enabled by context and must be described in that context. It requires strong governance of service representation and implementation. It requires a "litmus test" that determines a "good service." Open Group’s definition of SOA - http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632

5. Your context influences your perception of SOA Capabilities that a business wants to expose as a set of services to clients and partner organizations Business An architectural style that requires a service provider, requestor and a service description. It addresses characteristics such as loose coupling, reuse and simple and composite implementations Architecture A programming model complete with standards, tools, methods and technologies such as Web services Implementation A set of agreementsamong service requestors and service providers that specify the quality of service and identify key business and IT metrics Operations

6. Service Consumer Portlet WSRP B2B Other consumers business processes process choreography services atomic and composite Integration (Enterprise Service Bus approach) Data Architecture & Business Intelligence QoS, Security, Management & Monitoring Infrastructure Service Governance Service Provider service components Custom Application OO Application Packaged Application operational systems Packaged Application Custom Application Core in a SOA based architecture is the services, but more is needed – convergence towards this layered model (“SOA Solution Stack”)

7. Web Services can be a part of the answer ... but mostly we'll get to that later Most of today's production Web Services systems aren't service oriented architectures - they're simple remote procedure calls or point-to-point messaging via SOAP or well structured integration architectures Service Oriented Architecture is another part Most of today's production service oriented architectures don't primarily use Web Services - they use ftp, batch files, asynchronous messaging etc. - mature technologies SOA = Componentization = Flexibility = Good Web services = Standardization = Interoperability = Good BOTH = Optimal Is Web services part of the answer?

8. Everything is not services, and services are not everything!The SOA Solution Stack is an architectural view of the SOA building blocks. These are only a fraction of the architectural building blocks in the enterprise. This is an application by itself composed of the “usual” components like user interface, business logic and data

9. Anti-pattern: Chatty Services – decreasing flexibility and increasing complexity By Post – the Service Style By Phone – the API Style • Client requests application form • Provider sends it • Client fills it out and returns it • Provider determines “yes” or “no” and sends it back • Client calls provider • Provider asks “How can I help?” • Client: “I’d like a mortgage, please.” • Provider: “What is your name?” • Client: “Bond, James Bond” • Provider: “What is your address?” • Client: … • … • Provider: “Ok, your mortgage number is 42; I’ll post the details.”

10. Process Service Data Service-oriented modeling is necessary to define a service-oriented architecture - just as OOAD is necessary to define object-oriented systems and component-based development is used to define component-based architectures A service is a logical representation of a repeatable business activity that has a specified outcome Service-Oriented Architecture is based on the design of the services - which mirror real-world business activities comprising the enterprise (or inter-enterprise) business processes. I.e. we need a method aimed at enabling target business processes through the identification, specification and realization of business-aligned services that form the foundation of a SOA Leading bad practice: Using use cases for service identification!

11. Process Service Data Be careful about modeling responsibilities – especially expectations for business people. We want to align business and IT, but have to acknowledge that understanding and creating models is complicated Business people can model processes, but typically do not bother with variances, compensation and low level details regarding data Conceptual Logical Physical (XML) Business people can model data on conceptual level, but typically gets into troubles modeling on the logical level. Business people can identify services and describe them on “conceptual” level

12. All business activities are not good services.We must distinguish between candidate and exposed services Candidate Services Business Alignment Composability Externalized Service Description Redundancy Elimination Service Litmus Test Services (Exposed) SOA requires a "litmus test" that determines a "good service." The service must be traceable back to a business task or goal or it may not yield benefits required for SOA implementation Composability is defined as an attribute that enables the service to participate in a service composition The most basic property of a service is that it has an externalized service description The service must be usable in all contexts where its function is required Remember: Deciding to promote a service has a price tag • Modeling • Infrastructure (in operations) • Governance

13. Who has what responsibility? Can you see performance challenges? We want to omit point-to-point interaction: Central in an SOA you find the Enterprise Service Bus – mediating the service consumer and the service provider Consider this in a multi-provider environment

14. Consistent Service Model Reconcile Multiple Viewpoints & Interests Enterprise-wide focus Actually “Inter-enterprise” The governance model defines: • What has to be done? • How is it done? • Who has the authority to do it? • How is it measured? “Effective IT Governance is the single most important predictor of value an organization generates from IT.” MIT Sloan School of Mgmt. SOA approach mandates strong governance … Strategy Planning Business Opportunity Business Strategy Information Technology Strategy Technology Availability Business Architecture IT Architecture Model & Assemble Business Operating Environment and IT Infrastructure Deploy & Manage IT Solutions

16. Eating the SOA elephant is about planning your services and increasing your Service Orientation capabilities Open Group Service Integration Maturity Model

17. http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.htmlhttp://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html SOA – Not a Silver Bullet Essential Difficulties - the difficulties inherent in the nature of software • Complexity • Conformity • Changeability • Invisibility Accidental Difficulties – only due to our (mis-) behavior