COTS Applications and the Service Boundary

Most commercial off the shelf (COTS) applications these days expose Web service endpoints so they can interoperate in a platform neutral way with other applications in your enterprise. These COTS applications are not services in their own right.

Although they expose Web service endpoints, they are not services in the context of SOA. The endpoints they expose should be considered integration points to be leveraged inside the service boundary.

The contract of a business service must be expressed in terms of your business. The contract should abstract away the implementation details of the service (such as which COTS application is in use), expressing the business functionality in the language of your business.

The same off the shelf package will fulfil different roles in different services in different organisations. For instance in my last post, we explored an example where we had a CRM system being used to support both a Sales service and a Marketing service.

Now this could be two instances of the same CRM package, or as in the example could be a shared instance. Regardless, the functions being exposed to the enterprise are two distinct services that based on their service contracts perform Sales and Marketing functions.

If we directly exposed the CRM application's service interface as both the Sales and Marketing service contracts, then both services would have the same interface! This would imply they perform the same business function. Obviously as they are distinct services, they do not.

There needs to be an abstraction away from the service interfaces offered by COTS applications to the intended business function to be performed by the service.

So in summary, do not directly expose a COTS application's Web service endpoints to the other services in your organisation. Put a layer of abstraction in between.