Ambiguity

All About

I think I am going to start a collection of items that tell me what services or service-orientation is all about. The words "all about" generally make me uncomfortable, especially when I see how many different things (sometimes even from the same source) that SOA is supposed to be "all about".

In the past week, Martin Fowler and David Ing have both posted material about some widely differing uses of the service-oriented tag. (For what it's worth, I think it's the Meridian David Ing, not the Systemic Business one.)

They both use the word ambiguity. I think contradiction would be a more accurate word for what Martin describes in his bliki.

I've heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it's independent of web standards, that it's asynchronous, that it's synchronous, that the synchronicity doesn't matter ...

Explanation

But the diversity of explanation is not always a sign of contradiction or ambiguity. One reason why there are many different accounts of SOA in circulation is that these accounts are performing at least four different tasks.

Explanation		Examples from David and Martin
Explaining purpose and value	What are services good for?	SOA as a BA execution vehicle
Explaining use	What can we do with services - by what process are the benefits achieved? What does SOA allow you to do?	Building integration points on to your application architecture to open up your data and processes Allowing systems to communicate over some form of standard structure
Explaining form	What does a service look like - what is its essential structure? What are the essential characteristics of a service architecture?	Services are like COM/CORBA components but with cross-vendor standards and/or run-time options around transports SOA is an architecture where applications disappear
Explaining source	Where do services come from - by what process are they made?	Exposing software through web services Using (mostly) asynchronous messaging to transfer documents

(These four types of explanation were described by Aristotle, and are known as the Four Causes.)

Black Box

The ambiguity doesn't come from the fact that there are these different ways of talking about services, nor that these ways of talking about services are imprecise or even contradictory. In some areas, a great deal of effort has gone into producing fairly detailed and reasonably consistent standards, for what that's worth.

The ambiguity comes from the fact that the relationships between these different ways of talking about services are not clear. How does this form relate to this use, and how does this use relate to this purpose? That's where the vagueness and hand-waving often appears.

At some point in the future, the relationships between purpose, use, form and source may cease to be uncertain and become stabilized. When this happens to a technology, it becomes what Bruno Latour calls a "black box" - it encapsulates a particular way of solving engineering problems. Until then, we are faced with creating these relationships afresh for each SOA opportunity.

That's where a good methodology scores - not just to provide guidance on what to do, but to provide guidance on how to reason about what to do.

Update July 2008

John Evdemon has posted a collection of "what is SOA all about" under the heading Moving the SOA Goalposts