Recently I helped one of our larger customers to build a set of their business decision models. At the end I said that now they can continue to assemble new decision models themselves. Then one of their business analysts said that our decision modeling approach reminds him of LEGO. I believe this is a really good analogy and I will elaborate on it using specific examples.

Traditionally DMN methodologists recommend to apply a top-down approach to decision modeling when you start with the very high-level decision and gradually decompose it to smaller sub-decisions.  In practice, decision model developers use a little bit of both”top-down” and “bottom-up” approaches: start with a high-level decision, switch to modeling of a low-level decision, go back to a higher level, etc. Real-world decision modeling really reminds construction of LEGO products when first you are trying to observe the final product, then assemble smaller parts, and then put them all together. This table shows the similarities:

Let’s consider a well-known business problem “Vacation Days“:

The LEGO-like DRD may look as below:

And here are the decision tables (in the OpenRules representation) for each of these 4 decisions:

As you can see, we decomposed one, relatively complex decision model in 4 smaller decision models (in this case, simple decision tables). Like in LEGO, we started with a assembling a foundation piece without worrying what we will put on the top of it later on. In this case the “foundation” is the first decision table that defines the variable “VacationDays”. This multi-hit decision table uses as its input 3 decision variables produced by other single-hit decision tables, which set eligibility variables for 5, 3, and 2 extra days.

While in LEGO, smaller pieces which we assemble first are usually already defined, decomposition of a large decision model to a set of smaller models requires experience and  some guiding principles. One of such guiding principles states:

Decompose a complex decision model into a set of simple, loosely coupled, potentially reusable decision models

For example, you may notice that each of our 4 small decision models above has a very simple decision logic that doesn’t interfere with the logic of other decision models: only output variables of some models can be input variables for others. Such non-interfering decision models can be called “loosely coupled decision models“.

How to define the scope that these loosely couple decision models will cover?  Decision Requirements Diagrams with links (called “knowledge requirements”) can be very helpful. As an example, let’s consider the notorious decision model “Loan Origination” from the DMN Chapter 11. Here is its DRD (slightly modified):

When we tried to decompose this DRD into smaller, loosely coupled models, we just circled them giving each “circle” its own name:

With LEGO’s pieces this schema will look much more clear:

One of the decomposition challenges for this decision model was caused by the fact that clearly reusable decision model “Affordability” requires two different decision variables “Pre-Bureau Risk Category” and “Post-Bureau Risk Category” as its input. So, we decided that two different decision models that define these two variables should rather define the same variable called “Risk Category” that will be used by the decision model “Affordability”. It immediately made these 3 decision models loosely-coupled. You can read more about the actual implementation here.

Now the question is: How to assemble loosely coupled decision models in one “big” decision model?

For the small decision model “Vacation Days”, the answer was simple as all 4 models were actually implemented as decision tables within the same decision model. But in the real-world smaller decision models frequently are self-sufficient and reusable decision models themselves. For example, for the above “Loan Origination” problem our 7  “Lego pieces” were assembled separately, meaning they were deployed and tested as separate decision models. They even were placed in different sub-folders of our knowledge repository that looked as below:

It is possible to use a Business Process Management (BPM) engine to integrate these decision models as decision tasks of one “big” business process. However, the latest release of OpenRules offers a special table of the type “DecisionImport” that simply imports smaller decision models allowing a bigger decision model to use them without any changes. Here is an example of “DecisionImport”:

The first column refers to the full path of the file “Decision.xls” for every decision model we want to import into the big decision model. The second column contains to the names of the imported decision models, under which they will be known to the “big” decision.

Of course, the import only makes small decision models available to the big decision models. The integration logic could be quite complex and specific for each decision – it is similar to special instructions, which Lego usually provides to describe how to put together already assembled parts. For example, in case of the big “Loan Origination” model we used the following integration logic:

CONCLUSION.  The decision modeling  approach with decomposition of a large decision model to a set of smaller independent decision models is similar to LEGO. Larger decision models can be constructed from already tested decision models similarly to how LEGO’s products can be constructed from smaller parts.

                                                                                                                                                                                            top