Here at Decision Management Solutions, we are big believers in decision models using the DMN industry standard notation. We’ve modeled over 3,000 decisions around the world and we’ve trained over 1,000 people in decision modeling. We use decision modeling on all our projects and have done since 2011, before there was a standard.
We use decision models to define requirements for decision-making and to orchestrate existing decision technologies like Business Rules Management Systems, predictive analytics, AI etc. We create virtual decision hubs that orchestrate all the decision-making technologies required in a solution from business rules to ML, predictive analytics to AI whether custom or packaged.
We don’t use executable decision models and FEEL (the Friendly Enough Expression Language) very often. Some say that the only good decision model is an executable one. We don’t we agree for three reasons – business user engagement, maintenance and analytics/AI.
This week I will write a set of blog posts to cover the 3 reasons and I’ll wrap up with something about our virtual decision hub approach.
Reason #1. Business user engagement
One of the key challenges in executable models is that they must be 100% complete to be useful. You can’t edit generated code or add to an executable definition outside the model because if you do then you lose the connection between the model and the execution that is the reason for an executable model in the first place. This means, inevitably, that you embed programming concepts in your models.
We find this reduces business user engagement catastrophically as subject matter experts (SMEs) are reluctant to own or maintain “code”. As a decision model becomes more executable it gets more complex, more code-like, and SME engagement drops. Our experience is that keeping SMEs engaged is the #1 success factor so this is a real issue.
We keep the decision models we build focused on what the SMEs need and embed any necessary programming complexity in decisioning technology that we map to the decision model. So, for instance, programming logic and complexity is embedded in a business rules management system (BRMS) and not in the decision model. The 80%+ of a decision that is business friendly is modeled in the decision model and mapped to business-friendly artifacts like decision tables. The rest is in the technical layer of the BRMS where it executes but does not impact the decision model. This keeps SMEs engaged and ensures they own the decision model and the related business logic.
In my next post I’ll discuss the challenges of maintaining executable models.
To learn more about our DecisionsFirst approach, contact us and don’t forget to subscribe to our DecisionsFirst Digital Transformation newsletter.