How SOA helps you hit the agile sweet spot

Over at InfoQ there is an article on what the "ideal teamsize" should be now this isn't exactly news to anyone who has read the world's best book on Software Development (if you haven't read it you shouldn't be allowed into work tomorrow) or indeed who has tried to work in a large team it is one of the key ways that SOA can really help a development project.

Firstly lets face the reality that there are certain things that 4 to 6 people can't build on their own, an Air Traffic Control system, the entire Tax Processing system of a large country, Rome that sort of thing. And lets also face the reality that in fact lots of large business system deliveries could be done with less people that are currently on them, but again probably not 4 to 6.

This is where SOA really can help as you kick-off the project. I had a quick burst on this a while back but I thought I'd go over the basics again.

1. When you are doing a project, work out what the services are upfront.
   
2. Clearly define the interactions between these services
3. Assign separate teams to each service to formalise the interfaces
4. Within each service look to break down further to create a set of implementation services that
1. Can be developed behind clearly defined interfaces
2. Can be developed in around a month by a few people
3. Has a clearly defined unit & system test suite
5. Formalise the interfaces and map the dependencies between services
6. Plan a series of small projects within a larger programme of work

Here the Service Architecture's structure will help you to have a clear communication structure and by having clear Mock, Unit and System Test suites for the services you don't have to rely on honesty to track how things are going. At each level the teams are small, but overall the number of people able to work effectively is very high.

This fights at one of the accepted wisdoms of IT, namely that more communication is a good thing. It isn't, what is required is effective and directed communication, which is what a decent Service Architecture can help to provide a project.

Again this isn't new stuff, its been around for many many years in research around IT projects, and been implemented by people who certainly wouldn't have used the trendy term "agile" to describe how they did their projects. But would have thought on day one a about how to break up the project, some of then used processes (CICS people for instance) and now we should be using Services, the approach and aim however is the same, its easier to manage 4 people, or even 4 teams of 4 people than it is to manage 16 people directly.

Technorati Tags: SOA, Agile, Service Architecture