As a longtime DMN practitioner and from the beginning one of its biggest boosters, I am what you call a true believer. But while DMN continues to gain traction, even I would have to admit it has so far underperformed in the marketplace. The industry analysts say, “OK, we’re aware of it… But what’s the killer app?” It may not be what you think.

In the Beginning

Let’s go back to the beginning. In 2016, DMN was brand new. I had been posting about it, and I was invited to introduce it to the Decision Camp audience of decision management vendors and practitioners that year. As standards go, DMN was unusual: an executable modeling language designed for use by subject matter experts in a way that standards like BPMN were not. Executable logic would be defined graphically, using a set of standard tabular formats called boxed expressions, with a new business-friendly expression language called FEEL used in the table cells: Executable models without programming.

At that time, DMN was just a spec. There were no runtime implementations. But I also noticed that among tool vendors on the DMN 1.1 Task Force, which I had recently joined, there was no great urgency to implement it, and in my talk I complained about that. Of course, it was the things that made FEEL and boxed expressions business friendly that also made them difficult to implement: spaces in variable names, for example, and tables nested, potentially without limit, inside other tables.

But at that meeting, Mark Proctor of Red Hat told me, “Dont worry, my guy will have a DMN runtime in 6 weeks.” It actually took his guy, Edson Tirelli, more than 6 months, but it worked very well, and Red Hat made the FEEL parser and DMN runtime open source. So by 2017 we had an open source runtime, and there was little excuse for tool vendors not to fully implement DMN.

A few did, but most Decision Management vendors continued to resist FEEL and boxed expressions. In fact, they questioned the original premise that business users really wanted to go beyond defining requirements handed off to programmers. Or, if they did, that they had any interest in basing that on the DMN standard even though those had been central to the original DMN RFP.One vendor that did believe in the original premise, as I did, was Trisotech, and I soon moved my DMN training to their platform, which was aimed squarely at non-programmers.

Lets fast forward to today, 6 years later. The DMN standard continues to get better, every year a new version. But still, few tool vendors have implemented it beyond DRDs and decision tables. Interest in my DMN training has increased, but it is only now catching up to my BPMN training, which is focused on descriptive, that is non-executable, models. Its a little discouraging.Yet despite all that, I am more hopeful today than ever about the promise of DMNs key features FEEL and boxed expressions. And thats because they are the keystones of what I believe is a far larger opportunity.

What You Draw Is What You Execute

Back in 2010, the process modeling standard BPMN 2.0 promised business users, “What You Draw Is What You Execute.” I used to say that myself.

But not really. What makes a process model executable are the services implementing the tasks, and the process data and expressions used to orchestrate them. But for those things, BPMN has always required programming. That standard provides nothing like FEEL and boxed expressions for non-programmers. While the activity flow semantics can be defined by business users in diagrams, making those diagrams executable has always required Java programming. So diagrams created by business and handed off to programmers for implementation has been standard practice in Process Automation for a dozen years now.

A few years later, DMN set out to be different from that. If you are unfamiliar with OMG standards, they start with an RFP that lays out the objectives of the standard. And DMN was distinctly different from BPMN in that it wanted to enable business users to do more than create requirements handed off to programmers. To that end, the DMN standard itself defines a graphical Low-Code language for decision logic implementation: a set of standard tabular formats called boxed expressions and a friendly expression language for the table cells called FEEL. Although DMN allows tools to assert so-called Level 1 conformance without supporting FEEL and boxed expressions, FEEL and boxed expressions comprise the bulk of the DMN spec: the syntax, semantics, operational behavior and graphical formats.

Unfortunately, most decision management vendors especially those who formerly called themselves business rule engine vendors failed to adopt FEEL and boxed expressions, preferring the traditional arrangement in which business creates requirements handed off to IT for implementation in some proprietary language, and they continue to do so today although in so doing, they ignore the original promise of DMN.

