Trusting Services

If there is only one implementation of a service then trusting the service entails trusting the implementation entails trusting the supplier. Furthermore, if there is only one channel to access this implementation, then this also entails trusting all intermediaries.

Typically this is done by having a large trusted supplier with a reputable brand. IBM or EDS. Large suppliers have a valuable brand image to maintain, and therefore may be supposed to have too much at stake to allow any service to fail.

We can break into this loop in three places. Firstly, we may note the ability of some firms to decouple appearance from reality. Reputation is affected not by real failure but by the perception of failure.

Secondly, we may be able to decouple the implementation from the supplier, through some kind of guaranteed escrow. If the supplier cannot deliver the service with the specified level of quality, then we or someone else will immediately take over the implementation (together with all resources required, such as persistent data). We should expect the web service platforms to support this.

More importantly, we should be able to decouple the service from a single implementation. It might be stupid to rely on a business critical service if there is only one small supplier. But if there are lots of interchangeable suppliers offering equivalent services, the disappearance of
one supplier doesn't matter very much.

Thus web services allows us to shift from trusting a single source to trusting multiple sources (market or ecosystem). Without this step, the service-based business contains many dependencies, and the business process may seem critically vulnerable.

The process implications of this are twofold. Firstly, the SOA process should include some consideration of the appropriate number/diversity of implementations of a given process - and should certainly not assume that the design task is always to select a single best-possible implementation. Secondly, the enterprise model of an SOA solution should allow some visibility and management of the true dependencies and consequent risk involved, since multiple independent implementations of a given service will generally be expected to increase the overall availability and reduce the overall risk.


Updated 11 December 2013