SOA Fable: Thermometerman

This story is courtesy James Gardner. The story points out that how a shared service provider sticks to service level agreements (SLA) rather than service consumer's satisfaction with service. The SLA often define objective criteria to measure some attribute of service. And attributes covered by SLA do not essentially imply the satisfaction of consumer. Providing personalised consumer satisfaction, to a large consumer base is considered uneconomic. So service provider sticks to some objective criteria acceptable to large group of consumers and tries to make it a golden mean between service consumer's satisfaction and economy for service provider.

The reason for doing so is economical. Service providers segment their service consumers and for each segment the provider decides which service attributes that segment is sensitive to. Service provider then goes on to optimise those attributes alone for that segment.

In doing this segmentation however, service providers may lump a diverse group of consumers with diverse aspirations, motivations, intentions and temperament, together. The service attributes deemed important for entire group may be sum total of service attributes important to these smaller groups. But these smaller groups may like some other attributes to be addressed which may be missed by the segmentation. So instead of achieving of golden mean between economy and satisfaction it may lead to widespread consumer dissatisfaction.

The alternative to this is to allow consumer to choose which service attributes are important to them. In essence allow service consumer to define their SLA, even on the fly. The availability of such mass customisation ability is the moral of this story.

In an SOA, the service provider can allow consumer to choose the attribute of service which consumer wants optimised, and even allow this optimisation to take place in every interaction if it makes sense. Some combination of attributes are difficult/uneconomical to achieve.

e.g. Service availability and service currency can both not be made 100% at the same time When you provide 100% service availability, you may have to sacrifice currency a little and vice-versa.

Allowing such mass customisation ability might mean more work for service provider. Provider may have to provide different implementations to satisfy different combination of service attributes. Provider may charge differently for each of the combination as well to take care of economics. Whether this is done offline via service contracts or online via an architectural layer doing service attribute brokering, should be left to provider.