The modern Business Rules and Decision Management Systems help users to move business logic from a code to business rules controlled by subject matter experts (not developers).  In particular, the latest Decision Model and Notation (DMN) standard [1] defines powerful and broadly applicable concepts for decision modeling that allowed experts [2] to call DMN a “decision modeling language”. DMN even includes a friendly enough expression language, FEEL, to express complex relationships between different decision variables. However, DMN is a general purpose “decision modeling language” that naturally stays away from domain-specific decision modeling constructs. In this article I will discuss how to enhance DMN to support specialized decision modeling languages.

Let’s start with a real-world example from OpenRules [3] decision modeling practice. Our customer, one of the largest global security company and a US Government contractor, wanted to give their business users an ability to define various spatial business rules when distance between customers and suppliers regions may affect decisions. Of course, they already used a geospatial information system (GIS) in order to explore spatial relationships. Their business rules deal with business-specific concepts such as Airports, Hospitals, HRR (Hospital Referral Region) and HSA (Hospital Service Area). Here are examples of rules which business users should be able to express to specify spatial significance of the considered situations:

• HRR has at least 5 HSAs in it
• HRR has fewer than 5 HSAs in it
• HRR overlaps at least two Countries
• At least one hospital is within 5 km from the Airport
• Between 5 and 15 Hospitals are > 25 km from the Airport
• No Hospital is within 10 km from the Airport
• More than 2 Hospitals within 20 km from the Residence
• More than 1200 Residences within 15 km from the Hospital

Even if they try to present these rules using GIS API as external FEEL functions, it would create a barrier between subject matter experts and decision modeling software. So, a generic DMN-like decision modeling language cannot be used in such situations. What they needed was a new system that would allow their business users to define and maintain complex spatial rules without becoming experts in specific APIs.

Luckily this customer already used powerful OpenRules rules templatization mechanism that supports creation of custom decision tables. So, they asked us to help them to develop a “domain-specific” decision modeling language oriented to their subject matter experts. In response, we created a “Spatial Decision Modeling Language” that allowed their business users to express the above rules using custom decision tables that may look as below:

Here is another example of a spatial decision table:

What did we actually do to build a custom decision modeling language? We applied OpenRules to create a new Spatial Decision Table Template that actually works with two dimensional points or polygons by leveraging the industry standard Java Topology Suite to support the nine classic Eganhofer spatial relationships (touches, inside, overlaps, disjoint. etc.); distance calculations; distance rankings; spatial buffering; and various aggregate functions. Out template hides from business users all this complexity. The stakeholders with no GIS training may simply use plain English in familiar Decision Model spreadsheets to define spatially aware business rules without any knowledge of the underlying software.

Now let’s consider how DMN can be enhanced to implement domain-specific decision modeling constructs. The above Spatial Decision Tables look very similar to the standard DMN decision tables with a few exceptions:

• Instead of the standard keyword “DecisionTable” we use “DecisionTableSpatial” that is actually defines a regular multi-hit decision table
• Instead of the standard indicator of the table’s conditions such as the keyword “Condition”, these table used special keywords “ConditionEntityToEntity” and “ConditionEntityToCountOfRelatedEntities”
• These special columns have multiple sub-columns instead of trying to put complex relationships in one FEEL-like formula.

These new keywords are defined in the Excel-based Spatial Decision Table Template that by itself is a multi-hit decision table, which implements new by utilizing the above mentioned GIS API. So, this template can be easily enhanced by the customer developers without our help when they need to add new functionality.  You may read more about this use case at [4].

The above decision tables utilize an OpenRules implementation of aggregation mechanism with a separate operator sub-column inside “Conclusion” – it allows us to mix different aggregation functions within the same decision table. This is only slightly different from the standard DMN decision tables. More importantly, that the current version of DMN completely ignores sub-columns which for years have been a very powerful and frequently used feature of decision tables. This limitation is understandable as the current DMN is trying to specify the most generic types of decision tables when all relationships between decision variables are described either in different columns or using FEEL expressions inside cells of the same column.

Unfortunately, the current DMN identifies condition and conclusion columns in decision tables by the shape of vertical separator between columns (a double line) that is hardly a practical idea. Contrary, various DMN implementations are using explicit keywords such as “Condition”, “If”, “Conclusion”, “Action”, “Then”, etc. to identify various conditions and conclusions. This simple enhancement along with an ability to have multiple sub-columns is a basis for an introduction of custom conditions and conclusions. The future DMN doesn’t need to specify domain-specific conditions and conclusions and should remain a “generic decision modeling language”. However, by extending the standard decision table structure with these simple features, will encourage users to develop specialized DMN-based decision modeling languages. It will also be a great response to the practical need for domain-specific decision modeling for which you may find more examples at [5]:

References:

[1] OMG DMN Specification, http://www.omg.org/spec/DMN/Current/

[2] Bruce Silver “DMN as a Decision Modeling Language”, https://dmcommunity.files.wordpress.com/2016/07/decisioncamp2016-brucesilver.pdf

[3] OpenRules Business Rules and Decision Management System, http://openrules.com

[4] Alex Karman “The Decision Table Template for Geospatial Business Rules”, http://openrules.com/pdf/DecisionCAMP_2014_Alex_Karman.pdf

[5] Jacob Feldman “Building Domain-Specific Decision Models”, http://openrules.com/pdf/DecisionCAMP2014.JacobFeldman.pdf