Last fall I published my wish list for a few additions to BPMN. Typically these came from my BPMN training where a student would ask, How would you do this in BPMN?... and the spec provided no good answer. One of them, alternative entry points to a process, was explicitly addressed in the BPMN 1.1 spec in January 2008 using event gateway. For another one, the non-aborting "attached" event, I proposed a workaround valid in BPMN 1.1, but wished for a simpler notation. The desired semantic was picked up as a good idea by the BPMN 2.0 submitters, but without an explicit notation. The third one, which I called semi-structured behavior, is still an unresolved issue. Here again I proposed a workaround in the original wish list, but also unsatisfactory from a notational standpoint.
My new wish list carries forward the two unresolved items from my original list with an explicit proposal for a notation, and relates them to a longstanding problem in BPM, the difference between a task in BPMN and a task in BPEL.
First, a fundamental principle: In BPMN, if you can't see it in the diagram it doesn't count for much. A lot of the BPMN 2.0 discussion has focused on XML serialization and on attributes that don't print in the diagram. Those things are necessary, but the notation is more important. It needs to be expressive, simple to draw, and semantically unambiguous.
A second key point: BPMN is really just about when activities occur in relation to each other, when they start, when they end, and what happens next. It doesn't have a lot to say about how (the data, the implementation), and just scratches the surface of who (pools and lanes). But there is ambiguity about what is meant by 'starting.' In BPMN an activity starts when it is enabled by incoming sequence flow. But to a business user, it starts when someone or something begins working on it.
So let's start with the 'task' problem. In BPMN it just means a simple activity, i.e. having no internal structure defined by the model. It could be a human task, an automated service, or sending/receiving a message. In BPEL, task refers specifically to a human task. Leaving aside the 'inline task' variant of the proposed BPEL4People, a BPEL activity does not directly perform a task. Instead the process creates a task in a task management service (external to the process), which reports task completion back to the process. That's because unlike an automated service, a human task is inherently stateful. The time when a task is assigned and made available in a performer worklist is not the same as the time when the performer begins working on it. This distinction is fundamental to human workflow, but ignored by BPMN.
With all this as background, let's get to my new wish list.
Wish item #1 is the non-aborting attached event. There is consensus on the value of the semantic; we just need a notation. I propose to use the start event notation (single thin circle) drawn attached to an activity for this purpose. No need to add shapes to the graphics library when there is a perfectly good one available. So for attached event, I propose thin circle means non-aborting and double circle means aborting. Any event trigger for which attached intermediate event is valid should support both aborting and non-aborting variants, e.g. timer, message, and error.
Wish item #2 is a new BPMN attached 'started' event that means "performer has begun work on this task." It is non-aborting, meaning it triggers a parallel thread on the exception flow without disabling the normal flow out of the activity when it completes. It applies naturally to human tasks (user task type), but I can imagine use cases for service and send as well.
Wish item #3 is another non-aborting attached event, 'user action.' It means during this activity the performer MAY throw this event, which again triggers a parallel thread on the exception flow.
Wish item #4 is a new event type, 'Enabled to finish'. Like attached compensation event, it is a special one, i.e. doesn't follow the normal rules. It has a sequence flow in and no sequence flow out. It means that the activity (task or subprocess) cannot complete until the event occurs. Yes, a workaround is available in BPMN 1.1 by wrapping the activity in a subprocess with a parallel path waiting for a Signal event. I'm proposing a simpler notation.
These items all relate to one of my original wish list topics, semi-structured processes, something BPMN today does not handle well. Even though BPMN is fundamentally about time ordering of activities, it adopts a very limited view of time ordering, just Finish-Start (FS) dependencies: Activity B is enabled to start when Activity A is finished. I'm not the first to notice this. Denis Gagne wrote a long treatise about BPMN's limited view of time dependencies several months back. (The Temporal Perspective: Expressing Temporal Constraints and Dependencies in Process Models can be found in the 2008 BPM and Workflow Handbook published by WfMC). And as long ago as 2005, on an OMG discussion thread, Derek Miers worried about
...the sorts of dependencies that could exist between the nodes ... most people only understand the "hard-start" condition (if this activity has finished, then the next one can start). While that might suit software programmers trying to build code, it doesn't readily reflect how the real world actually works.In a semi-structured process, such as described by a tool like Microsoft Project, FS is only one of several dependencies between activities. You also have:
- Start-Start (SS). Activity B is enabled to start when Activity A is started in the normal business sense, i.e. a performer has begun work on it.
- Finish-Finish (FF). Activity B is enabled to finish when Activity A is finished. Note this is not exactly the same as using a gateway to join A and B, since the behavior of an event attached to B would be very different.
- Start-Finish (SF). Activity B is enabled to finish when Activity A is started.
... or activities enabled to finish by optional user actions (UF). Note enabled to finish does not mean commanded to finish, which you can do with aborting Signal event. Enabled to finish essentially imposes a join condition on completion of the activity; both completion of the activity in the normal sense and arrival of sequence flow at the enable to finish event must occur before the activity is complete.
Combinations of these dependencies are possible as well. The particular trigger icons used here are not important, but I would love to see these notation semantics in BPMN 2.0.