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.
Dear Bruce:
Excellent summary and very thoughtful extensions.
AA–Control Flow Dominance in Process Modeling:
I was really irked by the “control flow dominance” in many process models which do not show (or show poorly) the flow of materials, people, signals and energy (have I left some other types) in physical processes.
BB–Object Flow NOT secondary:
I feel that control flow is important but NOT ALONE. I feel that UML Activity Diagrams and BPMN need major overhaul to combine and balance the representation of both the kinds of flows. And we have error flows and feedback to take care of. I invite you to take a look at
http://www.slideshare.net/putchavn/1-c-comprehensive-radical-process-representation-23sep13 and
http://www.slideshare.net/putchavn/true-feedback
and give your views.
CC–Tyranny of Tokens:
I found that the use of “Petri Net Imaginary Token Flow” for basic modeling is too counterintuitive and complicated. A simple block diagram showing the flow of inputs and outputs of every activity or process block would suffice. In such a block diagram, the control flow is implied in object flow but that may not be able to explain focus of control, concurrency, synchronization etc. We will live with it than to struggle with imaginary tokens.
DD–UML Activity Diagram & BPMN Reconciliation:
I want to know if there is any comparison and reconciliation of UML Activity Diagram and BPMN, particularly because they both are managed by OMG. I hope they would pick BPMN and discard Activity Diagrams (I wonder how it is still a part of UML 2.5 with so many errors, flaws and absurdities). UML should simply redirect users to BPMN as the only standard.
EE–Can we hope for minimal essential Process Model?
The next thing is that we need a minimum essential model which can be extended to include advanced modeling concepts and elements without discarding the core model or lot of rework on the core model.
Thanks and regards,
Putcha V. Narasimham (09 APR 14)
Thanks for the mention, Bruce! While there are important properties of Process Timeline that differentiate it from BPMN semantically (rather than just notationally), I agree with your basic premise that, irrespective of notation, BPM solutions have to accommodate drivers beyond what BPMN was designed to support.
The question of simplicity versus transparency is an interesting one, but all else being equal, simplicity will always win. If that weren’t the case, we’d all just be writing assembly code to support our processes (a scenario my programmer son would much welcome 🙂 and we could do away with all this BPM stuff altogether.
Thank you again for the opportunity to present at bpmNEXT. It was a great conference, and as you point out, a number of complex foundational were addressed. That’s what I call a good time. 🙂
Scott, Your preso at bpmNext was definitely thought-provoking. I think there are things that could be added to the Gantt to make the logic more transparent. No one’s talking about code — that’s the very opposite of transparency. For example you could make the finish-start links visible instead of implied in the timeline, and if they are conditional you could indicate that by labeling the links. Similarly, some way to distinguish a join (wait for multiple precursors) vs a discriminator (trigger on first to arrive). Stuff like that. The main point of my post was that standard BPMN engines can probably execute Gantt-based models. Although I didn’t say it in the post, they would need to support discriminator pattern (allowed with complex gateway).
Excellent ideas. We’ve discussed a few of these, and as you correctly point out, the discussion always revolves around the visual complexity of that much exposure versus the simplicity of the basic Gantt. (And to be fair some of those things, such as start conditions, are already in the UI, although I didn’t highlight them during my talk.) All I can say is: stay tuned. 🙂
Hi Bruce,
I am struggling to see how BPMN can be successfully used to define and model a truely ad-hoc activity within a case management environment. I understand that the BPMN pallet provides a parrallel multi event sub process but how would you model a process that has many of these with no distinct relationship between them?
One example of a situation would be a process where the start event is a member of the public attends an appointment, during that appointment there are 3 required sub process that have to be carried out in sequence. In BPMN that’s easy to model! However there are also 15 individual parallel multi event sub processes that could be invoked depending on what that member of the public tells you. The result of each process could invoke another sub process or result in the process being completed. The case worker has to use there instinct and experience to determine which sub process to invoke. How would this be modeled? For me, i was able to model this with CMMN successfully and in a way that BPMN couldn’t. But i still used BPMN to define the activities that take place within the sub process.
So i am not so certain, unless shown otherwise, that CMMN is dead, I can see a long and prosperous future….
As for gantt charts to define processes to the masses, i can kinda see the idea behind it but like you said it hides the logic and in my experience the logic is the part that the masses need to see and understand.
Jon,
Thanks for your comment. You are one of very few who understand the issue (even though you think you don’t). You are agreeing that maybe the semantics are there in BPMN, but the notation is lacking. And I totally agree with you on that. CMMN isn’t much better, but it does at least TRY to indicate the fact that a dependency exists between an activity and its predecessors by means of the connectors and diamonds on the edges. It would be better if it described best practice for labeling those so that the dependency relationship is clearer in the diagram, but I agree with you that purely as a notation, CMMN has some things I would like to see in BPMN. But the issue (now raging on BPTrends LinkedIn group) is whether those minor differences in notation are worth creating an entirely separate metamodel that has huge conceptual overlap with BPMN. I think better to extend the notation of BPMN to include case management rather than have a separate metamodel for case.
Bruce,
Thanks for the response,
I see no issue with extending BPMN to include elements which allow adaptive case management. It must be common sense to head down this route? After all, personally i cannot see how anyone can utilise CMMN effectively independently of BPMN. BPMN models will always underpin case management case management…
It will be fascinating to see where this leads to!