Different Ways of Thinking about Business Process Models
- April 7, 2014
- 0 Comments
I think kudos should go out to the folks who really put effort into thinking about innovations around business modeling. In fact, Bruce Silver wrote a post that does a pretty good job of capturing the development.
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.
This has been a point I’ve made many times when talking with ACM folks about solving case management problems with BPMN-oriented software. IBM showed off some excellent case management improvements to their product, but as far back as Lombardi Teamworks 4, we have been solving case management problems in the context of process. It always took a little creativity to model – potentially to even model a completely open-ended user-defined process – but it worked. (The new features will greatly reduce the required modeling creativity).
Perhaps part of the disconnect all along was that some are more familiar with BPMN as a notation than BPMS as a solution leveraging that notation.
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.
I’ve always wished for a “transparency layers” much like the old books that had transparencies for different layers of human biology- skin, muscular, internal organs, skeletal, etc. In BPM terms it might be “happy path”, then “with alternate paths”, then “system integration”, then “error handling”, for example… But some of the presentations provided just another perspective, rather than a different layer.
Of these “think different” presentations, I think the two most promising takes were Scott Mentor’s presentation of a Gantt chart / timeline view of process (BP Logix), and Whitestein’s goal-oriented modeling overlay on BPMN. But to be fair, I should call out IBM as well – John Reynolds’ presentation showed off a few simple extensions to BPMN that really exposed case management features and revealed how easily a BPMN engine can execute these new visual elements (I doubt any changes were required in the engine itself to support these ideas).
To focus on BP Logix, the point that Scott was really able to drive home was that they see process through a timeline-lens, which for some types of processes is really advantageous. In particular, processes with a fair amount of work that happens in parallel, where timelines matter, but might be a little looser than a direct activity-to-activity prerequisite. BP Logix includes some very interesting calculations on likelihood of activities being completed on time as well.
Some interesting questions were asked that sound problematic if a timeline view is your only view of the model – how do you handle multiple dependencies (can be shown visually in the model with highlighting), how are choices / gateways represented, or how loops are represented, or optional activities, etc.
But for me, the best part was just this alternate view of the world that in some cases will be really useful. It doesn’t negate the usefulness of a BPMN model – it enhances the value of such a model, if you can do both.
On the other hand, Whitestein’s goal-oriented modeling isn’t so much a different lens as a layer on top of the typical BPMN modeling. I haven’t worked with the product but it has a “feel” of combining decision modeling (around goals) and process modeling (around execution), that could simplify or formalize things that happen just above the process layer in a business implementation.
Another session that touched on this is Gero Decker’s presentation from Signavio – illustrating how they’re including Enterprise Architecture modeling into their SaaS modeling offering. Its an interesting extension, given their focus on modeling in general, and a play to become a wider modeling offering appealing to additional sets of users, or to users who do both EA and BPM.
Bruce wraps with these thoughts:
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 feels to me like the innovation around views and modeling is happening, partly because the BPMN spec has sat still long enough for people to fully develop alternate ideas that expose representative value, without worrying about winning in a committee of spec writers. While BPMN has become the standard, widely implemented, it isn’t sucking all of the oxygen out of the room either.