To Model or Not to Model
Keith Swenson has another thought-provoking post on his blog regarding models. Effectively recapping a discussion from the latest BPM/Case conference, he notes that the presentations and research all seemed to start with a “model” as a working assumption:
Every presentation at the workshop dealt with modeling: (1) can CMMN model what is needed by ACM, (2) comparison of 5 different modeling approaches, (3) a way to model variants in process, (4) consistency checking of models, (5) modeling crisis scenarios with state charts, (6) using semantic web to compare models, (7) modeling based on speech acts, (8) more consistency checking within models, and (9) using viable system model for ACM.
It is not just this workshop. I have been seeing this everywhere. Lloyd Duggan gave a mini course on case management where he said that the difference is that BPM uses BPMN and case management uses CMMN. If you read the papers, you see statements like: “We needed to model, so we chose CMMN.” There are comparisons between approaches based on comparing how models are built. There is a build-in assumption that to do anything we start with a model.
I think he’s on to something. The presumption that everything should be modeled is nearly endemic in BPM and Case circles (though not universal, as Keith himself has long been a proponent of emergent process that wouldn’t start with a model, per se).
I think that there are some basic reasons for researchers (and BPM / Case experts) to lean on models:
- models can be objectively analyzed and examined and compared; they lend themselves to be studied in a way that non-explicitly defined models or processes do not.
- models are a convenient way of explaining the world, or a process, or what we’re analyzing. Even if we weren’t analyzing a model, we might create a model in retrospect to explain what we were analyzing…
And I think that unconscious bias explains a lot of it. Conferences are often spearheaded by folks who think about these things theoretically and conceptually rather than by folks who use BPM software and write BPM/Case solutions.
Another interesting question that Keith poses is the definition of “who” when we talk about models. End-users of software are not the primary benefits of models, for example – whether those models are BPMN, CMMN, DMN, or other models. The benefits accrue more directly to those who develop the solutions- the process developers or the software developers. As an example we discussed on his blog, likely Twitter developers have models that describe how Twitter works, but as users, we can leverage Twitter to get things done without drawing a model.
So, in a sense, whether a model adds a lot of value depends on whether you build solutions or just use them – are you a “developer” or a “user”. Whether you need to understand how the “machine” works, or just use the machine. If you’re in the former camp, a model may be a necessity. If you’re in the latter camp, knowing a model is a nice-to-have.
This shouldn’t really be a surprise – no one has expected doctors or lawyers are the average business user to crack open BPMN or CMMN or DMN modeling tools… And we shouldn’t expect the average person to want to build their own tools – typically the tool builders and the tool users are two different groups of people.