DMN Decision Engine Comparison
- May 30, 2017
- 0 Comments
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.
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.
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.