Wednesday, 5 November 2008

Agile SOA?

SOA promises business agility, so the question naturally arises whether Agile methodologies (as in XP, Scrum etc) are better suited to SOA development than more traditionaly (albeit iterative) methodologies such as RUP.

If you're not familiar with Agile principles you've probably been marooned on an island somewhere. Agile is the slated answer to the software development crisis. To quote the Agile Manifesto (

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The key principles of Agile methodologies include things like:
- Customer satisfaction through rapid, continuous delivery of functional software
- Working software, not documentation, is the principal measure of progress
- Change is welcomed
- Close, face-to-face daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Continuous integration of source code changes
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
- Test driven development

Agile methodologies are in general suited to small teams of senior developers with rapidly changing requirements and an end user. Some work has been done to apply Agile on the larger scale but in general the larger the scale and number of interworking groups, the less agile is applicable "to the whole".

The last phrase is key, because certainly there is no issue with organising service development teams in an Agile manner, however Agile as a methodology for delivering enterprise SOA is surely inappropriate?

SOA is highly planned, requires a defined architectural and organisational framework in which to operate, needs lots of up front business modeling to help drive service requierments, needs formally defined and well-documented contracts, needs formal rigorous change management, and finally some measure of stability because of the cost of change to clients.


Post a Comment