Its important to understand that decision logic is more than decision tables. For example, it must refine raw input data into the variables that are used in the decision tables. FEEL and boxed expressions not only do that, but represent a complete Low-Code language suitable for any kind of business logic, not just that related to operational decisions. Even though FEEL and boxed expressions are defined within the DMN spec, their utility extends far beyond the boundaries of traditional decision management.

For example, over the past two years, the Trisotech platform has quietly been adding Automation capabilities to its BPMN models in a different way, a Low-Code way, leveraging FEEL and boxed expressions borrowed from DMN. By now that Business Automation platform is quite complete. So this goes beyond business users creating decision services. This is enabling them to create full-fledged Business Automation services themselves, graphically, so that What You Draw actually IS What You Execute.

Low-Code Business Automation

I use the term Business Automation to mean the combination of business logic automation and process automation, and DMN combined with BPMN offers a Low-Code approach to it based on standards.. If Subject Matter Experts learn to create decision models using DMN with FEEL and boxed expressions, its just a small additional step to do Low-Code Business Automation themselves: model, test, and cloud deploy as a REST service no programming required.

Low-Code means model-based software development, accessible to technically inclined business users, as well as to developers. The fact is, interest in Low-Code Business Automation is exploding; Gartner says 65% of all solution development will be Low-Code by 2024.Thats an addressable market larger by orders of magnitude than Decision Management. The key benefits: time to value model-driven development is simply faster than code – and avoiding the IT resource bottleneck, since subject matter experts can do much of it themselves.

That is why I see these DMN features FEEL and boxed expressions, which have frankly languished in the world of Decision Management – as the key to something new and exciting today, an opportunity that is much larger than Decision Management. Actually Low-Code Business Automation is DMNs killer app.

Why is this opportunity happening now? The fact is, over the past six years, the software world has changed completely:

Example:
Vacation Request Process

Let’s see how Low-Code Business Automation with DMN and BPMN works, and then go back to key questions that have dogged Decision Management vendors from the start: Do business users really want to do this? And does basing the tools on standards make a difference?

Here is an example of a Vacation Request process as it would be modeled using my non-executable BPMN methodology called Method and Style. Not a core business process but illustrative. Its very simple. A Vacation Request is processed by decision logic that either automatically approves it, refuses it, or refers it to the manager. If ultimately approved, the requested days are deducted from the employees accrued vacation time.

And here is the executable version of it using Low-Code Business Automation: The BPMN is similar but the activities now are more fine-grained, the icons in the top left corner indicating specific capabilities of each task type. But the most obvious difference is the model now includes process data and data flow.

• The dog-eared page icons, called data objects, represent the process variables. In Low-Code Business Automation, FEEL defines the data language the datatypes and expressions. In the runtime environment, FEEL is converted to json automatically by the platform. FEEL and json types are actually quite similar.
• The dotted arrows, called data associations, represent mappings between the process variables, which are defined by the process modeler, and task variables, most of which are defined by each invoked service. In Low-Code Business Automation, those mappings are defined using FEEL and boxed expressions.
• The activities with the spreadsheet icon, called decision tasks, invoke DMN decision services. As I mentioned, DMN is in reality a Low-Code language that can be used for ALL modeler-defined business logic, not just what we normally call decisions. Here we have two decision tasks: The first one validates the data input Vacation Request to avoid runtime errors; the second one is the automated approval logic.

Decision Tasks

A BPMN decision task is bound to a DMN decision service.

Here you see the data input validation decision. DMN is actually an excellent language for data validation. A Collect decision table, hit policy C, produces a list of error messages. Data validation logic typically uses some of the lesser known FEEL functions and operators: generalized unary tests and the instance of operator, as you see here, also the get entries function, which lets you test all components of a structure at once, and match, for pattern matching with regular expressions.

Just to repeat, DMN is not only about decision tables. Its a Low-Code language for any business logic. For example, the Vacation Request specifies the employees requested start and return date, but the approval logic requires knowing the count of requested days. FEEL has excellent support for calendar arithmetic, but finding the count of requested days is a little complicated. We cant simply subtract the dates; we need to exclude weekends and holidays as well.

