Workflow patterns - so much more left undone

I have been following the progress of Dr. Wil van der Aalst in his efforts to create a patterns language for workflow processes, as you know if you've read my posts.  First, the workflow patterns were described, then a comprehensive comparison of different workflow systems with respect to the patterns, and most recently, the YAWL effort to create an open source workflow solution that encompasses all of the patterns.

What a teriffic thing this is!   YAWL implements all of the identified patterns... but the list is incomplete.

With no intent to criticize, I respectfully submit that the patterns identified are useful as atomic building blocks, in that they represent all of the patterns that exist at the Work Step level of abstraction (and somewhat at the Business Process level).  However, there are additional patterns at the Business Process level that are not identified (I can easily envision a few) and all of the patterns at the Business Unit level are completely absent.

What this means is that there's more work to be done.

For example, at the business unit level...

Just a reminder for folks who don't care to jump down to my earlier blog on multiple levels of abstraction in workflow... The business unit level of abstraction exists to show the collaboration between different business units (possibly within a company, possibly with units in other companies).  The diagram here is multi-threaded with the distinction between "context documents" which establish the context for a conversation, and "messages" which reference and require the existence of these context documents.  At the business unit level, we are not concerned with what goes on within a business unit.  However, a message from the unit may appear and may be sent to a partner, which can drive effects (that would be specified at the business process or work step levels).

So, one workflow pattern not included in the list would be a "rollback with penalties" pattern (my term).  In this pattern, a message arrives to a business unit that is currently in the midst of executing a workflow pathway... (the message arrives to the entire unit, not just to a point in the specific pathway).  This pattern exists if the message causes the workflow in process to roll back activities within the unit, run a special process to incur a penalty, and then potentially branch to a different business unit.

A good example would be: a customer commits to purchasing a passenger plane from AirBus.  Six months before delivery, AirBus has already constructed some parts, and is awaiting the arrival of other parts, the customer calls and cancels the order.  AirBus, according to its contract, needs to absorb the plane parts into other planes, and will inevitably charge a hefty fee for cancelling the order. 

Certainly logic of this nature is quite readily expressed in the YAWL language by combining a long series of atomic structures.  That is appropriate for the Work Step level of abstraction.  However, complete discussions can be held to deal with the implications of this kind of enterprise-level pattern completely seperate from the details of how it is implemented using Splits and Joins. 

This is part of the reason why the Gang of Four book on design patterns was not the end of the discussion on object oriented design patterns. It was, instead, the beginning.  In addition to numerous additional patterns at the detailed level of abstraction where the GoF book performed, a series of influential books appears in the following years detailing the patterns at different levels of abstraction (at the enterprise level, at the application messaging level, and at the detailed package level).

This is also the reason why the patterns work in workflow must now continue, to identify patterns at these additional levels of abstraction.