
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.

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.

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.



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: SOA, BPEL, BPMN, Service and Process, Service Architecture
2 comments:
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.
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.
Post a Comment