With the (almost) official release of DMN1.1 we find ourselves at an interesting crossroads in the industry as the concept of consistently modeling decisions becomes more widespread. It seems clear that we’ve moved from questions of “What is this?” to “How can we effectively leverage it?”. A plethora of companies have developed platforms to support DMN or at least support it through some kind of adapter. Gartner has commented on it and MISMO (Mortgage Industry Standards and Maintenance Organization) is moving towards adopting it as an official standard for exchange and interchange in the mortgage industry.
This crossroads also includes fundamental questions surrounding what we can do, what we can’t do, and what we should be doing with the standard. I’ve seen this manifest itself in two primary ways:
- Modeling vs. Implementation
- Methods to implement, share, disseminate and execute decision logic
These will both be discussed here.
DMN provides a rich toolset for both business and IT to model and represent decisions and requirements. Many have feared that this is often minimized by just focusing on the rules. James Taylor – a member of the august group responsible for DMN – posted a wonderful article looking at common misconceptions around DMN*. His tenets include the reminders that DMN is not just rules, not just decision logic, and not just successful only if code can be generated. It’s ability to provide a common tool for all members of the Enterprise to model requirements is absolutely critical. It’s our duty as practitioners to ensure this function is not lost. That said, I get more questions and inquiries from interested organizations that are directed along those very lines: how does decision logic get expressed, how is it implemented, and how can it be shared and exchanged. Gartner themselves in acknowledging DMN** seem to be identifying the importance of implementation. Two of their three primary keys to decision modeling seem to stress this:
- Use business-logic decision models to implement repeatable decision-making processes
- Build explicit analytic and business-logic decision models at conceptual, logical and physical levels
Implementation, decision logic and representation are clearly important and being considered by many. DMN certainly provides that path to get there.
DMN 1.1 has gotten us to Conformance Level 2 which includes support for DRDs, decision tables, and expressions based on S-FEEL. S-FEEL (Simple FEEL) is a subset of FEEL (Friendly Enough Expression Language) that essentially includes math and simple comparisons. There is, however, enough expressive power in S-FEEL to handle many use cases. Conformance Level 3 would include full FEEL which brings with it boxed expressions, function invocations, and relational data tables. This would be a complete programming toolkit ready to handle any user story. I believe that S-FEEL has limits and is not well suited to certain kinds of decisions and use cases as was addressed more fully in a previous essay***. However, it is tremendously powerful.
New product vendors in the DMN space seem to be taking a cautious approach towards their platform development. Most support full DMN modeling, others include S-FEEL development capability with the modeling, and some have integrated BPMN process modeling with the suite. No vendor yet has attacked FEEL. I’ve heard from several that they’re monitoring adoption levels of S-FEEL before proceeding. In fact, some vendors with pre-DMN platforms, while offering decision modeling, eschew S-FEEL in favor of their own decision table implementations.
This may seem minor but it has some potentially serious ramifications. Certainly, the DMN models themselves can be shared and exchanged. But if those models include decision logic that may or may not be S-FEEL (or ultimately FEEL) compliant, we may lose the capability for exchange at that level. Interchange at the decision logic level could then only occur across the same platform.
However, the ability to have more commonality in implementation is one of the most exciting and appealing aspects of DMN. We know the old business rule management system paradigm never fully realized its goal of complete business control. Even if we still fail to realize that dream of full business control**** and management (and DMN certainly seems as though it will get us as close as ever), we have deployment opportunities that minimize the need. Interchange and exchange can lead to the ability to disseminate rule libraries to interested parties. By using DMN-compliant software we’re guaranteed consistency in application and execution. Industries with data standards (e.g., mortgage) have a common language in which we can express decisions and logic. And we can make it even simpler. Cloud-based DMN platforms can make decision services available for a variety of needs. SaaS becomes DaaS – Decisions as a Service. Or to revisit something we first contemplated approximately 8 years ago: Decisions on Demand.
The continued evolution of DMN and the appearance of new, exciting platforms to take advantage of its power is helping decision management to truly realize its full potential.
* Dispelling some common misconceptions about decision modeling on MAY 5, 2016 in BUSINESS RULES, DECISION MANAGEMENT, DECISION MODELING.
** Lisa Kart and Roy Schulte of Gartner recently published a new research report Develop Good Decision Models to Succeed at Decision Management.
*** Making Decisions Operational, Business Process Management Instititute, February 2015.
**** Why Johnny Still Can’t Write Rules, Business Process Management Institute, January 2013.
