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.