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.
In addition to dependencies on “actual start” vs simply “enabled to start”, the notation can be applied to flows triggered by optional user actions (US)…
… 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.
Bruce – I couldn’t agree more that these notions are not currently well-captured in BPMN. They’re also not well implemented by vendors, and I think this is a case where an improvement in the spec would be followed by improvements in the implementations… However, it is also an opportunity for Vendors to augment their implementations to anticipate this need (regardless of future notation, these kinds of time-related configuration details could be captured in “properties” below the visual level). Capturing these details below the visual level is hardly ideal, as it means you can’t see the semantics of the ordering without inspecting the implementation details, but it at least prepares the way for vendors to support a more explicit diagrammatic approach…
I would say there are a lot of scenarios where you really want to know “start” as the moment a user starts the activity. So, a time-based escalation might not need to happen if a user has already “started” the activity, but should happen if no user has started it yet… etc.
(like you, i don’t care what the specific diagram choices are – I’m not iconographer
scott
Scott,
You make a good point. A number of BPMS offerings capture the ‘started’ event for BAM but any triggered process actions are limited to BAM capabilities and are ‘off the map’ as far as the process model is concerned. The BPMN standard definitely has pushed BPMS vendors to add more event-triggered functionality, so what you suggest is not out of the question.
Bruce,
Good ideas as usual. Most of them are supported in standard BPDM, including notation (normative in the BPDM-based BPMN2 submission). Temporal constraints are the foundation of standard BPDM and BPDM-based BPMN 2, while the IOS BPMN 2 uses UML-style token flow and cannot support the level of expressiveness you’re looking for. See http://www.conradbock.org/#BPDM for more about BPDM.
> 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).
BPMN has some data flow capabilities, if you include the attributes. Standard BPDM and BPDM-based BPMN 2 has a full data flow model. IOS BPMN 2 is still working on theirs.
> 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.
> 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.
All the BPMN variants (standard BPMN, standard BPDM, BPDM-based BPMN 2, and IOS BPMN 2) distinguish the start of a process from the start of the first step in the process. Perhaps the first step in the process can be taken as “someone or something begins working on it”. It could be notated as attached to an activity with a new event symbol referring to the first step.
> 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.
The thin circle currently means “start” (before work actually begins) and I think modelers would assume it meant the start of the activity it is attached to, analogous to the error attached event already in BPMN. I’d reserve this notation for the SF/FS/SS semantic below. Perhaps the double border on any attached event could indicate it is non-aborting.
> It means that the activity (task or subprocess) cannot
> complete until the event occurs.
In standard BPDM and BPDM-based BPMN 2 this would be an attached end event with an incoming sequence flow. This establishes a temporal constraint that the activity cannot finish before the source of the sequence flow does. IOS BPMN 2 cannot support this with it’s current UML-style token semantics, see below.
> The Temporal Perspective: Expressing Temporal Constraints
> and Dependencies in Process Models can be found in the
> 2008 BPM and Workflow Handbook published by WfMC
Thanks for the citation, this is exactly the BPDM approach to process semantics (for example, see slide 4 and after in http://www.conradbock.org/bock.....cs-web.pdf). The IOS BPMN 2 submission, by contrast uses UML-style token flow, which is not expressive enough to capture these constraints, is too computational from a business perspective, and doesn’t support choreography semantics.
> 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).
> Finish-Finish (FF).
> Start-Finish (SF).
> Finish-Start(FS)
BPDM can model all these, because BPDM sequence flows (“successions”) can specify an event on each end of the sequence flow. The notation (nonnormative in BPDM, normative in the BPDM-based BPMN 2 submission) is similar to yours, using the existing event symbols (and the additional ones for success and failure) attached to activities. IOS does not support these in either notation or semantics, and in semantic has a significant barrier due to its UML-style token semantics.
Conrad
Conrad,
If your goal was to get me to go back and re-read the BPDM submission, you’ve probably accomplished it. My recollection is the notation part was particularly unrevealing, so I may come back to ask you for page references, or even to say it in plain English.
–Bruce
The wishes for variations of “non-aborting attached events” reminds me of my Master thesis work in 1985 with something originally called PiP (Processes interfaced through ports), but that later was known as PPM (Process Port Model from Arne Sølvbergs IS group at the Norwegian Institute of Technology). We had the concept of a “free flow”, which essentially was a kind of sequence flow that could be sent without the activity terminating. A “free sequence flow” variant in BPMN would solve several of these wishes. In particular, it also would be useful to combine with conditional sequence flow to indicate things that “may happen”, or be triggered from the mother activity while the mother is still alive.
Bruce’s mentioning of temporal logic reminds me about Allen’s temporal interval relations which lists the 7 possible relationships between two activities time intervals; for an example see http://www.dcs.kcl.ac.uk/staff.....f/time.pdf
Steinar
[...] obviously a work in progress with some very rough edges. One major enhancement is my favorite wish list item, the non-aborting attached event. The proposal provides this for timer, message, conditional [...]
Bruce,
Here’s a draft of BPMN-S/BPDM that linking notation and metamodel:
http://doc.omg.org/bmi/08-09-07
(browse the metamodel at ftp://ftp.omg.org/pub/docs/bmi.....42002f.htm)
See Sections 7.6 (Process Model) and 7.9 (Interaction
Protocol). These sections can be read standalone from the
rest of the spec. See Figure 40 (Events and Successions)
regarding temporal constraints (these need to be updated to
the latest IOS notation for non-interrupting events).
Conrad