Matt Simms (@matty_simms) asked me this:

By “be Agile”, I assumed that Matt meant something like “How compatible are Service-Oriented Architecture and Agile practices?” or perhaps “Does practising SOA mean that we have to abandon Agile practices, principles, and values?” I propose this as an equivalent question:

Can you deliver Services incrementally?

I think of this as essentially the same question, biased perhaps by my impression of many people’s beliefs about SOA: specifically that SOA means Big Design Up Front (BDUF), the antithesis of the agile principles of incremental and evolutionary design as well as practices like TDD, BDD, and continuous integration. While many SOA-related programming and deployment tools encourage BDUF, you could say the same about most software development-related tools, SOA or otherwise, since BDUF remains a very popular approach to software design in general. I see nothing in particular about SOA that makes it unsuitable for incremental delivery. The approaches that we use to refactor (evolve) any public-facing API apply to SOA, just as they apply to relational database schemata and published file formats.1 I won’t lie: publishing APIs constrains our freedom to change things at will, but we have most of (all?) the techniques we need to mitigate the associated risk. The principles (and many of the concrete techniques) in Ambler and Sadalage’s Refactoring Databases apply just as well to published web APIs as they do to relational databases.

So let me offer some simple guidelines to help marry SOA and Agile Methods.

Make your Services as small as you can, because smaller ones tend not to need to change.

  • This follows from both the Interface Segregation Principle and the Open/Closed Principle.
  • Rather than change tiny Services, you will tend to replace them, which you can do much more safely Doing the Three-Step (add the new one, migrate customers/change the old one to use the new one, remove the old one).

Drive down the risk of changing a Service incorrectly by writing solid specifications.

  • As usual, use a combination of examples (scenarios) and general statements.
  • When in doubt, add an example, but don’t force yourself to write out 10 examples just to avoid writing a general statement.
  • Add examples until fear turns to boredom.

Plan to migrate Services from the beginning. If you don’t know about Rails database migrations, learn about them.

  • The web makes redirecting HTTP requests easy, so learn how and where to add redirects in your environment.
  • Test your Service thoroughly in pre-production, then support both the old and new Service at the same time for a while (A/B testing between old and new).
  • Retire the old Service when you have enough confidence in the new one.
  • Make it easy to put the old Service back into production. Again, use HTTP redirects!

As an extra added bonus, ask yourself why you’d need to limit any of the foregoing advice to Web Services and SOA.

  1. I recommend Martin Fowler’s article “Public versus Published Interfaces”.↩︎