Tuesday, July 25, 2006

Using Services to give Process agility


There are an awful lot of pieces out there that are equating processes with agility, so I thought I'd come up with a simple example that shows how Contract First helps ensure a much greater degree of agility than just trying to do it just with process, and how process can get complex in a hurry.

So to demonstrate that I'm going to use the Burger Flippers guide to SOA. First off the Burger Flippers decide to model the processes using BPEL. Which I've lobbed on the left hand side here. Like all "good" BPEL techies the person has sat down and worked through the process front to back and kept adding in steps until the job was done (I've at least let them call a sub-process for Fries, but believe me when I say I've seen that done inline as well).

So here we have a nice linear process that runs through and delivers the wonder of high fat foods back to the customer.

The trouble is that the person doing the selling bit isn't the person doing the burger flipping so they begin to get confused and decide that they need to model this using BPMN, because Swim lanes will make it much easier.
So now they've made it much easier to see what everyone should be doing and the world of the Burger Flippers is a happy place.

Then a change in business strategy means that instead of making every burger on demand they are going to have a "bin" which will maintain an active stock level in order to get customers in and out as quickly as possible. The bin is therefore responsible for ensuring the stock level and making the order of the burger. So as they've already got the BPMN they elect to do what any good process person does... namely extend it.
So now we've got a nice complex BPMN diagram and we haven't even got to ordering drinks or having more than one type of burger!

Now if we'd of take a contract first approach and split the business up into its different domains, namely customer service, fries and burgers then we'd have had the following set of contracts.

Inside the first version of Burger Service we'd have had only one service to worry about, the flipper so any requests to Burger Service would have been passed directly through.
With the new version however we'd have added in a new service to manage the demand and the bin, but the external interface wouldn't have changed at all.

In this model each of the services would have its own, independent process models and the changes and optimisations in one, that don't impact the interface, wouldn't reflect on the others. You could still generate a single BPMN if you wanted, but a great deal of the flexibility comes from being able to view each of the different areas separate.

This was a very trivial example, but the BPMN diagram is already getting complex with all of the different sub-processes and links. By having to modify in this way it quickly becomes cluttered and we start relying on process to process links rather than service to service links.

Technorati Tags: , , , ,

2 comments:

Anonymous said...

You seem to be comparing apples and oranges here: the contract/services are at a much higher level than the more granular BPMN diagram. The contract doesn't actually state how that service is executed, only the external interfaces. That's fine for high-level process descriptions and choreography, but not enough to implement something.

Both types of models have their place.

Steve Jones said...

Which was the point I was clearly (badly) trying to get across in part. Service defines boundaries, process describes implementation. Having process without services is a bad idea(tm) as it has no explicit boundaries. Process is ONE (amoungst many) implementation or modelling languages within service boundaries.