Signalling in BPMN

At the risk of raising the ire of those that want to avoid precise meaning in their process flow diagrams, I recommend a study of Anatoly Belychook's handy primer on the use of the signal event.

I would emphasise that the signal event allows the ultimate "late binding". You do not have to design the world process ... only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise ... Signal ... then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.

For those of us that look forward to the executable process, Signals also provide a simple communication method between parallel flows within the same pool and avoid the process designer having to think too much about implementation level stuff like writing data to a store somewhere.

see also

BPMN only part of the solution

Scott Francis takes up the pen in the the ongoing and tedious debate about BPMN ( enough, too much, too hard, too rigid, too imprecise ....) and makes the excellent point that "too many people think that BPM starts and stops with BPMN!".

With a very small set of symbols, BPMN allows a range of expression of process definition from a whiteboard-quality overview to the precision of a computer algorithm for calculating Pi. Even with a palette of 1007667 English words, it is very difficult to get the necessary precision for specifying a business process. Working on the basis of the average reader using only a small subset of those possible words (about 2000) it is clear that we need something more formal than text to get to commitment on what a process is or should be.

It would be really scary if those responsible for the operation of multimillion dollar enterprises can't take on the meaning of a set of symbols that can be put on a small wallchart.

The sad thing is that there is not a similar set of symbols that could be used to encapsulate other aspects of the business canvas so that discussions on whiteboards, or around coffee-bar napkins could be more enduring and useful communication of requirements.