Decision Model and Notation (DMN) is an OMG standard to ensure that decision models can be shared between multiple stakeholders, and/or created, analyzed and executed on platforms provided by multiple vendors. DMN is already showing promise, with several industrial business rule vendors providing support. This compares well to previous standards like Rule Interchange Format (RIF) and Production Rule Representation (PRR) which failed to gain industry adoption with the business rules community. This paper introduces DMN with a focus on the portability of its executable profile across computational platforms. The paper proposes a cross vendor collaboration challenge, “Vacation Days” from the Decision Management Community, to test the effectiveness of the standard for use in cross vendor situations. The different degrees of compliance and extensions as supported by the vendors is also discussed.
When looking at standards for business rules, of those proposed, none have yet gained
mature adoption with the main “business rule” vendors - such as Oracle, IBM and
Red Hat. The most notable efforts to date have been Rule Interchange Format (RIF),
Production Rule Representation (PRR) and the Rule Markup Language (RuleML). In
the case of RIF those vendors focused around the Production Rule Dialect
(RIFPRD). Both RIF-PRD, PRR and Reaction RuleML [
RIF was a large effort, from W3C, that attempted to provide interchange between a
number of different rule types using XML. RIF rule semantics were modelled on
Horn Logic [
PRR was a more focused effort, from OMG, that attempted to only provide a standard for production rules with a visual model representation (UML) as well as an XML document. It proposed two meta models, PRR-Core and PRR-OCL, with the latter committing to the use of BasicOCL, a subset of the OCL standard, to express the rule logic, while the former did not make any specific recommendation as to what expression language should be adopted.
RuleML, along the lines of RIF, focuses on providing a concrete syntax for the expression of a variety of types of rules, with varying degrees of expressivity according to the underlying logic(s). To this end, RuleML is an actually a modular family of languages, which can be composed to target the exact level of expressivity required by each use case.
In contrast to previous efforts centered on business (production and/or ECA) rules, DMN does not aim to be an interchange language between systems or offer full production rule semantics. DMN allows to express the specifications of how a business problem should be solved by means of processing information according to a given corpus of knowledge (either declarative or imperative, prescriptive or descriptive), with the aim that different “reasoning agents”, human or computer, can execute it. Since software agents executing production rules fall under this category, DMN provides an opportunity for business rule management system vendors to specify modular knowledge bases, and map them to something that can be executed on their production rule systems. The standard itself defines the required semantics of the standardized decision modeling constructs, but allows different vendors to execute them in a number of different ways. In fact, DMN focuses on the ability to define decisions, their information requirements, and the knowledge that influences the decision making processes. The assumption is that the results of one decision (making process) provides the answer to a precise business question, that can also be used as an input to other decision(s) until all the relevant answers are derived. The dependencies between decisions can be conceptualized as a graph, and expressed by means of a “Decision Requirements Graph”. The actual decision making logic is abstracted by the standard, and, when explicitly expressed, is expected to be formalized as a computable “expression” in some kind of language and notation, the most common being a Decision Table.
The purpose of this work is to test the effectiveness of this standard, using the “Vacation Days” example taken from the DMCommunity Jan 2016 challenge, by executing a cross vendor workflow defined so that multiple vendors are involved in the authoring, analysis and runtime execution.
The life cycle of a knowledge artifact (the expression of a piece of business knowledge expressed in some knowledge representation and reasoning language) may include activities such as the authoring, curation, storage and retrieval, verification, simulation, execution, revision and presentation. Different vended systems are likely to provide different subsets of capabilities around such activities: the goal of DMN is to support full interoperability between such systems, and this endeavor aims to assess how far away a number of mainstream concrete implementations are from this ideal state. 2
2. Conformance Level 2: A conformance level 2 implementation is required to support the same as Conformance Level 1, but expressions should be written using the S-FEEL (Simplified FEEL) language, as defined in chapter 9 of the specification. Conformance level 2 models must be fully executable. 3. Conformance Level 3: A conformance level 3 implementation is required to support everything in Conformance Level 2, plus the full set of boxed expressions. In addition to that, all expressions can be written using the full FEEL language, as defined in chapter 10 of the specification.
DMN was designed for BPMN2 interoperability (see Fig. 1) and decision models can be linked from a decision task within a business process model expressed using the BPMN2 standard. This relationship is usually manifested allowing to navigate from a business process diagram (that renders a BMPN2 process model) to a decision model diagram (that renders a DMN decision model).
A Decision Requirements Graph (DRG) (see Fig. 2) is a directed acyclic graph of nodes (see Fig. 3) and the relationship between those nodes (see Fig. 4), that models the decision making logic in a given business domain. A Decision Requirements Diagram (DRD) is a “view” on a DRG, i.e. a subset of the nodes and relationships, that emphasizes the decision making logic from the full DRG.
These graphs model the chain of decisions and its dependencies, with each decision node receiving an input and producing outputs for other decision nodes to consume. There is no single starting or end point. Instead each node defines the variables it needs in order for it to be able to evaluate: whenever those variables are available, an (informed) decision can be evaluated to produce more information, which in turn can result in other nodes being satisfied and evaluated. Nevertheless, DMN does not dictate whether decision models should be evaluated in a ‘forward chaining’ rather than a ‘backward chaining’ or a ‘hybrid chaining’ manner. The orchestration of decisions is left to the implementation (engines), or by orchestrating the decisions by means of business processes.
Fig. 4 DRD Component Requirements [
DMN supports decision tables as one form of expression to determine the outcome of a decision making process. DMN Decision tables support both vertical and horizontal layout with single or multiple output columns, as well as a crosstab layout. Decision tables also specify a hit policy which controls the execution behavior of the table. Fig. 5 shows a horizontal layout, with rules as rows and a single result column. 2.3 FEEL The DMN standard defines a new expression language called FEEL, that stands for “Friendly Enough Expression Language”. The purpose of this new language is to define standard execution semantics that would be common to all models, allowing the model to produce the same results independently from the runtime environment.
It is a language designed to appeal to non-technical users, and the goal was that any user capable of authoring typical spreadsheet formulas would be able to learn and use FEEL.
In FEEL, every expression is a formula that produces a value. FEEL expressions are side effect free and variables are immutable.
FEEL defines just a few common data types: string, boolean, number, date, time, and duration types. These types can be restricted to enumerated values or ranges, and can be combined to form complex data structures. FEEL variables may include lists and tables, as well. FEEL provides a large number of built-in functions and operators.
Boxed expressions are expressions presented in tabular formats. It is a way to decompose complex logic in tables making them more readable. For instance, the following example (see Fig. 6) is a boxed expression called “Context”. A Context is a list of key-value pairs represented as a table with two columns, where the first column is the key (or variable name) and the second column is the value (represented as a FEEL expression). The last row of a Context Boxed Expression does not have a name and the result of its value expression is the result of the boxed expression as a whole.
Boxed expressions can be nested. For instance, a Decision Table can be a value of a context entry in a Context Boxed Expression.
The metamodel defines all the components of a DMN model, its properties and semantics. By bringing formal precision to the element definitions, they ensure DMN models can produce the same results when executed by different decision engines.
The XML schema, on the other hand, is the standard syntax that enables
interoperability between different engines. One of the DMN metamodels, the
“decision metamodel”, is shown in Fig. 7. DMN defines XML for each its
metamodels.
As of now there is no clarity or transparency on what is supported across vendors, or
what this common denominator is. Most vendors have not yet gained full CL2, so
there is a long way to go before wider CL3 adoption is made. This places a burden on
the end user to understand what this common denominator is and keep their models
within that to ensure what they create is portable. Work is underway on a community
driven TCK [
Furthermore, several vendors are proposing extensions to address customer needs. This will also represent problems with portability and end users should be fully aware of those extensions, before adopting them. In some cases, efforts may be underway to have those extensions adopted within the standard. 4
The Decision Management Community (http://DMCommunity.org) runs regular
challenges which provide plenty of potential source material. Most vendors do not
have full DMN support yet so it’s important that we pick an example that uses the
common denominator that is supported. Vacation Days [
The number of vacation days depends on age and years of service. Every employee receives at least 22 days. Additional days are provided according to the following criteria: 1.
Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days. 2. Employees with at least 30 years of service and also employees of age 60 or more, receive 3 extra days, on top of possible additional days already given. 3. If an employee has at least 15 but less than 30 years of service, 2 extra days are given. These 2 days are also provided for employees of age 45 or more.
These 2 extra days cannot be combined with the 5 extra days.
Following the DMN standard, the high-level solution is modelled in a DRD (Decision Requirements Diagram) that is presented in Fig. 8. Each node of the diagram is explained in the following sections.
The problem statement presents 3 different rules/cases for extra vacation days. Although the cases can be combined into a single expression or single decision table, in order to improve the maintainability of the solution, a separate decision table was defined for each case. The three cases are presented in figures Fig. 9, Fig. 10, Fig. 11 and Fig. 12 It is important to note that for simple decision tables like this, there are several hit policies that could be used with the same result (for instance, Priority (“P”) policy would also work).
Calculating the total vacation days is then a trivial summation of all the component decisions, with a single caveat: the problem statement indicates that the extra vacation days from cases 1 and 3 are not cumulative. There are several ways of doing this and the example uses a decision table, because it is easy to understand and works across all the tools:
The “Collect SUM” hit policy adds up the values of all matching rows, calculating the total vacation days. The model is very easy to read and understand.
Here is a table with some results generated by the solution.
The cross vendor collaborative workflow involves 5 different vendors, each addressing a different part of the workflow. • Authoring: Signavio, Trisotech • Execution: OpenRules, Drools • Analysis: Method&Style The demo was executed as shown in Fig. 14. Using a subset of DMN we have managed to take an example involving DRDs and decision tables and create, analyze and execute those across multiple vendor’s products. While there is little full CL2 or CL3 compliance yet, this is a stronger starting point that either RIF-PRD or PRR managed to attain. Although it should be noted that DMN’s goals are different. RIF-PRD and PRR were about interchange between two systems and not the primary authoring target of those systems. DMN primarily addresses portability, allowing the same document to run in different systems – rather than interchange native documents between systems. DMN still presents many challenges to early adopters due to lack of clarity on the degree of support across vendors and this will be the next challenge for DMN. As shown in the demo it can be a case of trial and error to find that portable common denominator. This makes it difficult to know what can or cannot be used from DMN while still ensuring models remain portable. The community driven TCK will be an important tool to help drive DMN to that next level, providing the clarity and transparency that customers need. In the early stages where there is still not full CL2 or CL3 compliance, it will not be enough to say whether a vendor meets CL2 or CL3. Instead it must provide a detailed breakdown of what is and isn’t supported by a vendor, so end users can use this information to guide them through the trial and error process of making portable documents.