What Else Should Rule Platforms Be Doing?
Where DMN and Decision Models Fall Short
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.
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.
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. 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 (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:
- A points reservation is created.
- The person holding a points reservation is changed.
- The reservation holder of a points reservation ceases to be a club member.
- 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. 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. 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?
- Monitor events apart from processes to detect flash points.
- 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.
Shortcoming 6. Lack of Support for Natural Language
DMN and decision models offer no support for structured natural-language expression of rules. 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 is simply not going to fly.
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. And they have treated that space as a semantics-free zone. So much more can and should be done.
 Ronald G. Ross, Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business (2nd ed), (2020), Appendix 3.
 Refer to Business Knowledge Blueprints, Appendix 3 for definitions.
 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
 An example of a behavioral rule with just two flash points is presented in Ross, (Feb. 2022).
 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.
 For more about the watcher, refer to Ross, (Feb. 2022).
 Ideally, the watcher would do both tasks, although the responsibilities could be separated and distributed.
 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:
 e.g., using RuleSpeak — www.RuleSpeak.com
 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.
 The space also happened to be one where existing platforms (some quite old) could be brought to bear.
# # #
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules