SOA & Agile Software Development

Many industry articles and experts would like you to believe that SOA and Agile software development methodologies (let’s call them “ASDM” for simplicity sake) are made for each other. People like Gregor Hohpe of Google or Brenda Michelson of ebizQ would like you to believe that Agile and SOA are a powerful combination. I would like to set the record straight once and for all. ASDM, regardless of the flavor or the sort, is the worst thing you can apply to your SOA program.

Agile is created to build software quickly while requirements continue to shift thus allowing the end users to see the results in days rather than months. Refactoring (read “change”) is assumed as normal and is, in fact, welcomed. Software design is often organic and evolves with each story card or iteration.

SOA is an architectural style that requires rigorous planning, forethought, and discipline. Most experts will tell you that A (“Architecture”) is the important element in SOA. Services must be designed with an eye towards the future reuse, not immediate requirements. Contract-first development, which is inherent in any SOA approach, is largely alien to an ASDM. Same is true for comprehensive design cycles that focus on designing reusable, flexible, and architecturally sound services. Agile simply has no room for design. Code is self documenting, Agilists will tell you. Some Agile flavors that account for some design time still focus on a very narrow set of requirements and never take the big picture into account.

The most telling example of incompatibility between SOA and Agile is a project that needs to build a large number of shared services for a large number of consumers. Under an ASDM, each service would be built incrementally, over time as the story cards with new requirements come up. As new consumer’s requirements are satisfied, the service must change, which most likely triggers the need to test the impact on the existing consumers. The more consumers the service has, the more testing must be done. Using a model-driven design and contract-first development would undoubtedly solve this problem. Service interface would be modeled in its entirety and a complete contract presented to each consumer. This would eliminate the need to retest each subsequent consumer integration.

To take this example even further, imagine that this needs to be done for several, not just one project! And timelines are not evenly in synch. Amount of refactoring and testing would become enormous. Throw in the typical governance processes each organization has in place, a registry that keeps track of each service’s lifecycle and policies, service management platform that must be integrated with it, an ESB through which services must be exposed, etc. and you will get an even better picture. Without proper planning, design, and architecture, your SOA program will not succeed. No Agile methodology applies the level of rigor and depth required to build truly reusable services. Stop using Agile before it’s too late for your SOA program!