SOA Case Studies A Retrospective on Evolutionary vs Big Bang SOA James Carpenter Enterprise Architect Great American Insurance Co.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References Conway, Melvin. “How Do Committees Invent?”. s.html s.html Cunningham, Ward. “Technical Debt”. Fowler, Martin. “Design Stamina Hypothesis”. thesis.html thesis.html

Resources zapthink Hohpe, Gregor and Woolf, Bobby. (2003). Enterprise Integration Patterns. Addison- Wesley.