This boxed expression is called a context. It lets you break up a complex value expression into pieces using local variables something most other Low-Code languages cannot do. For example, here there are 5 context entries, each defining a local variable and its value expression, and the final result expression references those local variables. Note that the fourth context entry uses a decision table, an example of a table nested in another table. Context boxed expressions let you make complex logic business friendly without cluttering up the DRD with dozens of tiny decisions.

In the DMN model, a decision service defines the parameters called by the BPMN decision task. The decision service outputs are selected decision nodes in the DRD, and the tool calculates the required service inputs. Here the service Validate Vacation Request has input parameters Vacation Request and Original Employee Record, and output parameters Validation Errors and Employee Record.

In BPMN the Decision task Validate Vacation Request is bound to that decision service. The task inputs are by definition the decision service inputs, and the task outputs are the service outputs.In the process model, the dotted arrows, called data associations, represent mappings between the process variables, here called Vacation Request and Employee Record, and the task inputs and outputs. So from the diagram you see there are input mappings from Vacation Request and Employee Record and an output mapping to Validation Errors.

Since all data is represented as FEEL in the modeling environment, the mappings use boxed expressions and FEEL, similar to a boxed invocation in DMN. Here the mappings are essentially identity mappings, but any FEEL expression can be used.

Service Tasks

An activity with the gear icon, called a service task, calls an external REST service. Simply bind it to a REST operation in the models Operation Library and map process variables to the service inputs and outputs.

EmployeeVacationData is a MySQL database table on my website. It holds the employees accrued vacation time.A third party service, Skyvia Connect, introspects the database and generates a REST endpoint for it and a metadata file used to configure a Trisotech connector, exposing 5 database operations on the table using OData. We will use the Find, or query operation, to retrieve the record for the requesting employee.

We bind the service task Get Employee Data to the Find, or query operation of this endpoint in the Operation Library.Then we model mappings between process variables and the service input and output parameters using FEEL and boxed expressions. Here the data mapping for the input parameter $filter uses a FEEL expression to create a query string in the OData language.

Once were done, the whole Vacation Request process is itself deployed as a REST service in the Trisotech cloud. This Business Automation service can be called by any REST client app with the appropriate credentials.

Hopefully this gives you the flavor of how subject matter experts can create Business Automation services using FEEL and boxed expressions without programming!

Where Can We Use This?

What kind of Business Automation services can make use of this? Currently the Trisotech platform is used most heavily in integration-centric processes in healthcare and financial services. Digital mortgage underwriting is a great example, as there are many complex rules. You might say thats a straight decision management problem, but its really a process. You need to first get the data from various sources, validate the data, transform it to testable values, apply some decision logic, and finally format and store the output. Low-Code Business Automation can do all that in a single composite service.

I am currently working with a large accounting firm to create general ledger entries triggered by business events related to financial portfolio assets and trades. Its high-volume, involves many database tables, a lot of computation perfect for DMN and BPMN.With Low-Code, solutions like these are much faster to build, test, and deploy than with Java, and easier to maintain.

So who can create apps like these? I admit its not every business user or subject matter expert. Most of my BPMN Method and Style students probably could not do it very well. But anyone who can create executable decision models using FEEL and boxed expressions certainly can. You need to have some basic facility with data and expressions, and the patience to debug when things dont work right the first time. Thats just a subset of business users, but in most companies, subject matter experts who can do that still greatly outnumber programming staff. Microsoft used to call them citizen developers; now they are calling them software makers, a term I like better.

To turn subject matter experts into makers, I had to completely revise my DMN training. Originally I had a course DMN Basics that focused on DRDs and decision tables, since thats all most DMN tools supported and Its something every business user can understand. The problem is you cannot do anything useful with only that except to provide requirements handed off to others. In the revised training I focus on FEEL and boxed expressions. Those are the critical elements. And yes, subject matter experts who are not programmers can learn to understand and use them well. You just have to show them how. They feel empowered, because they ARE empowered. Once you fully understand DMN, Low-Code Business Automation is mostly a matter of learning how to find and orchestrate REST APIs.

