I read with mixed feelings Larry Goldberg's post "Just Not FEELin It". Larry is the one who introduced me to decision management a decade ago. He was the first to promote a strict methodology for business users creating model-driven decision requirements, which is essential. So he is a very smart guy, and I respect his opinion. That is why his blanket dismissal of DMN's key features - FEEL (and, by implication, boxed expressions) - was so disappointing.
Last month I showed why Trisotech is a great Low-Code Business Automation platform, based on its use of FEEL and boxed expressions in executable BPMN. How ironic is it, then, that many decision management vendors don't even include those features in their DMN tools! The only part of DMN they use is the Decision Requirements Diagram (DRD), but what is the point of using a standard diagram to describe business requirements that are not even testable?
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.
Students in my BPMN Method and Style training are often befuddled by how to start a process. I see Conditional events, Error events, all kinds of things. No, stop! While the BPMN spec provides many different types of start events, only three of them are relevant to the non-executable flows most modelers are trying to create. In Method and Style, those are the only ones allowed. This post will explain. Just Three Ways to Start There are really only three ways to start a process: On external request.
In my previous posts on Business Automation, my focus has been on straight-through processes, since this is the sweet spot of the Trisotech platform. But even there, occasionally you need some human input, and that is where User tasks come in. User interaction is not a primary consideration in Trisotech BPMN, so the User task implementation is fairly basic. Even so, how to model User tasks confused me until recently. I think this is because of some default shortcuts in the modeling intended to simplify things.
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 "
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.
BPMN has a way to say an activity should be performed more than once. In fact, it has multiple ways, and students in my BPMN Method and Style training sometimes get them confused. This post will clear things up. A Loop activity is like a Do-While loop in programming. It means perform the activity once - it could be either a task or subprocess - and then test the loop exit condition, a Boolean expression of process data.
In BPMN, the most common way information is provided to a process from an external source is via a message. Incoming messages are indicated in the diagram by a dashed arrow connector called a message flow, with its tail on a black-box pool or a message node in another process pool and its arrow on a message node in the receiving process, either an activity or message event. In our BPMN Method and Style training, which focuses on non-executable processes, we discuss at length the semantics and usage patterns of messages and message events.
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.