1. SOA Case Studies A Retrospective on Evolutionary vs Big Bang SOA James Carpenter Enterprise Architect Great American Insurance Co. jcarpenter@gaic.com

2. Overview Two case studies of companies building out an SOA with different approaches The advantages and challenges posed by each path Lessons learned on common issues and corresponding mitigation strategies

3. Evolutionary SOA Evolved from an Enterprise Application Integration (EAI) stack Home grown Enterprise Service Bus (ESB) Canonical data model Configuration-based integrations  Dynamic orchestration execution External and internal integrations with commercial and custom applications 1 year planned – 3 year delivery

4. Evolutionary SOA End State  More Service Oriented Integration (SOI) than SOA  Existing applications were not to be impacted

5. Big Bang SOA Purchased many commercial packages Integration of “best of breed” components Commercial ESB Static itineraries using shared services Canonical data model 1 year planned – 1 year delivered

6. Big Bang SOA End State  Reusable business service layer “speaks” domain  Existing applications intentionally impacted

7. Advantages Evolutionary SOA  Deliver iterative value  Leverage existing investments  Interfaces are stable

8. Advantages Big Bang SOA  Service contract can be designed  Functionality can be exposed and consumed as applications are being built

9. Challenges Evolutionary  Overall architecture footprint increases Maintenance  Reuse exists between applications

10. Challenges Big Bang  System interfaces are evolving simultaneously  Delivery schedule Technical debt

11. Challenges Common issues  Data sourcing Replication of data outside System of Record Additional synchronization  Service contracts Canonical data model Ownership and maintenance  Managing change Evangelism Communication

12. Challenges Conway’s Law “Any piece of software reflects the organizational structure that produced it.” Produces

13. Mitigation Strategies Decisions made as tactical action in a strategic direction – “stratactical”  Incur technical debt knowingly and only after evaluating the cost and benefit Intentional Enterprise Architecture  No “accidental” architecture  Create strategy  Break down to tactical steps and insert into active initiatives  Execute

14. Mitigation Strategies Communication  Leverage Conway’s Law instead of fighting it Produced By

15. Achieving the Value Consolidate integration points Identify functionality within applications to be exposed as Enterprise Business Services  Focus on the data contract as a business document in domain terms  Leverage industry models as a base when possible Single source of data and functionality  Impact existing systems…for the better

16. References Conway, Melvin. “How Do Committees Invent?”. http://www.melconway.com/research/committee s.html http://www.melconway.com/research/committee s.html Cunningham, Ward. “Technical Debt”. http://c2.com/cgi/wiki?TechnicalDebt http://c2.com/cgi/wiki?TechnicalDebt Fowler, Martin. “Design Stamina Hypothesis”. http://martinfowler.com/bliki/DesignStaminaHypo thesis.html http://martinfowler.com/bliki/DesignStaminaHypo thesis.html

17. Resources zapthink http://zapthink.com/http://zapthink.com/ Hohpe, Gregor and Woolf, Bobby. (2003). Enterprise Integration Patterns. Addison- Wesley.