Dmn

Low-Code Standards-Based Business Automation Services

There is no hotter segment of Business Automation software today than Low-Code. Low-Code refers to application development based on models - diagrams and tables - and business-accessible expression languages, not program code. Gartner assesses Low-Code as a $13.8 billion market in 2021, growing to $46.6 billion in 2023. And, they say, by 2024 it will account for 65% of all application development! According to Forrester, 100% of companies that have adopted Low-Code report satisfactory return on investment.

What is DMN?

Over the past year I've written a number of posts on specific aspects of DMN, but many readers may be unfamiliar with this standard and how they might benefit by learning to use it. In recent months, I've discovered new ways of using it myself, so even experienced modelers may learn something from this post. DMN, which stands for Decision Model and Notation, is a business-oriented language for decision logic. Like its sister standard BPMN, the language relies on a standard palette of shapes and symbols - that's the "

Business Automation Services in Fintech

In client engagements, I am seeing growing interest in what Trisotech calls Business Automation as a Service. I am seeing it particularly in financial services, but I expect it applies in health care and other verticals as well. Financial services, for so long reliant on legacy applications, is now racing to create new cloud-based apps built on modern architecture, where business automation services built with BPMN and DMN are a great fit.

XML and JSON in DMN Models

A critical piece of what makes DMN accessible to business users is its expression language FEEL. FEEL variable names are business-friendly. Because they are simply the labels of the shapes in the Decision Requirements Diagram (DRD), FEEL names may contain spaces and other punctuation not allowed by other expression languages. OK, you already know this. But when you publish a DMN model as a collection of executable decision services, a non-DMN client can't invoke it using FEEL.

DMN: Dealing with Nothing

They used to say Seinfeld was a show about Nothing. But given its enduring influence on popular culture, Nothing is clearly not nothing. Attention must be paid. In DMN, as well, Nothing demands attention. In simple models like the ones we study in my DMN Method and Style Basics and Advanced training, it doesn't come up. But in many real-world decision models, Nothing pops up all over the place, often unexpectedly.

Calling REST Services from DMN

One of the basic principles of DMN is that decision services are stateless, meaning that given the same set of input data values, the service output will always be the same. But sometimes it is convenient to break that rule with tool-specific extensions. For example, in Trisotech Decision Modeler the FEEL built-in functions Today and Now, which return the current date and date/time, respectively, break the rule. If you wanted to strictly comply with DMN you would need to define those as input data and, if necessary, look up the values before executing the DMN service.

Modeling Virus Transmission on an Airplane

As I write this, everyone is freaking out over COVID-19. We know it is a highly contagious and dangerous disease, with particular risk to groups in a confined space such as an airplane or cruise ship. Researchers are scrambling to model the contagion risk, but detailed data is almost nonexistent. With a good model, you could create a decision service that would output the likelihood of a passenger contracting the disease if on a flight with an infected patient.

Using Decision Services

In recent posts I reviewed the use and benefits of BKMs and contexts for DMN modelers and stakeholders. This time we'll continue that theme with an explanation of another of DMN's woefully underutilized features, decision services. The introduction of decision service as a formal element in DMN came about in a surprising way. The spec's only real example of a decision model, a lending decision, featured a DRD meant to be executed in two or three steps.

Use Contexts to Simplify Your Decision Models

Last time I showed the value of Business Knowledge Models (BKMs), those misunderstood and often-maligned elements in DMN diagrams. In this post I'm going to try to do the same for contexts, another DMN feature that is similarly underappreciated and frequently disparaged by tool vendors that don't support them. Unlike BKMs, contexts are not DRG elements, meaning distinct shapes in the DRD. Instead, a context is a type of boxed expression, a standard tabular format for the decision logic of a decision or BKM.

Handling Complex XML Input in DMN

In a recent post, I showed how DMN could be used to model and execute decision logic on complex XML input data such as loan application information in MISMO format. The MISMO schema was envisioned as an enterprise data dictionary for the mortgage industry, standardizing the names of various information elements for use across any mortgage-related application. As such, however, it is effectively impossible to use MISMO data directly in decision models.