Procesdynamics and true Dynamic Case Management (Part 3)

This update focuses on the differences between sequential and rule-driven process models from both perspectives. In the previous update, I argued why the rule-driven model on the right (now in blue — I love colors) is much more maintainable than the now yellow sequential process model on the left. In this update, I'll debunk a few misconceptions about the differences between these modeling approaches.

1. Aren't the models the same?

In the yellow sequential process model on the left, activity D comes after B. In the rule-driven process model on the right, the rule for activity D would state that activity B must be completed first. So what's the difference?

This is a crucial and fundamental distinction. In the right process model, it will never state that D follows B. Rules on activities never look at what has happened because a rule-driven process simply doesn’t care about the past. The rules focus on the information within the case and whether it’s complete enough to make a decision. This aligns with the familiar analogy of a navigation system: it doesn’t care where you've been but constantly reasons from the current situation: Given what I know about you (where you are) and your goal (where you want to go), this is the next step (turn right).

2. Aren’t they the same for the user?

Even if the process models are different, won't users experience them the same way? Whether the system is based on the left or right model, doesn't it behave the same?

Not true. In a rule-driven process model, unnecessary tasks are never performed, making the process feel far more personal. The sequential model must always follow a path with a minimum set of activities to complete, such as ACGH or ABDEJ. In an application based on the right model, we might be done after just one or two activities. For example, if the application becomes complete enough at a certain point, we could immediately issue a credit card or reject a subsidy request. The rules in the right model constantly check whether the goal has already been achieved. If so, we're done. If not, Blueriq reasons as follows: Given what I know about you now (the structured and unstructured information in the case) and your goal (the case objective), these are the actions you can take (activities that add the information needed to decide).

So the goal of such a process isn't to reach the endpoint but to make a decision.

3. The left model is easier to test

A common argument for sequential modeling is that it’s easier to test. Take a highlighter and walk through the model. If you've marked all paths, you've fully tested the model! But how do you do that with the model on the right?

This seems plausible at first. But will you really test every path? In the example, there are three paths on the left, while the right model seems to have many more. However, a sequential process model with 15 decision points (which isn’t that many) already results in 32,768 possible paths. Is it useful to test all of them? In 2020, scenario and persona testing proved much more efficient, combined with a strategy of short-cycle releases to quickly add value, implement changes, and continuously improve. The right model fits perfectly with this approach.

4. The right model is harder to learn

As an Academy Manager (and instructor of the Dynamic Case Management course), I happen to know the answer: No, it’s not harder to learn. Designing the left flowchart is only easy when there are very few activities. Modeling with a rule-driven process instead of a procedural one does require a mindset shift. It becomes much easier if you approach it with an open mind.* Just like transitioning from imperative programming to declarative modeling, it's mainly a matter of getting used to it.

I can immediately recognize students who find this transition challenging. On the first day of the course, they always ask, "How can I set the rule to make this activity always follow that one?" By day two, they've already moved past that mindset.

* "The mind is like a parachute; it does not work if it is not open."

An anonymous quote often attributed to (my musical hero) Frank Zappa, who frequently used it to explain his sometimes highly inaccessible music.

Want to read more? Check out part 1, part 2 part 4 and part 5.