I think it's time to highlight the shortcomings of DMN and decision models. These shortcomings have a big impact on business agility, productivity, and programmer workload. In this discussion, I identify six major shortcomings.

I fully recognize all the benefits DMN and decision models have provided, so I intend this analysis to be constructive. Of course, if you're a glass-half-empty kind of person, you'll perceive big holes in current rule platforms. If you're a glass-half-full kind of person, however, you'll perceive huge opportunities yet to be seized.

A case study that has been widely discussed in standardization circles is EU-Rent. You might have run across it. I'll use EU-Rent in several places below to identify current shortcomings of DMN and decision models.[1]

Shortcoming 1. Lack of Business Semantics

You're kidding yourself if you think you can do any kind of serious rule work — work that is effective and reusable — without a structured business vocabulary and glossary. A central idea of business rules is to make the logic accessible to non-programmers. How can you do that without incorporating explicit business semantics?!

Figure 1 presents a partial concept model diagram for EU-Rent. A concept model is the basis for a glossary — a structured business vocabulary. The structure in Figure 1 is sufficient for supporting the set of EU-Rent behavioral rules in Table 1 later.[2]

Figure 1. Partial Concept Model Diagram for EU-Rent

Shortcoming 2. Lack of Support for Behavioral Rules

Supporting EU-Rent properly also requires a very healthy dose of behavioral rules. Behavioral rules are ones that can be violated or broken. They govern the conduct of on-going activity and so are critical to people, organizations, and business activity. Very roughly, you can think of behavioral rules as business constraints. They also have huge impact for data quality.[3] DMN and decision models do not support behavioral rules.

Table 1 provides a sampler of behavioral rules from EU-Rent. EU-Rent is in no way unique or atypical in depending on behavioral rules. Also, as I explain below, behavioral rules are key to addressing additional shortcomings in DMN and decision models.

Table 1. Sampler of EU-Rent Behavioral Rules

Shortcoming 3. Lack of Support for Flash Points

Flash points are events where a behavioral rule could potentially be violated or needs to be evaluated. In general, every behavioral business rule produces at least two flash points[4] (but usually not more than 4–5). Behavioral business rules that are specific to an individual event do exist, but they represent a small minority.

Consider the following EU-Rent example from Table 1.

Behavioral Business Rule: The reservation holder of a points reservation must be a club member.

For this rule there are four flash points, as follows:

1. A points reservation is created.


2. The person holding a points reservation is changed.


3. The reservation holder of a points reservation ceases to be a club member.


4. An existing reservation is converted into a points reservation.

Unless the rule is evaluated at all four flash points, some violations will be missed. Such omissions have immediate consequences for quality of service, as well as for quality of data. Indeed, such omissions are root causes, often quite obscure in traditional schemes, for shortcomings in both regards.

Since DMN and decision models do not recognize or support either behavioral rules or flash points, the application systems that use DMN and decision models must evaluate behavioral rules and handle flash points themselves. That creates huge programmer workload. Offloading that work to a rule platform would yield a huge boost in productivity.

With regard to process models, DMN and decision models force modelers and software developers to indicate explicitly when to evaluate all rules. Rule platforms have to be told when to evaluate rules, often at a point in a BPMN model.

Now to be clear, being able to specify when to evaluate certain sets of decision rules (i.e., DMN-style decision tables) is actually sometimes a good thing. Indeed, for many decision problems, waiting as long as possible for data to pile up often produces optimal results.[5] In those cases, explicitly invoking a decision service at a point in a process model is probably the best way to indicate how long the decision can be delayed.

You definitely don't want to wait, however, to evaluate most behavioral rules because defects will only compound themselves downstream. Errors are multiplicative. Generally, behavioral rules are a real-time problem! And obviously the world is increasingly real-time.

Ever wonder why legacy systems so often produce such inconsistent results? One big reason is because programmers are coding and managing behavioral rules and flash points. To me, that's not a very smart way to build business systems. It also doesn't work very well for addressing sentiment and human discretion, another important real-time issue.

Shortcoming 4. Lack of an Independent Watcher

So, what is the solution for real-time support of behavioral rules and flash points?

