Beginning DMN modelers might describe a decision service as that rounded rectangle shape in a DRD that behaves similarly to a BKM. That's true, but it is a special case. Fundamentally, a decision service is the unit of execution of DMN logic, whether that is invoked by a decision in the DRD, a business rule task in BPMN, a decision task in CMMN, or an API call in any external client application or process.
Although DMN's expression language FEEL was designed to be business-friendly, it remains intimidating to many. That has led to the oft-heard charge that "DMN is too hard for business users". That's not true, at least for those willing to learn how to use it. Although the Microsoft Excel Formula language is actually less business-friendly than FEEL, somehow you never hear that "Excel is too hard for business users." One key reason why FEEL is more business-friendly than the Excel Formula language, which they now call Power FX, is its operators.
Lookup tables are a common logic pattern in decision models. To model them, I have found that beginners naturally gravitate to decision tables, being the most familiar type of value expression. But decision tables are almost never the right way to go. One basic reason is that we generally want to be able to modify the table data without creating a new version of the decision model, and with decision tables you cannot do that.
It's been over five years since DMN Method and Style 2nd Edition was published and a lot has changed since then. So I'm pleased to announce that DMN Method and Style 3rd Edition is now available. You can get the print edition on Amazon and other online bookstores, and you can order the e-book edition right here on my website. The new edition is based on the draft DMN 1.6 spec, which contains many features unavailable in the second edition of the book, which was based on DMN 1.
DMN is not optimized for machine learning algorithms, but it's good enough for simple problems such as fitting a straight line to a set of data points, known as linear regression. In this post we'll look at two ways to do it. Consider the table Dataset, a list of x-y pairs. Here x represents the number of members in a group health insurance plan, and y represents the administrative cost of the plan as a percentage of claim value.
Last month we discussed a valuable low-code implementation pattern using Business Automation Services to create event-driven database apps in the cloud. Upon receipt of a business event - a REST API call - the pattern involves a straight-through process that retrieves various database records, calls a decision service to generate additional records, and then inserts the new records in the database. The beauty of this pattern is that by using BPMN, DMN, and OData, subject matter experts can create executable implementations themselves without developer resources, greatly increasing business agility.
Most of my past posts about DMN have assumed that the reader knows what it is and may be using it already. But there is undoubtedly a larger group of readers who have heard about it but don't really understand what it's all about. And possibly an equally large group that have heard about it from detractors and have some misconceptions. So in this post I will try to explain what it is and how it works.
This month we return to a topic I've written about twice before, data validation in DMN models. This post, in which I will describe a third method, is hopefully the last word. Beginning decision modelers generally assume that the input data supplied at execution time is complete and valid. But that is not always the case, and when input data is missing or invalid the invoked decision service returns either an error or an incorrect result.
Often in decision models you need to calculate a date or duration. For example, an application must be submitted within 90 days of some event, or a vaccine should not be administered within 120 days of a previous dose. DMN has powerful calendar arithmetic features. This post will illustrate how to use them. ISO 8601 Format The FEEL expressions for dates, times, and durations may look strange, but don't blame DMN for that.
Recently I received a note from a longtime colleague newly employed at a financial services firm. "We've finally got our DMN server running, and we're looking now for user training," he writes. "I'm thinking a half to full day at our site." Hmmm... Even with a full day, you can't teach more than DRDs and decision tables. And if you want your team to do more than create business requirements for DMN to be handed off to developers, that's simply not enough.