DMN vs Proprietary Low-Code Languages

OK, youre saying there are already a large number of Low-Code Business Automation tools available. Thats true. Basically all of them use their own proprietary scripting for the Low-Code piece, just as many Decision Management vendors use their own proprietary rule languages, which they also say are business-friendly.

But FEEL and boxed expressions are not only non-proprietary, they are actually more business friendly and often more powerful. For example, FEEL and boxed expressions make DMN more powerful and more business-friendly than Power FX, Microsofts Low-Code expression language used in Excel formulas and Microsoft PowerApps. Without boxed expressions like contexts, Power FX must pack complex logic into a single literal expression. And Power FXs lack of infix operators makes these expressions deeply nested functions that are difficult to understand.

For comparison, here is an example published by Microsoft marketing showing how Power FX can extract the last word in a string. They were very proud of this So, lets see, Is that 4 or 5 right parens at the end?Below it is the equivalent in FEEL: The split operator tokenizes the input string based on the space character and [-1] means take the last item. Now you tell me, which is more powerful AND more business friendly?

So why are DMN users not demanding their tool vendors support FEEL and boxed expressions?

The Larger Opportunity

That lack of support from incumbent vendors is why I have come to doubt that Decision Management is the best opportunity for DMN. A better opportunity is Low-Code Business Automation.

And this takes us all the way back to the original question:Do subject matter experts really want to create executable solutions themselves? Not all, obviously, but an increasing number of them do, and their employers today desperately need to acquire low-code tools and expand their pool of software makers. And even for professional developers, Low-Code is faster, easier to maintain, and more transparent to the business.

That is why I am becoming increasingly optimistic about engaging the Business Automation community with Low-Code Business Automation using BPMN and DMN. Its a far larger addressable market than Decision Management, its growing, and its perfectly matched to todays architecture based on the cloud and REST APIs.

But we know there are other Low-Code alternatives. So do they want to do it using standards, i.e. DMN in combination with BPMN? That is DMNs most obvious differentiator right now vs other Low-Code languages. Here are two reasons why they would.

• First, BPMN is widely used by business already for descriptive models. Whats been missing in the BPMN world is a way for non-programmers to automate their processes. Now integration with DMN offers them a way to do just that by creating executable business logic without programming, and orchestrating the many REST APIs that are now available.
• Second, BPMN users already recognize the value of using a vendor-independent standard. DMN, like BPMN, is an OMG standard, and the two standards were designed to work together. DMN has a published spec, governed through a vendor-neutral process, continually maintained and updated. It is supported by multiple tools. You are not locked in to a single vendor. There is a model interchange format, so business users and developers can use different tools. There is an open source runtime for it. There are multiple sources of information and training on how to use it. There is even a TCK that validates correct execution semantics.

So ideally,
what should happen now?

• Id like to see more DMN tool vendors include support for FEEL and boxed expressions, although Im not too confident that will happen.
• In addition, Id like to see new Low-Code Business Automation platforms emerge, likely focused on specific industry segments, that adopt FEEL and boxed expressions. Im seeing service providers in healthcare and financial services begin to explore moving to offer software solutions built with this Low-Code approach. An open source FEEL runtime is available, and this is now an IBM product, so maybe that will help.
• Existing DMN tools like Trisotech continue to add features that make it even more powerful and easier to implement, such as a graphical debugger and support for importing powerful function libraries.
• And of course, endorsements by industry groups are in principle helpful. We have those from BPM+ Health in the healthcare space and MISMO in the mortgage space, and hopefully those will lead to increased adoption in those industries. So well see.

What started as an effort to enable subject matter experts to create decision logic themselves, while so far resisted within the digital decisioning community, could ultimately find a better path forward in Low-Code Business Automation.

For anyone interested in the tools and techniques used in this approach, there is a lot of information on methodandstyle.com. I offer online training in DMN, focused on FEEL and boxed expressions, and in Low-Code Business Automation, and there is a bundled offering at a discount. Each course includes 60-day use of the Trisotech platform and post-class certification.