The key is monitoring events in real-time, independently from all processes. For that you need what I call a watcher, like a referee in a game of soccer, only automated.[6] This watcher should be completely non-partisan, interested only in detection of violations and enforcement of behavioral rules at flash points.

What capabilities does the watcher provide?[7]

1. Monitor events apart from processes to detect flash points.


2. Evaluate behavioral business rules based on these flash points.

To achieve that, a rules platform needs to maintain continuous, unbroken awareness of state — yet another shortcoming in DMN and decision models.

Shortcoming 5. Lack of Awareness of State

DMN and decision models have no awareness of state. No watcher is ever on duty.

The watcher must know comprehensively what is happening as 100s, 1000s, or more events are happening almost simultaneously across dozens, 100s, or more processes, as well as all unmodeled, ad hoc interactions. Trying to synchronize events using only process models is hopeless — or at least hopelessly complex.

The issue of state actually brings us full circle to the first shortcoming discussed above. The best way to handle business state is by supporting business semantics (a concept model). Let's be very clear here. By 'state' I mean business state — not software state.

What are the implications for programmer workload? What work would the rule platform be off-loading?

DMN's dependence on process models subtly encourages a procedural view of the business, one where business solution and system model are easily confused. For example, I believe you should never see discussion of synchronizing processes in analyzing and specifying rules. That's a system concern. But you do see such discussion (regularly and at length) in DMN circles.[8]

Shortcoming 6. Lack of Support for Natural Language

DMN and decision models offer no support for structured natural-language expression of rules.[9] Behavioral rules, however, are usually one of a kind. They just don't fit naturally into decision tables.

Policy manuals, legal documents, science and engineering documents, etc. generally aren't expressed as decision tables. (And they never will be.) Sometimes decision tables can be retrofitted in useful ways for implementation purposes, but even then it's only partial treatment. What about all the remaining rules? Programmer workload!

In a day and age when you can Google just about anything, lack of natural-language support[10] is simply not going to fly.

Bottom Line

As I stated up-front in this discussion, DMN and decision models have permitted significant progress with practical use of rules. Their crucial shortcomings, however, must also be recognized. This discussion has identified six major shortcomings. Rule platforms providing suitable resolutions would achieve the following:

• Reduced programmer workload. Modelers and coders would not need to indicate when and how to evaluate behavioral business rules.


• Higher business fidelity. Correctness of (business) state would be maintained in real time across all relevant flash points, dramatically improving not only business service but also data quality.


• More responsive systems. Responses to violations of behavioral rules would be selectively invoked based on human discretion, sentiment, and common sense, providing the smart touches today's digital systems often lack.

The bottom line is a far better partnership overall between humans and machines.

In many ways, DMN and decision models have focused on the easiest part of the rules space — decision tables.[11] And they have treated that space as a semantics-free zone. So much more can and should be done.

References

[1] Ronald G. Ross, Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business (2^nd ed), (2020), Appendix 3.

[2] Refer to Business Knowledge Blueprints, Appendix 3 for definitions.

[3] Ronald G. Ross, "What Else Should Rule Platforms Be Doing? Eliminating Programmer Workload," Business Rules Journal, Vol. 23, No. 02, (Feb. 2022), http://www.brcommunity.com/a2022/c087.html

[4] An example of a behavioral rule with just two flash points is presented in Ross, (Feb. 2022).

[5] For example, in matching problems where one set of things (e.g., rental requests) is to be matched with a set of resources (e.g., available apartments) with the best possible pairing.

[6] For more about the watcher, refer to Ross, (Feb. 2022).

[7] Ideally, the watcher would do both tasks, although the responsibilities could be separated and distributed.

[8] A case study that provides an excellent illustration of such synchronization issues can be found here: "Offering Donated Organs for Transplant," Decision Management Community Challenge, (March, 2019), https://dmcommunity.org/challenge/challenge-march-2019/
The RuleSpeak/SBVR Solution is here:
https://dmcommunity.files.wordpress.com/2019/03/challenge2019mar.behavioral-business-rules-for-heart-lung-donations.pdf

[9] e.g., using RuleSpeak — www.RuleSpeak.com

[10] Here are two simple tests for whether the language you're using for rules is 'natural-language'. If it understands 'null', no. If it has iterative loops, no.

[11] The space also happened to be one where existing platforms (some quite old) could be brought to bear.

# # #