Friday, April 11, 2008

Services Like Laundry

Just over a year ago, fed up with the over-use of the Lego brick metaphor, my colleague David Sprott proposed the laundry model of SOA (Explaining SOA to the Business). Antony Reynolds of Oracle quoted this in his blog today (The Laundry Model of SOA), which is what reminded me.

Both David and Antony talk about the contract basis of the laundry model.
  • I delegate something (in this case cleaning) to the laundry service.
  • Officially I don't care how it's done (although the term "dry cleaning" seems to indicate a preferred implementation).
  • The laundry service accepts some (limited) liability for any failure.
These are typical characteristics of pretty much any kind of service, more or less. But there is a particular characteristic of the laundry service I want to talk about.
  • I entrust the service with something (an asset) that belongs to me.
  • I expect the laundryman to be discrete. I do not want my dirty linen washed in public - in other words, I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to inquisitive journalists.
  • If something goes wrong with the service, then my asset is damaged. The potential liability is linked to the value of the asset, not to the value of the service. (If my dress suit is ruined, I am not going to be happy if I just get the cost of the cleaning reimbursed.)
  • I do not authorize the service provider to use the asset for his own purposes. (I do not expect the laundryman to borrow my suit for his daughter's wedding.)
These characteristics are common to many services. I do not expect my CRM provider to try and sell things to my customers, nor to allow identity thieves to access their information. (Indeed, the customer information may not belong to me either; it arguably belongs to the customers themselves, who have entrusted me with their information according to the same pattern.) I do not expect my ISP to read my email, or interpret my search history. (Perhaps I'm being naive about that.)

However, there are many services where this is not clearly agreed. Perhaps I get some cut-price service, and this is only economically viable because the service provider expects to be able to broadcast some advertising to me or my customers. But if I am careless with the small print on the contract, I may not have understood this aspect of the deal.

And there are many services where this simply doesn't apply. For example, information services often simply involve transferring information from the service provider to the consumer, while Software-as-a-Service may simply involve transferring functionality. Obviously there are trust issues here as well - I trust the BBC to provide accurate and balanced news, I trust my internet security provider to protect me from viruses, I trust Microsoft Excel to calculate my profits correctly - but these are not linked in quite the same way to specific assets.

So I think the laundry metaphor is a very useful one, but like any metaphor we must be careful not to push it too far. All services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

See also

Services Not All Like Laundry (July 2008)
Laundry as Intelligence (Oct 2008)
Understanding Business Services (November 2012)


Rajesh Raheja said...

Great article. I have mentioned yet another analogy using home construction that I have used successfully in the past.

Richard Veryard said...

Hi Rajesh. Your example is a good one, raising lots of issues about the way different types of service (delivering materials, working on the materials, certifying that the work satisfies building regulations) must be orchestrated. How do the electricians and the plumbers and the painters avoid getting in one another's way - do they talk directly to one another, or only via the general contractor?

Thanks for mentioning this post. For the sake of completeness, you might also want to look at the sequel Services Not All Like Laundry.

David Sprott said...

The post Explaining SOA to Business can be found at: