Some of the greatest advantages of SOA derive from adopting interface contracts. (Of course the benefit of interface contracts isn’t limited to SOA, but they are definitely applied to good advantage in an SOA environment).
By the way the definition of SOA that I use is that it’s a style of design, not a technology. The design is implemented using one or more technologies.
One of the crucial aspects of any SOA design is the contract between the service requester and the sevice provider, which is typically expressed (at least in part) using an interface definition language such as IDL and/or WSDL.
Among the many benefits of designing contracts and defining interfaces is the ability to divide up the work. Once the contract is in place (at a minimum this would be the definition of the data to be shared, often expressed using XML) separate teams can go off and work in parallel to develop the service provider and requester.
This approach can scale effectively as the library of reusable services grows, dividing up the work across multiple development teams, perhaps in different geographies. And this approach also creates the possibility that the work can be divided across companies, too. And that it could more easily be outsourced and/or offshored.
But with all the great potential for dividing up the labor involved in IT development comes an equally great responsibility to ensure that things go as planned when the divided up work gets assembled. Someone has to ensure that the interface definitions are interpreted and implemented consistently, and preferably before the whole application is deployed.
The folks at Business Management recently interviewed me about this. We have found, through sometimes painful experience, that it is best to validate individual interfaces as they are created rather than wait until final assembly. Many of our customers are starting to realize they need to change their approach to application assembly when using an SOA based approach.