One of the reasons that BPMN so quickly displaced BPEL in the BPM space is it had a graphical notation that exactly mirrored the semantic elements. What you see is what you get.  So whenBPMN 2.0 changed the acronym to Business Process Model and Notation, I stubbornly refused to acknowledge the “and”.  For me it was all about the notation.  The whole basis of Method and Style was making the process logic crystal clear from the diagram, so if some behavior was not captured in the notation, it didn’t count.  But now I am changing my tune.

At bpmNEXT last week, one presentation after the next kept reinforcing a thought that has been much on my mind lately: that many of BPMN’s supposed limitations – it can’t describe case management, for instance, or goal-directed behavior – are actually limitations of the notation, not of the semantic model.  And why is that important?  Because it means that a BPMS that can execute BPMN can execute those other behaviors as well.  You don’t need a special engine to do it.

At bpmNEXT, Scott Menter of BPLogix described using a Gantt chart to drive process automation – activity enablement by prerequisites rather than by explicit control flow.  His main argument was that the simplicity of the Gantt chart made the process easier for business users to understand, and to prove it he contrasted that with a nasty rat’s nest of a traditional flowchart.  Hmmmm.  Yes, the Gantt is cleaner to look at, but that’s because it hides the process logic. Not so, says Scott. You can select an activity in the Gantt and its predecessors are highlighted in the tool.  Sure, you can do that in the live tool, but not in a paper or pdf printout of the model.

And here was lesson number one:  There is an inherent tradeoff between simplicity and transparency.  BPMN notation is messy because it reveals the process logic clearly.  If you don’t need to visualize the flow logic, you could make a much simpler diagram.  That lesson was reinforced again in the Q&A following my own presentation, together with Stephan Fischli and Antonio Palumbo representing BPMessentials, on a structured interview wizard that automatically generates a properly structured BPMN model following Method and Style principles.  Someone commented that the text representation of the process in the wizard might be a better way to describe the process logic to a business person.  That was never our intention.  For us, the wizard was just a means to an end – the BPMN – but it reinforces the point: a flowchart is not always the most intuitive description of all process types for all users.

John Reynolds of IBM provided lesson number two. He gave a sneak peek at how IBM BPM will expand to include case management.  He presented it by introducing a new BPMN element – I think it’s called an ad-hoc task or case task – that can be instantiated at runtime either by a user or by an event plus a condition.  The notation has the dashed border of a BPMN event subprocess, plus a couple new markers.  Even if such a new extension element were needed, IBM’s implementation probably puts a bullet in the head of CMMN, but I actually think BPMN 2.0 has this already!  The non-interrupting Parallel Multiple event subprocess – yeah, it’s there, look it up, p. 245 – already has that behavior.  IBM’s new task type could be considered a “visual shortcut,” similar to a few others in BPMN 2.0, an alternative notation for a more complicated standard serialization.  The parallel events in this case are either Message, Signal, or Escalation (representing manual instantiation) for the trigger plus Conditional for the condition.  IBM’s notation is cleaner, but I believe standard BPMN 2.0 engines can already execute it.

However, when your process or case is represented by a bunch of free-floating ad-hoc tasks or event subprocesses, the logic that connects them is invisible in the diagram.  Like the Gantt chart, you need to either trace hyperlinks in a live tool, or somehow parse the BPMN XML, to understand it. But what if we could find a new graphical representation of the BPMN that reveals it more intuitively?  Keep BPMN as the semantic language, but provide an alternative, non-flowchart visual representation for certain process types.  This is really an intriguing idea.

The third lesson came from a presentation by Dominic Greenwood of Whitestein.  He mostly focused on intelligent agents, another recurring theme at bpmNEXT, but the purpose of those agents appears to be mostly the same as in Whitestein’s presentation last year: goal-driven process execution.  This is really important and exciting, and Whitestein is clearly the leader in this area.  They have a notation that represents goals and subgoals linked to standard BPMN process fragments, but what is missing from those diagram is the logic behind that linkage.  For me, the most interesting part of Whitestein is not intelligent agents – that seems like just an implementation style – but rather what is the language for modeling goal-directed processes?  How do you design them?

There is a common thread linking BPLogix, IBM, and Whitestein.  It’s the notion of independent BPMN process fragments assembled dynamically at runtime based on a combination events and conditions, ad-hoc user action, and some goal-seeking logic.  The control flow paradigm of conventional BPMN is great at revealing the process logic in the diagram, but it can’t describe these new behaviors.  The BPMN semantics still work, but the diagram does not.  We need new ways to visualize it; maybe Gantt is a good starting point.  And beyond that, how you go from goals to the specific events and conditions that enable the BPMN fragments is another vital area.  How do you model it?  How can you visualize it in a diagram?

It’s a lot to think about.