SOA Fable: Do you wear a watch?

Most of us wear watches, and except for those who wear it as a piece of jewellary, we expect a service from this piece of equipment. And what is the unique service provided by this equipment? It lets us know what time it is! Wait, hang on. Aren't there enough service providers, providing this very service, around us? Well every car has a clock in it. every house has many clocks, every PC has a clock. Even every mobile phone, PDA, iPhone has a clock. Why do people wear watches, anyway?

What are your expectation as a consumer from a possible service telling you waht time it is?

Availability: Service must be available when consumer needs it.
If a consumer relies only on mobile phone and battery runs out. The service is not available when consumer may need it.

Reliability: Service response must be reliable and should not require double checking.
A consumer is not sure of the time shown by a clock at public place, he needs to double check it with another reliable source anyway.

Accessibility: Consumer can access the service whenever he needs it.
A clock in laptop in backpack is not easily accessible in a crowded commuter train.

Trust: Consumer trusts that service is backed up by accountability on part of a service provider. When it is a question of life and death, one can trust service provided by one's own piece of equipment to be accurate, reliable and available than a general purpose service. As a consumer one tend to trust no one but oneself as most accountable service provider.

This is a very important insight which helps one prepare a proper versioning policy.
Without that trust versioning schemes can be mis-used for creating specialized services.

In enterprises, since SOA is mandated, project owners will use services. But they will make sure that they get their own private version of a service. This is quite easy by getting a veto power over life cycle of a service and mis-using governance for this sake. Assume a service version 1 is in use. Second consumer wants to create another version, because it has additional needs. This version 2 is derived from version 1. Now first consumer wants an upgrade to his existing service. But he is not willing to accept service version 2 as base for its next version. He will find any execuse to make sure he gets a service version 1.1 rather than 3. This pattern will keep repeating. And soon there will be a lot of versions, changing only in second qualifier. So you will get, what I call parversion (parallel version) anti-pattern.


SOA governance must make sure it guards against this anti-pattern and creates appropriate policies and controls to minimize and eliminate its occurences. Morover governance must recognise that this is a symptom and root cause lies somewhere else.

Moral of the story: Consumer is willing to bend rules to get an acceptable, reliable, accessible and trustworthy service. Watch out for such rules violation and fix root cause.