DMN Decision Engine Comparison

  • May 30, 2017
  • Tom
  • 0 Comments
[ Editor’s note:  Originally published here, republished with permission ]
 

 

Since the Object Modeling Group (OMG) released the DMN 1.1 specification, a number of DMN-based decision engines have hit the market that take advantage of this new modeling technology. Over the last few months a number of customers and colleagues at BP3 have asked me, “When should we choose one of these new DMN-based decision engines over a BRMS like IBM’s Operational Decision Manager (ODM)?”

The DMN 1.1 specification provides for both decision modeling as well as decision execution, depending on the level of conformance to the DMN spec. met by an implementation. Over the last couple of years we’ve seen a number of DMN modeling tools become available. Although these have proven to be quite useful, what I find particularly interesting are those DMN implementations that actually execute decisions. I refer to these as “DMN Decision Engines”. Of particular note is the DMN Decision Engines from Camunda 7.6, and IBM’s experimentation implementation of Decision Composer.

From a modeling perspective, DMN allows a user to functionally decompose how a decision is made. Typically, this exercise starts by describing the primary decision being made, by defining the question the decision answers, and the particular types of answers that are allowed. The modeler then systematically decomposes the primary decision into dependent decisions. In DMN, this decision decomposition ends when it is no longer meaningful to break down a lowest level decision into further dependent decisions. For each decision described within the decomposition, the modeler then needs to describe how that decision is made. The DMN 1.1 specification gives us a few options. The user can either describe this decision as a decision table, which if you a familiar with ODM, is basically a collection of if-then rules that all have the same structure. If a decision table is not appropriate, DMN provides what is called a “literal expression”. A literal expression, as far as I can tell can basically be any kind of statement that returns a result that is within the domain of allowed answers for the given decision. In ODM, we would probably think of an expression as a business action language (BAL) rule, i.e. ‘if <condition> then <action>”. However in DMN, this is much less specific. There is a concept in DMN of a “FEEL Expression” which stands for “Friendly Enough Expression Language”. However, I have not yet seen a full implementation of this language.

Alright, so lets start by looking at the Camunda DMN decision engine. This implementation is the first DMN decision engine I’ve actually seen. I was introduced to it during a session that was given at BP3’s BPM Camp in August 2016. The presentation was given by a couple of really sharp guys out of Berlin Germany who work for Camunda. In their presentation they showed us how to use Camunda to model a DMN decision, and implement it with a decision table. When I asked them if they had implemented any other types of expressions, they said that only decision tables were currently supported, but that they were working on other types of expressions. Fast-forward to March, 2017, when I downloaded Camunda 7.6 and implemented a basic “Driver Eligibility” decision.

From this Decision Requirements Diagram (DRD), you can see that determining driver eligibility is dependent on two other decisions. The first is the Driver’s Age, which is calculated based on the date of birth of the driver and the current date. The other dependent decision is whether or not the driver has received formal driver training.

From an implementation standpoint, I used a decision table to answer the Driver Eligibility question. I like the fact that Camunda allows for multiple outputs on a single decision. In this case, I added a reason for ineligibility where appropriate. From an integration standpoint, it is a little tricky dealing with multiple outputs since Camunda only allows for basic types. This means that the result of the decision comes out as an array as opposed to a structured type. If I were implementing this in ODM, I would have made the output of the decision table invoke a method with two parameters (boolean and string), and then return a complex object in the response. From a non-technical usability standpoint, I can totally see a business user modifying the entries in this decision table. This is key, as one of the primary value proportions of a DMN decision engine or a BRMS should be that non-developers can create and modify decisions.

To implement the other two decisions, “Driver Age” and “Received Driver Training”, I utilized a Literal Expression. With Camunda, the good news is that the user has lots of options for implementing a literal expression. In version 7.6, they support javascript, groovy, python, jruby, juel and a very limited implementation of FEEL. This means that we we can implement any kind of logic we need within an expression. So, in the case of determining if a driver has received driver training, I’m using javascript to invoke a Java method that traverses a list of training courses that the driver has taken. The method returns true if the list includes a DRIVING course, and if the driver actually passed that course. Although this is very functional, it requires a developer to actually implement the expression. This makes Camunda’s implementation a bit limited from a non-technical user perspective as compared to ODM, where non-technical users can write an action rule that invokes a similar method. In the future, I expect that Camunda will beef-up its implementation of its FEEL expression, which should hopefully allow non-technical users to participate more fully in the decision automation process.

The other DMN decision engine I looked at was IBM’s experimental Decision Composer. The current implementation is exposed through IBM’s Bluemix PaaS environment. This is a pretty cool implementation that under the hood is just ODM. In fact, you can learn a lot about how it works by creating a decision model and then exporting it from Decision Composer. The exported file is just an archive of an ODM rule project. If you unzip it, you can bring it up inside of ODM’s Rule Designer.

I tried implementing the same Driver Eligibility decision and was mostly successful. The Decision Composer UI is pretty intuitive. Not only can you model a decision, but it provides functionality to define complex types to use within the decisions.

The “Driver Eligibility” decision table, that I implemented in Decision Composer is pretty much identical to the one I created using Camunda. My implementation of “Received Driver Training”, however, in Decision Composer is quite a bit different. Instead of implementing it using Java or javascript code, Decision Composer allows the user to write rules in the Business Action Language, just like ODM. Although the verbalizations are a bit funky, IBM has enable non-technical users to more fully participate in the decision implementation process than with the current implementation of Camunda.

Where this experimental version of Decision Composer falls down is in its inability to invoke Java methods within a decision. In the Camunda example, I was able to write a method that calculated the driver’s age based on their date of birth and current date. For the life of me, I couldn’t figure out a way to do this within Decision Composer. I even tried to perform the calculation within a BAL rule, like I would in ODM, but IBM doesn’t seem to included the necessary business object model (BOM) entries needed to pull it off.

So, given a choice, which technology is better, Camunda’s DMN Decision Engine, IBM’s Decision Composer, or do we just stick with IBM’s Operational Decision Manager? As with most questions like this, I have to say “it depends”. If you are already using Camunda, and your decisions can be entirely implemented using decision tables, then Camunda’s DMN Decision Engine is a pretty good choice. However, if any of your decisions require an implementation other than a decision table, and your users aren’t developers, it’s probably not the best choice. Once Decision Composer gets beyond experimental, it might be worth considering as it allows non-technical users to implement decisions using either decision tables, or BAL rules. However, until IBM comes up with a way to write a BAL rule that can invoke a Java method, there will be some decisions that you can automate using ODM that simply can’t be handled by Decision Composer.


, ,
Related Posts
  • September 19, 2017
  • Ariana
  • 0 Comments

What is Digital Transformation from BP3 on Vimeo. CEO, Scott Francis talks how BP3 helps companies operatio...

  • September 17, 2017
  • Scott
  • 0 Comments

Ray Wang wrote a great post on the subject of successful AI projects and the outcomes they seek almost a year ...

  • September 11, 2017
  • Scott
  • 0 Comments

The Harvard Business Review published "Leading Digital Transformation Is Like Urban Planning" - in which they ...