SOA and Agile Software Development

SOA projects are distributed and typically involve a number of software development teams. Coordinating the teams involved can be a challenge. You may find yourself particularly exposed if you are creating a service that is dependant on a number of other services. Changes or delays in any one of them can prevent you finalising your service. One approach is to specify a date, relatively early in the project, by which all interfaces should be finalised. This is very hard to achieve, as changes often come to light as development progresses. Once, the deadline has passed, there is a perception that each change needs to be incorporated immediately it arises. This can lead to churn as multiple minor changes have knock on effects.

Agile processes introduce the concept of iterations – fixed period of time during which as specific number of tasks are achieved. Synchronising the iterations of the teams is an effective way of coordinating them. These iterations also set an expectation for when changes should be applied and when the implications of those changes should be addressed.

For example, you could say that changes to shared schemas are made at the start of an iteration and that the implications are completely addressed by the end of that iteration. Requirements for changes that are found during an iteration are not addressed immediately, but wait for the next iteration. This might sound just as difficult to achieve. However, the rhythm established within a software development project as a result of these short iterations changes the mind set of those involved. It provides confidence that changes are properly addressed and encourages a discipline of ensuring that the consequences of the changes are fully thought through by the start of the next iteration.

Does your team structure work against SOA?

Traditional integration projects involving more than one team often become an exercise in getting the other team to do most of the work. For example, imagine such a project involving two teams: Team A is developing an application which needs to make use of a feature within an application maintained by Team B.

This is where the fun starts – Team B is tasked with making their application accessible to Team A. The quickest way for Team B to complete this task is to make use of what they have and expose their application as is. A directory on a file system is monitored for messages. A format based on an internal data structure is used for the messages. Team B now declares that their work is done. However, in doing so they may have created a headache for Team A.

This approach to integration works against SOA. A second project is not going to be tempted to reuse this communications mechanism. For a SOA to be successful, Team B should do everything possible to make life easy for Team A. New XML message formats should be designed and documented using XML Schema. A Web service should be created that performs the task. It should conform to all relevant SOA principals.

The effect of this is to place additional work onto Team B, while reducing the amount of work Team A needs to do. You may need to consider ways of encouraging and rewarding such behaviour as part of your plan to introduce SOA.