Saturday 4 July 2009

Testable Architecture and Agile Development

I was watching and listening to Dan North and Michael Feathers on the web. It is worth a look. At about 12 minutes Dan says the following "You can TBD your way out of anything... There is balance between doing all up front design and doing no up front anything which is irresponsible." and he mentions that Richard Watt says "Enough up-front thinking" is what you need.

The tension between agile and "enough up front thinking" is what I want to explore. Those agile bigots that think you should not do anything up front miss the point. Hopefully there are not too many of them. Having deployed "testable architecture" in several sites now I do get asked how does this work with agile. And I think Dan and Michael have really nailed it.

What is enough?

The communication/interaction model between services in an SOA is probably a good place to start. The aim is to provide enough structure without getting in the face of developers who will operate in an agile process. If testable architecture, embodied today in the pi4soa tools, provides the necessary communication/interaction model along with the necessary minimum data structures (for example the business transaction identities needed to support the communication model and any asserted state thereafter) then we can (and we have in Cognizant) use it to provide "what is enough" and thereafter engage developers in an agile process to fill in the gaps. The structure is preserved and testable against requirements, as I have often said in my other posts. And in more recent posts that structure remains a valuable testable artefact for systems integration testing.