How to Fail With SOA: Anti-patterns for Service-Oriented Architecture

1. Ivan Towlson, ECN Group How to Fail With SOA:Anti-patterns for Service-Oriented Architecture

2. Agenda • Motivation • Adoption anti-patterns • Identification anti-patterns • Realisation anti-patterns • Discussion

3. Why SOA? • Add business value • Return on investment • Reusable for multiple applications • Interoperability, self-describing • Policy-driven configuration • Unified governance 2.0 • Semolina pilchard climbing up the Eiffel Tower

4. Why Anti-Patterns? • Why do we need to know how to screw up? • So we can get promoted to management

5. What is a Pattern? • Can use the same solution a million times without ever doing it the same way twice. • Technology independent – can apply solution equally regardless of underlying technology

6. What is an Anti-Pattern? • Can make the same mistake a million times without ever doing it the same way twice. • Technology independent – can foul upequally regardless of underlying technology

7. What is an Anti-Pattern? • A common set of circumstances and a response which is obvious, attractive and wrong • The antipattern describes: • How you are likely to get here • Why you don’t want to be here • A resolution to the problem (“refactored solution”) • Use antipatterns constructively

8. Taxonomy • Adoption – the decision to implement a service-oriented architecture • Identification – the design and structure of the service set • Realisation – the implementation and construction of an individual service Adapted from Ang et al, SOA Antipatterns http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/

9. Adoption Anti-Patterns

10. Technology Bandwagon • Problem: SOA adoption driven by technology fashion instead of business need • Symptoms: Nobody can express how the SOA effort is going to help the business, or document how it has helped it • Cause: Keeping up with the Joneses • Refactored solution: Hype-Free Value Proposition

11. Big Bang • Also known as: Boiling the Ocean • Problem: Attempt to move all business services to SOA at the same time • Symptoms: Spiralling cost and risk, death march • Cause: Overambition, hype • Refactored solution: Business Supported Roadmap

12. Laundry List Benefits • Also known as: SOA Silver Bullet • Problem: Unrealistic expectations of SOA value • Symptoms: “Once we have the SOA, all our time/cost/complexity/interoperability/ management/etc. problems will be over!” • Cause: Consultants, usually • Refactored solution: Dose of Reality

13. Identification Anti-Patterns

14. SOA = Web Services • Problem: No consideration given to the content and factoring of services, only to the technology • Symptoms: “We’re fully SOA-compliant – we use WSE.” • Cause: Service design driven by technical experts, not business experts • Refactored solution: Business Driven Services

15. Balkanisation • Also known as: Service Silos • Problem: Services built around applications, so each application exposes similar but different “services” • Symptoms: “And this is the PeopleSoft service.” • Cause: Service design driven by balkanised business or technology groups • Refactored solution: Governance

16. One-Click Services • Also known as: Technology Granular • Problem: Services are thin wrappers around existing code, with no business abstraction • Symptoms: Interfaces look suspiciously like COM objects, green screens or sprocs – but with XML • Cause: Oh-so-seductive “make a Web service in just one click” checkboxes and frameworks • Refactored solution: Business Driven Facade

17. Realisation Anti-Patterns

18. Uberservice • Problem: A single service that takes arbitrary XML • Symptoms: Uh, a single service that takes arbitrary XML • Cause: “We just wanted to allow for future changes.” • Refactored solution: Granular Services, Evolution Through Versioning

19. Chatty Protocol • Problem: Fine-grained operations • Symptoms: Operations involve multiple service calls (network round-trips), with corresponding performance impact • Cause: In-process thinking (e.g. OO) transferred to messaging environment, often helped along by frameworks that disguise the transition • Refactored solution: Messages As Documents

20. Point to Point • Problem: Applications send messages directly to services • Symptoms: Changes to cross-cutting concerns (e.g. logging), business processes and application topology are costly and complex to implement • Cause: Add Web Reference, HTTP fixation, overhead of middleware • Refactored solution: Message Bus / Broker

21. Irresponsible Implementation • Problem: Design discipline breaks down within the service • Symptoms: Implementation of changes to services, or new services, is costly and unpredictable • Cause: “But we’re service-oriented now, not object-oriented!” • Refactored solution: Service Facade

22. Expose Business Objects • Problem: Business objects in service interface • Symptoms: Business object designs distorted to meet toolkit requirements (e.g. XmlSerializer); unstable service contract • Cause: “This is easy! You just add [WebMethod]!” • Refactored solution: Message Objects or Contract Metadata

23. Expose Implementation • Problem: Service exposes implementation details • Symptoms: Technology changes in one application affect every other application; “It returns an EDIFACT message” (or DataSet) • Cause: Design team aligned to back-end host application rather than to business function • Refactored solution: Messages As Documents

24. Dependent Client • Problem: Client application code depends on service contract • Symptoms: Cannot switch to alternative service provider (or new service version) without major client rewrite • Cause: Development team aligned to “service as API” rather than required business function • Refactored solution: Service Agent

25. Themes • Business driven • Not application-driven • Not IT-driven • Message-centric / document-centric • The Ron Jacobs metaphor: departments, messengers and envelopes – it was good enough for the 1920s and it’s good enough for us

26. Summary • Adoption • Technology Bandwagon, Big Bang, Laundry List Benefits • Identification • Web Services = SOA, Balkanisation, One-Click Services • Realisation • Uberservice, Chatty Protocol, Point to Point, Irresponsible Implementation, Expose Business Objects, Expose Implementation, Dependent Client

27. For Discussion • How do we unpick SOAs that have fallen victim? • What other areas do we need to attend to? (E.g. management, governance.) What anti-patterns have we observed in these areas? • How can IT achieve the necessary engagement of the business? How do we organise for success? What procedures do we introduce for review etc.? Any other stakeholders? • What improvements to our frameworks and tools would help? (Linguistic constructs? DSLs? Designers?) • Is SOAP itself an anti-pattern? ivan@hestia.cc http://hestia.typepad.com/flatlander ivan.towlson@ecngroup.co.nz http://www.ecngroup.co.nz