Service Contract Stability

SOA as a style of architecture reduces coupling between services by mandating that services have no knowledge of each other's implementations. Services communicate only by way of exchanging messages that conform to service contracts. As such, service consumers are dependent only on a service provider's service contract, not its implementation.

However if we do not take particular care in designing our service boundaries and responsibilities, and by extension its service contract, then we run the risk that our service contracts may themselves be highly dependent on a service's implementation. One such example of this is white box services.

Consequently, we want to align our service contracts with concepts that are very stable. With a JBOWS approach, services are exposed somewhat arbitrarily. They do not contribute towards any defined broader architecture. Therefore service contracts will have an arbitrary level of stability.

Next on the list is Service Oriented Integration. With this approach, service contracts are centred around applications. They are expressed in terms of the application with which we are integrating. Consequently if the scope of the application changes, or the application itself is exchanged for another (such as exchanging an Onyx CRM with MS CRM), the service contract is very likely to change.

So what about layered service models? In this case, we have atomic business tasks, business processes and data stores abstracted as services. These concepts are not at all stable. Businesses very often make changes in business processes that in turn require changes in how atomic business activities are defined and how data is represented. With this approach we are very likely to find ourselves changing our service contracts as business processes are updated.

But what about business capabilities? Business capabilities are by their very nature incredibly stable. Although a retail organisation may make regular changes as to how it goes about inventory management, the fact is that it will always have an inventory management capability. Moreover, other capabilities within the enterprise don't care how inventory management is performed. They only care that it is performed.

Consequently, aligning our service boundaries (and by extension our service contracts) with business capabilities gives us an incredible amount of stability. This is the basis of the self-contained process centric-service model introduced in an earlier post.

By defining our services around business capabilities we achieve greater business agility by way of being able to update how business functions are performed without influencing other services in our enterprise.