During the presentations at the Workshop on Adaptive Case Management (ACM) on Monday, there was a growing question about the models: Not just how models should be constructed, but whether we should be using models at all. These ended up forming a major discussion at the end of the day, and even into the rest of the week, culminating with the final keynote questioning our obsession with models in BPM. This is my take on the main positions in the debate.
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.
Questioning The Value of Modeling
The assumption is a blind spot: If it is true that modeling is effective, we should be able to show that through the use of a model we allow the user to get more done than when a model is not used. However, this question is rarely, if ever, asked. The second presentation compared the expressibility of various modeling techniques, however the actual advantage of modeling was never demonstrated. Almost no research is done comparing cases where a model is used, to a control case where a model is not used.
A Convenient Crutch
One might suspect that models are foremost in research, because they are quite a bit easier to study than real office behavior. Interview some people, make a model, and then put the model under a microscope. You can experiment with the model, find the ways that it fails. Two of the talks were about ways to find inconsistencies within a given model, to avoid deadlock type situations in the model. However, these deadlocks have nothing to do with the behavior of the actual workers in the office, it is simply a flaw in the model.
Through all of this, we lose sight of our real goal: making workers more effective. We really do need to do controlled studies: consider a set of offices, measure the performance, then give one set of offices use the ACM technique, while another set continues operating manually. Measure the increase in performance. We need to keep our eyes on actual knowledge workers productivity, and not get distracted by our attractive technical developments.
Who is Modeling?
We need to be clear about who is modeling. When talking of an ACM system, we all know that such a system is built from software. That software might be modeled. The issue is not whether the programmer of the system uses a model to make the software. That would be a question of the use of modeling in software development — a completely separate issue from the use of modeling in ACM by the knowledge workers. When an approach to ACM is presented as “providing modeling” we know that means modeling by the knowledge worker, or by someone close to the knowledge worker, as part of the knowledge work. When we talk about modeling being “part of” the ACM System, it means that modeling capability is presented as part of the features for the intended users of the system — not the programmers who make the system. I know these lines are blurred somewhat in some systems that can be “customized” by programmer. Still, lets keep this modeling discussion about those models created by the knowledge workers themselves. For example, a law office, we consider the modeling done by lawyers, even when only 10% of the lawyers actually make models, but lets not consider modeling done by someone who only does modeling,a nd never does any law.
An Example of a Non-modeling Approach
One of the best examples of a system that supports extensive, complex knowledge work is Git Hub. Software product designers and programmers have a very complex, knowledge intensive task to accomplish. Git Hub offers a simple, elegant way to coordinate this work:
- issues can be logged by anyone at any time. The issue describes the problem or the work to be done.
- team members can discuss any issue using a chain of comments, either asking questions of clarification, or stating positions.
- issues can be tagged and classified in different categories, such as bug, feature, enhancement, urgent, ignore, and others.
- issues can be grouped into milestones, which have an intended release date.
- programmers can focus on all the issues in a milestone, marking off issues as the work implied by the issue is completed. Everyone on the team can be aware of the status of the milestone.
- Milestones can be adjusted and replanned by moving issues in and out of the molestone.
That is it. Simple and effective. Used effectively by thousands of projects today. There is no modeling capability. There is no automation of the knowledge worker tasks. There is no need for a modeling language at all. And it works.
Another example I have used in the past is Easy Chair, which is a system used to collect, review, and judge papers submitted to a conference. This system is used by hundreds if not thousands of conferences every year, and most academics are familiar with it. It allows knowledge workers to get their work done — very effectively by all accounts — but it offers no modeling capabilities at all.
Both of these are software systems, so one might assume that the programmers who developed them used models. We don’t care. This discussion is not about modeling in software engineering, but modeling by the knowledge worker as part of doing knowledge work.
Everything is a Model
One particular rat hole that the discussion kept going down is the position that anything you do to customize is a model. For example, in Git Hub you can specify the labels that are used for categorization: I might have 5 varying levels of urgency, while someone else might only have three. In Easy Chair you can decide whether abstracts can be sent in ahead of the submission, or whether the full submission must be given at once. These changes effect the way that the users must behave with the system.
In some purist technical way, any setting that one person makes effecting another is modeling. These trivial mechanisms are not what most people mean by modeling. I think we know by modeling, we mean some flexible, abstract, general purpose representation of the work being done. When we say the work can be modeled, we don’t mean that there is a check-box somewhere that directs work differently. Or a label.
The true gray-area is that of checklists. A checklist is a general purpose representation of a collection of tasks. One might argue that this is modeling. For example, grouping the issues into a milestone in Git Hub, is modeling the work to be done for that milestone. No! I am not buying it. The difficulty in modeling has to do with a certain level of abstraction. Checklists are concrete. If we want to discuss the merits of modeling, we must be talking of models that are more abstract than a checklist.
For What Purpose?
My stated position was that we must consider and measure the benefit of a model. WE can not assume that it offers a benefit, and as you can see there are good examples of knowledge work systems that require no modeling by the knowledge workers. They offer no possibility for it, and there does not appear to be any problem.
Models could be useful for a purpose. For example, a model of the work can be very important in predictive analysis, where you use patterns of behavior together with emerging workload, to predict how many resources you will need. A call center wants to make sure they have enough knowledge workers available on days when load is expected to peak. Presentation #5 was about emergency response, and having a model to simulate potential scenarios before an emergency can be critical. It can also be useful to take inputs and warn about potential problems as the emergency is unfolding. A model can be used in numerous simulation situations. Some of these models would be implemented by a specialist who does only models: for example the person who makes a model to predict problems in a flood, might not be an actual emergency rescue worker. The question still remains whether a system to support emergency responders needs modeling capabilities.
If we include modeling in an ACM System, then we should be very clear what the purpose and goal of such modeling is. We should then not only show that it achieves this goal, but that also, as a result of the modeling, the work of the actual knowledge workers is made more effective.
The rest of BPM as well
Outside of the workshop, we saw a lot of the same sentiment: we are too hung up on modeling. Far too many papers assume modeling, and then study the model. Studies of model correctness constraints are about assuring that certain modeling rules are not broken — not necessarily whether the business that uses the model improves from it.
Leon Osterweil, a hero in the 1990s in the software process model domain, whose work I have cited many times, attended the conference and participated on a panel about agile BPM. However, it is somewhat ironic and humbling to realize that in the software development space, real progress has been made not by developing an elaborate executable process model, but instead by going the other way to agile approaches, such as SCRUM. SCUM has a method to be sure: two week sprints, daily stand-up meetings, visible status, develop test before developing the code, but these are less like automated processes, and more like simple patterns of interactions on which programmers manually create the software. Git Hub does a brilliant job of coordinating developers work, without having any readily apparent enforcement of something you might call a process model.
Marlon Dumas gave the closing keynote for the BPM Conference including a history of the BPM field from 1990 to date. He also decried the focus we give on models: measuring models, improving models, etc. to the exclusion of knowing whether we are actually creating the business. He showed how at different times we moved from studying process, to studying models, to studying analytics. He urged a change in culture for the papers next year and beyond. Modeling and analytics are tools to use to improve a business process, but they are not themselves the business process. The model should not be the focus of the research. Instead, we should focus on returning to study the actual business process, the actual work being done, and show how we can make the business more effective, possibly with the use of models.
No Model is a Good Model
I think a whole lot more can be done to support knowledge workers without the need for modeling. We need to study those. Modeling might be useful in situations, but we should be clear about the purpose of that modeling, and we should measure whether the model is actually effective in improving the work of knowledge workers. We should not be blinded by the assumption that modeling is a necessary part of ACM.
Thinking Matters 
Keith – in your post above, the implication seems to be that the word “model” for purposes of this discussion is only something formalized by a spec and intended to represent implementation of a process (or case?)… is that an accurate read?
(in other words, mental models or models in a more general way, that explain complex subjects with more simple language, wouldn’t necessarily qualify based on the above definition… unless they’re leveraging a modeling language like CMMN or DMN or BPMN).
Regardless of the above, I’d caution not to throw the baby out with the bathwater. It has long been a critique from those of us doing implementation work in the field that people are too focused on the models – and the code! – and not enough focused on the business outcomes and the reason we’re all working on something in BPM. You can see signs of this tension on the BPM.com boards from time to time. Easy for us to theorize about models – harder to theorize about spaghetti code 🙂 Models lend themselves to analysis – but it is easy to lose sight of whether that analysis is on target with respect to the original goals.
But models do have value – the power to explain something that is complicated, in terms that are not, is always going to be of value. Github for example is great for developers- but lousy for a business stakeholder to get a sense for whether your development process is supporting their needs until after you build the software… i.e., some tools are great for people who start with common understanding/skills/etc. but not so great for a heterogenous group. Food for thought.
Hi Scott, I think you have it: a model is something created to represent something else, and is necessarily simpler than the real thing. A mental model is something else.
As you see from the ending I agree models have power, but we should be explicit about what the purpose of a model is, and measure that it indeed achieves a benefit. Models themselves are not the problem, instead the untested ASSUMPTION is the problem.
One part of the discussion I did not get the chance to include is that we discussed that if a good programmer needs to learn 20K lines of code quickly, then an object model can be a real help in learning the code. This explicit benefit of a model is measurable.
I must respond to the implication that the approach in Git Hub works only because programmers are somehow more capable (in some way) than business people. There are many other examples. Twitter is an excellent example of a very simple system from which emerges very sophisticated responses. I also saw many attempts to do what Twitter does which offered sophisticated mechanisms for linking — but they simply made bad assumptions about what was needed. If sophisticated process models would make the job easier, then I would expect programmers to be the MOST capable to use them. The fact that Git Hub achieves good results without process models is not a testament to the exceptional capabilities of the programmer, but rather the inappropriateness that a process model would bring to the situation.
Many systems are “over engineered” in this way. Designers wrongly assume that thing need to be automated to be easy. But in many cases, the opposite is true: a simple manual system can often be far easier to use than a system that is automated in a misguided attempt to make it easier to use. I am a fan of “appropriate technology.” The easiest approach often involves avoiding things that designers do to make something easy.
hm. I didn’t say “only” w.r.t. Github but when it comes to reading writing merging and managing code, programmers are more capable than non-programmers. when it comes to business, well, the shoe is on the other foot usually. We use Github, and we also have processes defined (and modeled) for building and releasing code. Those processes just aren’t defined in Github because it offers no modeling/automation for that.
The point is that the requirements and the users are aligned on tooling. But for many things that businesses want done, the users and the tools are not aligned. A model is one way to have a representation that they both can understand, and that then the tool builders can build.
While twitter didn’t use something like BPMN / etc. it wouldn’t surprise me if they had object models and flow diagrams and story boards to think through the behavior. I could talk to one of my friends who was there at the early days and has a single letter handle and find out.
Incidentally you mentioned a key aspect of automation – better to do things manually to be sure that you automate the right things – the repetitive things, etc. And it helps avoid wasting effort automating the wrong things. While you’ve pointed the finger at designers, there are great examples of this among programmers as well – optimizing for performance before they’ve demonstrated that a performance problem exists. future proofing rather than solving the present problem, etc. We all have our flaws!
oh, and i should have stated that i agree that the untested assumption should be tested, if it isn’t being tested by the academics who are currently testing all kinds of modeling. Meanwhile folks like you and i should just keep using the tech we think is appropriate.
You are falling down the same rat-holes that many such discussions do.
(1) Of course your builds are automated! That is a predictable, repeatable, automatable task. This is NOT a knowledge worker task. It is not needed in Git Hub because there are literally dozens of tools to automate builds, and because Git Hub does not want to be in the business of doing builds. Lots of other things can be automated. Hopefully you recognize the difference between routine and unpredictable work.
(2) The second rat-hole was when you dived into what the Twitter programmers used to design their product. Of course the software engineers used models, because that is a well known technique which programmers spend hundreds of hours each to learn to do. You can also bet that the programmers behind Git Hub also used models to help implement the issue tracking system. That is the job of implementing the system, not using the system. The point is that in Twitter and Git Hub issue tracking, neither of them require (or even allow) the intended user of the system to model their work.
We fall into these rat-holes because of the ambiguity of language. Saying “you don’t need models” is very problematic because the “you” in that phrase is very ambiguous. We don’t have a crisp definition who really we are speaking about. I might mean the “banker” who is using the account management system at the moment (who has absolutely no need to model a process), but others might think I am referring to the company that is producing the software (which readily uses such models). We have gotten to the point were we distinguish “business user” from “IT user” but even that is too ambiguous. Some business users create elaborate spreadsheets with sophisticated formulas, while some others never advance beyond entering a number into a cell. There is a very wide range of skills and needs. The “process analyst” is neither in IT, nor really a business user. One output of the workshop was to consider identifying and naming specific personae for use in discussing the knowledge worker scenarios.
It all come back to the same thing: if we say a model is needed, we should be clear about what the model is to be used for, what benefit it is to produce, and we should actually measure that it does so.
I think there are some assumptions you’re reading into my response- which means i didn’t explain myself clearly.
1) with respect to build process, i didn’t mean automation. I meant a process for all the stuff that isn’t automated. “hopefully” i do indeed recognize the difference between routine and unpredictable work, given all the conversations we’ve had on the subject, and “hopefully” you would know i do 😉
2) My thought re: twitter is that twitter programmers are analogous to the people building business processes and applications that support them. if models are useful to twitter programmers, maybe they are also useful to people building business processes. (and maybe they are less useful to twitter users and business process users/operators)
3) agreed language is ambiguous. I wasn’t trying to pick sides in the argument, just wanted to understand your post and the discussion you were relating better. “not throwing the baby out with the bathwater” wasn’t me taking sides, just me acknowledging there are cases that will be argued well from either side – and there are theoretical discussions that are interesting, but then there are actual implementations that are interesting.
Keith, I fully agree (well: as always; thanks for your profound thoughts)
We do not need new modelling languages allowing to express better how knowledge worker get things done. We just need a different methodology which breaks with a simple rule: since many decades BPMS / WfMS are based on the principle that the build-time / design-time defines how you can act at run-time: You need to model first before you can execute. It’s just a requirement. If you follow this approach you need to improve the modeling language if want to extend the capabilities of your execution environment.
By the way, we all know what happens when a business analyst models how knowledge worker should work…
If you break this rule (requiring fully redesigned BPMS), “run-time first” is possible as well. It is an additional option which opens the door for a different methodology as well: start bottom-up instead of top-down. Use similar projects as a starting point. Copy & adapt your tasks. Just dot it!
Even on the run-time level we can talk about a process model: just a model how one case is done; a very simplified model like the checklists Keith mentioned long time ago. If you can refine tasks into sub-tasks, if you might use simple dependencies between tasks like in Gantt charts, if you can plan optional tasks and milestone, you have everything you need. This “task plan” is a model as well. Every project plan is a model (though it’s neither BPMN2 nor CMMN).
However, “build-time first” and “run-time first” are two extreme approaches (well you need to realize that “build-time first” is an extreme approach used since decades). Even in the example how software development is managed (I am from a software company building ECM & BPM software where we have broken the build-time first rule in our BPM software) with Git Hub, Jira, Mantis or whatever, there are some predefined rules or process models behind all the flexibility of managing tasks & cases: every case follows a simple statechart model of analyzing issues, implementing/fixing them, testing, documentation and finally shipping all together. There is a simple predefined process model on build-time level, but just defining the constraints /rules / phases.
Thus, a hybrid approach is needed: predefine as much as needed but as less as possible; use a BPMS which allow to combine build-time and run-time definitions of processes and tasks; do not fear to start bottom-up.
Terrific discussion of the modeling and business technology.
And the comment that we need to learn a lot more about knowledge workers and the support they need is especially important.
I suggest in this context that the research in economics on the question of “tacit knowledge” is relevant. Regarding tacit knowledge, it’s impossible and unnecessary to capture in software models the richness and complexity of even simple human tasks. We must rely on the capabilities of human actors — and hopefully always do so.
Nevertheless, the fact that modeling is sometimes expensive and/or unnecessary shouldn’t imply that the model doesn’t exist. Even with the simplicity of Github there is a tacit model (e.g. “narrative discussion chain”) which exists as part of the social capital of Github participants.
We sometimes treat “Business-Models-Instantiated-In-Software” as reified away from mere language. However, an argument can be made that modeling is a specialized form of language and that a model-is-a-model-is-a-model, regardless of the formalism of a process model or the informality of discourse around a boardroom table.
From this language-centric perspective, we can get rid of religious wars around modeling versus coding and agile versus waterfall and acknowledge that there are pragmatic reasons to choose a given approach.
Pragmatism works as long as one acknowledges that when one is building technology, one is by definition instantiating a model, even if it’s only in one’s head. For business’ though sake, I believe that the more explicit the better. Finally, technology is making it easier to be explicit.
Good comment. Many people view “tacit knowledge” as a bad thing. I guess an organization that wanted replaceable people would never like the idea that there are people who have knowledge in their heads. That sound, however, like a very shortsighted company. The reality is that people are good at learning, and good at putting things together in creative ways for unique situations.
A model is an expression, however it is also a specialized skill which can only be “spoken” by a few people (and probably understood by a few more). For some tacit knowledge cases, it will be easier for both the speaker and the listener to simply use their own mother tongue. It all lies on a spectrum so we need to be careful about generalizations.
Keith, very nice characterization of (process) modeling as something which only “spoken or understood” by a few people. As you say, for processes where tacit knowledge is paramount, just using one’s “mother tongue” (e.g. English or Hindu or Chinese etc.) is simpler.
Interesting now that the original problem is now defined as one concerning language. A concern I have is that mother tongues or vernaculars (considered most broadly to include social practices and mores of various professions, trades, institutions, workplaces etc.) can also be prisons of conventional thinking. And conventional thinking is not likely to be a good defense against disruption.