[This post is my presentation at Decision Camp 2022, delivered September 27, 2022.]
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, "Don’t 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.
Let’s 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. It’s a little discouraging. Yet despite all that, I am more hopeful today than ever about the promise of DMN’s key features – FEEL and boxed expressions. And that’s 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. And 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.
It’s 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, it’s 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. That’s 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 DMN’s killer app.
Why is this opportunity happening now? The reason is that over the past six years, the software world has changed completely:
- Reason Number one – the cloud. The cloud has revolutionized software, both tools and runtime. Large enterprises have largely overcome their resistance to putting critical data in the cloud. In addition to its well-known benefits to IT, the cloud makes Business Automation tools and runtime directly accessible to business users. They don’t need to wait for IT to provision or maintain the tools or the runtime. The Trisotech platform, for example, is entirely cloud-based and business-user-focused. In one click BPMN and DMN models are compiled and deployed as REST services in the cloud.
- Reason #2: REST APIs. Today you can find a public REST API for just about anything you need. You don’t have to build it, someone has already done it. It’s there, accessible to you via a simple web message. Aggregators like RapidAPI.com provide a centralized search, subscription, and SDK for thousands of public REST APIs. In addition, standards like OData allow you to generate REST APIs for your own applications and databases. For example, Skyvia Connect generates OData endpoints for over 100 apps and databases. Each endpoint exposes 5 REST operations per database table. And on the Trisotech platform, DMN itself generates a REST API for ANY business logic you create yourself, and BPMN similarly generates REST APIs for your executable process logic. So today REST APIs are everywhere. Business Automation is really just orchestration of services, some created by you, but mostly created by others.
- Reason #3 is Covid and its aftermath, the current labor shortage. It is nearly impossible today to hire skilled programming resources. So getting new projects off the ground just takes too long. But what if you could teach subject matter experts to create solutions themselves? That’s what the current excitement over Low-Code and No-Code tools is about. No-Code is used primarily for situational apps in HR and CRM. I’m more interested in Low-Code – logic equivalent to a DMN decision model – that in combination with the cloud and REST APIs can automate critical core business activities in financial services and healthcare.
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. It's not a core business process but illustrative. It’s 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 employee’s 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.
Decision Tasks
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.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. It’s a Low-Code language for any business logic. For example, the Vacation Request specifies the employee’s 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 can’t 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 more 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 model’s Operation Library and map process variables to the service inputs and outputs.
EmployeeVacationData is a MySQL database table on my website. It holds the employee’s accrued vacation time. A third party service, Skyvia Connect, introspects the database and generates a REST endpoint for it along with 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 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 we’re 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 that’s a straight decision management problem, but it’s 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. It’s 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 it’s 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 don’t work right the first time. That’s 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 that’s all most DMN tools supported and it’s 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, you’re saying there are already a large number of Low-Code Business Automation tools available. That’s 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, Microsoft’s 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 FX’s 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, let’s see, is that 4 or 5 right parentheses 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?
- It’s mostly lack of awareness. Most of what other folks write about DMN just talks about DRDs and decision tables. Possibly even many of you here at Decision Camp were not aware of what FEEL and boxed expressions can do.
- It’s also the need for training. You need to learn the language. Developers can generally learn from books and articles, but business users by and large cannot. They need training, a methodology that leads them through it step by step, and it must be hands-on using the tools. That’s an investment in money and time, definitely a barrier.
- As everyone here knows, Automation is unforgiving. If the slightest thing in your model is wrong you will get an incorrect output or worse, a runtime error. So Automation requires debugging, and not all business users have the patience or discipline for that.
- But a major reason also, probably the most important reason, is the determined resistance from Decision Management vendors. Even though DMN is a standard, most vendors on the Revision Task Force still do not support it beyond DRDs and decision tables. FEEL is too hard, they say. Business users don’t want to create implementations, just requirements. They say it all the time. FEEL and boxed expressions are a distraction, not fundamental to DMN. We even heard this last year at Decision Camp.
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. It’s a far larger addressable market than Decision Management, it’s growing, and it’s perfectly matched to today’s 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 DMN’s 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. What’s 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.
- I’d like to see more DMN tool vendors include support for FEEL and boxed expressions, although I’m not too confident that will happen.
- In addition, I’d like to see new Low-Code Business Automation platforms emerge, likely focused on specific industry segments, that adopt FEEL and boxed expressions. I’m 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 we’ll see.
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.