1 / 27

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

Ivan Towlson , ECN Group. How to Fail With SOA: Anti-patterns for Service-Oriented Architecture. Agenda. Motivation Adoption anti-patterns Identification anti-patterns Realisation anti-patterns Discussion. Why SOA?. Add business value Return on investment

arnie
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related