The Service Oriented Car Wash

I recently had the pleasure of discovering that The Open Group have an SOA Working Group, the mission of which is "to develop and foster common understanding of SOA in order to facilitate alignment between the business and information technology communities." This is a very significant step in coming to a consensus on the definition of SOA in both the business and IT domains.

The group is putting together an SOA ontology, which will hopefully go a long way towards creating a standard definition for the main elements of SOA and their relationships to each other. The draft ontology in its current form makes reference to an example business scenario based on an imaginary car washing business. The scenario is outlined below.

"Joe has a one-man business. He stands on a street corner with a sponge, a bucket of water, and a sign saying "Car Wash $5". A customer drives up to him and asks him to wash the car. Joe asks the customer for five dollars. The customer gives him five dollars. Joe washes the car, then says, "That's all done now," and the customer drives away."

The Open Group at present states that this example identifies a single service, which embodies a single repeatable business activity performed by Joe - washing the car. The customer is identified as the service consumer. The customer "consumes" the service when he or she pays the five dollars for the car to be washed.

There are however some issues with this model. Firstly, the service identified in the model consists only of a single business activity. Services modelled this way are far too finely grained, thus resulting in low cohesion and high coupling between services. A business service represents an entire cohesive business function, which may contain many processes and activities.

Secondly, the service model completely omits the Sales function. Although we are looking at a one man business, there are two business functions here (each of which translate to a business service). There are two different processes at play here – Sell Car Wash, and Wash Car. The Sell Car Wash process involves two roles – the Customer and the Salesperson. The Wash Car process involves only one role – the Car Washer. Joe just happens to hold two roles – the Salesperson and Car Washer roles.

As the model as described by The Open Group consists only of one process, it is unclear as to whether their model follows an event driven paradigm. Modelling the business architecture around business services and events provides for a far more loosely coupled and maintainable business architecture than other approaches.

The example business scenario calls for a single end-to-end business process spanning two business services. This is best represented as two business processes separately defined, but connected via a single business event which we might call Sale Completed. This is the end event of the Sell Car Wash process and the begin event of the Wash Car process. This is illustrated in the EPC diagram below.


Modelling our services this way has our Car Wash service as a consumer of our Sales service. The customer is merely a participant in the Sales business service. He or she is not a service consumer.

Now although we could indeed model our business architecture as outlined by The Open Group, to do so would produce a Business Architecture with business processes spanning multiple business areas, thus having low cohesion. This would produce a more unstable business architecture description and provide a poorer footing for our IT architecture.