Decision Requirements and Modeling with DMN in SMARTS
In this post, we present how Sparkling Logic continues its involvement in the DMN standard, through its graphical tool SMARTS Pencil, which business analysts use to model business decisions by drawing a diagram to form a decision process.
DMN, a bit of historyThe Decision Model and Notation (DMN) was formally introduced by the Object Management Group (OMG) as a v1.0 specification in September 2015. Its goal was to provide a common notation understandable by all the members of a team whose goal is to model their organization’s decisions.
The notation is based on a simple set of shapes which are organized in a graph. This allows the decomposition of a top-level decision into more, simpler ones, whose results must be available before the top-level decision can be made. These additional decisions themselves would be decomposed, and so on and so forth until the model reaches a more complete state. In addition, the implementation of the decisions can be provided, notably in the form of decision tables (which is also a very common means of representing rules).
The normalization of the graphical formalism (the DMN graph) and of the way the business logic is implemented (e.g., decision tables) allows teams to talk about their decisions, using diagrams with a limited set of shapes.
Sparkling Logic was one of the early vendors to provide a tool to edit (and execute) these decision models: Pencil Decision Modeler. It was released in January 2015, before the standard was officially approved.
Since then, the DMN standard evolved significantly, by adding new diagram elements, new constructs and new language features, while clarifying some of the existing notions. It is now at version 1.3. And we didn’t rest on our laurels either: in SMARTS Ushuaia, we made Pencil Decision Modeler part of SMARTS, as a first-class feature and added full compliance to DMN 1.3! This post describes how SMARTS supports DMN 1.3.
BasicsDMN 1.3 still defines the building blocks which were in the original standard and which I mentioned in Talking about decisions.
As a recap:
- A Decision determines its output based on one or more inputs; these inputs may be provided by an input data element, or by another decision
- An input data is information used as input by one or more decisions, or by one or more knowledge sources
- A business knowledge model represents knowledge which is encapsulated, and which may be used by one or more decisions, or another business knowledge model. This knowledge may be anything which DMN does not understand (such as a machine learning algorithm, a neural network, etc.) or a DMN construct (called a “boxed expression”, see below)
- A knowledge source represents the authority for a decision, a business knowledge model, or another knowledge source: this is where the knowledge can be obtained (be it from a written transcription or from someone)
These blocks are organized in a graph and the links between them are called requirements.
What’s new in SMARTS’ DMN Support
More building blocksIn DMN 1.3, the following elements may also be added to a graph:
- A decision service exposes one or more decisions from a decision model as a reusable element (a service) which might be consumed internally or externally
- A group is used to group several DMN elements visually (with whatever semantics may be associated with the grouping)
- A text annotation is a shape which contains a label and can be attached to any DMN element
Custom types and variablesInput data, decision and business knowledge model elements all have an associated variable, which is of a given type (string, number etc., or custom). A variable is a handle to access the value directly passed by an input data element, or calculated by the implementation of a decision or a business knowledge model, from within the decision implementation.
Custom types may be defined to group multiple properties under a single type name (with structure) or to allow variables which will hold multiple values (arrays).
Boxed ExpressionsA few constructs are available to provide an implementation for a decision or a business knowledge models; they are termed boxed expressions since such expressions are shown in boxes which have a normalized representation. The following types of boxed expressions are available in DMN 1.3:
- Literal expression: this is a simple expression which can use the available variables to calculate a result
- Context: this is a set of entries, each combining a variable and a boxed expression. Each entry in the context can use the variables of the entries defined before it, which is like using “local variables” in some languages
- Decision table: this is a tabular representation where rows (called rules) provide the value of outputs (supplied in action columns), depending on the value of inputs (supplied in condition columns)
- Function: a function can be called using an invocation, by passing arguments to its parameters. The result of a function is the result of the execution of its body (which is an expression that can use the values of the passed parameters). A Business knowledge model can only be implemented by a function
- Invocation: this is used to call a function by name, by passing values to the function’s parameters
- List: this is a collection of values calculated from each of the boxed expressions in the list
- Relation: this is a vertical list of horizontal contexts, each with the same entries
In addition to these, SMARTS defines an additional boxed expression, called the rule set. This is a set of named rules, where each rule is composed of a condition (an expression evaluating inputs) and action (an expression providing some values to outputs).
Helping Industry AdoptionWith SMARTS Ushuaia, decision models are first-class citizens. The full compliance with DMN 1.3 means that all the DMN elements and boxed expressions, as well as the ability to interchange diagrams with other tools, are part of the package.
As is usual, any model can be tested and executed in the same context as your SMARTS decision –a decision is never made in isolation, and a model is never used in isolation either. And of course, you will benefit from the great tooling we provide.
Finally, we at Sparkling Logic strongly believe that decision management technologies should be put in the hands of all business analysts. This is why we are part of the DMN On-Ramp Group, whose mission is to provide a checklist to help customers find the DMN tool to suit your needs, educate and raise awareness about DMN, and help with DMN compliance. For a great presentation of the group, check out here.
AboutSparkling Logic is a Silicon Valley company dedicated to helping businesses automate and improve the quality of their operational decisions with a powerful digital decisioning platform, accessible to business analysts and ‘citizen developers’. Sparkling Logic’s customers include global leaders in financial services, insurance, healthcare, retail, utility, and IoT.
Sparkling Logic SMARTSTM (SMARTS for short) is a cloud-based, low-code, AI-powered business decision management platform that unifies authoring, testing, deployment and maintenance of operational decisions. SMARTS combines the highly scalable Rete-NT inference engine, with predictive analytics and machine learning models, and low-code functionality to create intelligent decisioning systems.
Marc Lerman is VP of User Experience at Sparkling Logic. You can reach him at email@example.com.
If you envision modernizing or building a credit origination system, an insurance underwriting application, a rating engine, or a product configurator, Sparkling Logic can help. Our SMARTS digital decisioning platform automate decisions by reducing manual processing, accelerating processing time, increasing consistency, and liberating expert resources to focus on new initiatives. SMARTS also improve decisions by reducing risk and increasing profitability.