Today Nick Broom published his own example of a decision model based on his understanding of the current version of the DMN standard. Nick is a business analyst and a well-known decision management practitioner, so his interpretation is very valuable as the standard is oriented to the business analysts (not to programmers). Nick’s example is supposed to make a decision whether an applicant is eligible or ineligible to a credit card. Nick described a simple credit card application process and designed decision requirements diagrams and related decision tables.
Starting to read his post, I decided that it could be helpful to make Nick’s decision model executable and to test if it actually produces the expected results. It took me several hours to do it using mainly Excel and the latest version of OpenRules BDMS. I took a standard OpenRules example “DecisionLoan” and converted it to a new project called “DecisionCreditCardApplication”. You may look at the actual implementation in the Excel format:
- Decision.xls: a business decision with a Decision Requirements Diagram (DRD) and links to all other Excel files
- Decision tables
- Glossary.xls: a business glossary
- Data.xls: test data
- Execution results
- results.txt – decision execution protocol
- report1.htm – decision execution report for the use case 1 in the HTML format
- report2.htm – decision execution report for the use case 2 in the HTML format
- report3.htm – decision execution report for the use case 3 in the HTML format
I will make this OpenRules project publicly available soon so everybody would be able to download, modify, and execute this decision model. Meanwhile, I will describe this executable version of Nick’s model with some comments.
OpenRules-based Implementation
So, Nick’s decision requirements diagram looks like below:
I placed this diagram to the Excel file Decision.xls and converted it to a simple tabular high-level decision:
The main decision invokes two sub-decisions that should “know” their own business logic.
Business Logic
Here is the first decision described in the file DemographicSuitabilityRules.xls:
It consists of 3 sub-decisions; here are the first two decision tables:
In the last column I put $ in front of the variable “Applicant Private Credit Card Demographic Suitability” as required by OpenRules (but not by DMN). Nick tried to represent this “Business Knowledge Model” by strictly following to the DMN:
Click on the picture to see a larger image. Along with a very similar decision table you will see something called “Boxed Expression” and other “boxed” DMN concepts that Nick really “hates”. As a business analyst, he has serious reasons for that, and we, at OpenRules, are trying to avoid the necessity to use these technical and awkward constructs. Still Nick (probably) made a mistake in his decision table by calling variables like “Applicant Private Credit Card Demographic Suitability” instead of the proper decision table.
Note, that OpenRules allows a user not to introduce a special sub-decision “ApplicantDemographicSuitabilityDecision” (see above) bu rather call the decision table “ApplicantDemographicSuitabilityDecisionTable” directly. This table will invoke other two decision tables only when necessary if we add one more action-column to it:
OpenRules offers several other ways to represent these relationships between decision tables, and a user may choose the most appropriate one for his/her particular decision model.
There is another big topic to discuss called “Hit Policy” but I will get back to it at the end of this post when I complete the description of the implementation.
So, our second major sub-decision is described in the file EligibilityRules.xls:
It invokes the following 3 decision tables:
The last table gives an example of a multi-hit decision table. It is quite similar with the version provided by Nick:
However, Nick tried to follow a DMN sample representation of the hit policy and the aggregation methods. Our decision table shows that the same concepts could be represented in a much more intuitive way:
- We do not use a special first column with a mystical characters “NC” and unnecessary numbered rules; instead our decision table is simply defined by the keyword “DecisionTableMultiHit” in the top-left corner.
- We do not use a special last row with “Aggregation = sum” that brings many questions to be addressed: does it belong to only action-column “Applicant Credit Score”? what if we want to use different aggregations inside the same column or even different action-columns? At the same time OpenRules’s aggregation is simply a special type of the standard operator “+=” in the action-column “Applicant Credit Score”. As this example uses the same increment-operator “+=” for all rows, we simply merged all operator rows. But a user may also use “-=”, “*=”, and “/=” in different rows of the last action “Applicant Credit Score”.
This completes our business logic representation.
Glossary
Nick correctly pointed out that DMN does not explicitly specify a business glossary but every implementation tool usually provides one. For example, in OpenRules you may define the following table:
I decided that for this simplified version it will be enough to define only two business concepts “Applicant” and “Application” (see the second column above). Then I filled out the first column by copy-pasting all decision variables from the column titles of all previous decision tables. The third column contain “technical” names of the proper object attributes for the mapping to the actual data (no spaces allowed). And finally the fourth column (optional) defines possible domains for some variables.
Test Data
Nick did not test his decision model that is a real problem for many pure methodological tools that “proudly” claim that they do not to care about the model execution. Applying main agile principles to decision modeling we may state:
- There should be not decision models that could not be executed
- Decision modeling should be test-driven.
So, to execute and test out decision model we need to create at least several test (use) cases that become an essential component of our decision model. It should be done even before you commit to any decision execution platform (while I personally do not like such separation).
Out decision model requires that the types Applicant and Application at least should contain the following attributes that I described in the file Data.xls:
The actual data type could be define in Java classes or in XML, but these Excel-based definitions are sufficient for our testing needs. Now we may define the actual test cases:
Executing and Analyzing the Results
Now we are ready to execute our decision model against thee 3 test cases. I quickly modified a standard Java template that execute the most of OpenRules-based decision model. It you are interested you may find the actual code here.
The execution of our decision model against 3 above test cases produces results presented in the file results.txt. For example, for the third applicant
we receive the following results:
Looking at this execution protocol we already may understand how sub-decisions and decision tables were executed. It is even more convenient to analyze the generated execution reports in the HTML:
- report1.htm – decision execution report for the use case 1 in the HTML format
- report2.htm – decision execution report for the use case 2 in the HTML format
- report3.htm – decision execution report for the use case 3 in the HTML format
For example, the following table contains only those rules which were actually executed that explains how the credit score 550 was calculated:
Comments
If you look at my decision tables and those proposed by Nick, they are very similar with only a few differences. However, there is one important difference in our interpretation of the DMN that I want to clarify now.
DMN provides a quite powerful concept of “Hit Policy”:
As a possible (but not mandatory!) representation of the Hit Policy, DMN suggests using the very first column of any decision table with a combination of two characters:
- The first one defines a hit policy (U, A, P, F, N, O, R)
- The second character ‘C’ is supposed to tell if the decision table is complete meaning all rules are included to cover all possible combinations of decision variables.
The numbers in this column may represent different priority orders for different first characters – that may lead to a complete maintenance nightmare in my humble opinion. I don’t believe Nick likes this approach either, but he tried to follow this suggestion to somehow demonstrate the use of the DMN hit policy. So, his first column always contain two characters such as “AC” or “UC” like for example in this decision table:
I don’t think that a designer of the decision table should decide whether the table is complete or not – it should be done by an automatic tool. For example, this table obviously is not complete even if we mark it as “UC”.
OpenRules provides one of the most sophisticated decision tables mechanism with different hit policies but we use a much clearer way to define it. I’ve already sent my critique to the DMN developers and together with other BR vendors we plan to send more specific suggestions to them. I hope they will find the example produced by Nick and my implementation useful while considering modifications to the beta version of the DMN.
OpenRules - Decision Intelligence Software 