Monday, August 4, 2008

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.


Anonymous said...

Can't we evolve our business architecture as our business evolves?

While a simpler business architecture now might provide "a poorer footing for our IT architecture" surely thats only the case if we can't efficiently evolve our business architecture and our IT architecture in the future as our business changes?

Wouldn't the Open Group's position that the example - given the current state of the business - represents a single service be more likely to lead to simpler and cheaper IT environment?

Bill said...

We can indeed, in fact we must evolve our business architecture in the future as the business changes.

However it is important that we model our current business architecture accurately. There is a Sales function in the described scenario currently being performed by Joe.

The Sales function is probably in fact more complex and involved than the scenario makes out. For instance there may in fact be negotiation over the price that may occur.

This Sales function needs representation in the business architecture for the architecture to be accurate.

Mapping the architecture to an IT environment is a separate issue. For instance, in the given example there is no IT environment to speak of.

IT systems could in theory be introduced at a later time to support these business services if warranted.

It is also very likely that any IT systems introduced to support the Sales function would likely be very different from those supporting the Car Wash function.

The point is that modelling the business architecture with separate Sales and Car Wash business services doesn't necessarily lead to a more complex or more expensive IT environment.

wine production said...

Hi I liked your information is very interesting ... these blogs about such interesting topics and I think I should love to offer more of these items as excellent ... thanks for the post

Kevin Brown said...

Great! Really useful blog for visitors! You have really done the great job.Touchfreewash

Pitstop said...

Nice Blog! Hire Pitstop for Multi Brand Car Repair Car Service Car Wash in Bangalore Delhi Gurgaon.

Soniya David said...

Some really useful content here. I've been looking for something like this to help with a research piece I've been working on.
cash for car