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.
It's true that to a number of vendors who claim DMN support, that is enough, because DRDs and decision tables are the only part of DMN that they have implemented. Officially per the spec, that is enough to legitimately claim "Level 1 compliance" with the standard. But all you can do with that is create decision logic requirements, not executable decision services. I don't mean to say the ability to decompose some complex business logic into a DRD with defined datatypes for all the elements has no value. It certainly does. But don't kid yourself... that's just requirements, not a decision model.
While real DMN - not just DRDs and decision tables, but boxed expressions and FEEL - was designed for use by subject matter experts and business analysts, there is quite a lot to learn, substantially more than for BPMN. For that reason, when I began to offer DMN training several years ago, I split it into two courses, Basics and Advanced. Basics just covered DRDs and decision tables; Advanced covered boxed expressions and FEEL. Most people just took Basics, but I realized from doing customer engagements you cannot do anything real in DMN with only that. So I combined them in a single course, and I am much happier with that. As I've discussed previously, not every "business user" can do it. It requires a basic understanding of data and expressions, for example. If you can use the Formulas ribbon in Microsoft Excel, you can do it. (In fact, I have demonstrated previously why boxed expressions and FEEL are actually more business-friendly than the Excel Formula language, Power FX.)
So how much DMN is enough? If you want your team to be able to create real-world DMN models, they need to be able to do the following:
- Define datatypes using FEEL. For the most part, variables in DMN models are defined simply by the labels of the decisions and input data elements in the DRD. But the label is simply a name. You also need to be able to specify its datatype. FEEL defines a number of base types, and allows users to define custom types by applying constraints - such as enumerated values - to a base type or defining structured data containing components.
- Specify decision logic using FEEL literal expressions, i.e. a formula in DMN's standard expression language. Just like Power FX, FEEL provides a long list of built-in functions for manipulating text, numbers, lists, and dates, and you need to know how to use them.
- Define custom functions as BKMs. The built-in functions just cover low-level operations. BKMs are parameterized decision logic, reusable modeler-defined functions.
- Use context boxed expressions. A context boxed expression is a standard tabular format with two distinct uses.
- The first is simplifying complex literal expressions by breaking them down into simpler pieces. Each row of the table, or context entry, defines a local variable and its formula. Subsequent rows can reference previous context entries, and the final result box is typically a simple expression of those local variables.
- In the second, the final result box is empty, and each context entry defines a component of a data structure. This is the normal way to construct and manipulate structured data.
- Manipulate lists and tables. Real-world decision models almost always involve lists and tables. A table in DMN is just a list of some structured type. To be competent in DMN, the user needs to understand FEEL's list functions and operators, including filters and iteration.
- Perform calendar arithmetic. Real-world models also often involve dates and durations, and you need to understand how to manipulate them using FEEL.
In our DMN Method and Style training, we show you how to do something, and then there are exercises for students to do themselves. Then we look at the solution. Did you do it correctly? Students need that feedback to confirm whether they really understood it the first time. This is the key difference between reading about DMN and hands-on training. And even after all the sections of the training, the datatypes, FEEL literal expressions, BKMs, contexts, lists and tables, calendar arithmetic and the rest, there is one more step. To be certified, students have to create a decision model containing a number of required elements for my review. If it's not perfect, I point out the errors and the student must resubmit. It is actually through that process of fixing the errors that the student becomes a competent DMN modeler.
Now, can you do all that in one day on-site? No way. Maybe with a really sharp group of students it would be possible in 3-4 days, except for the certification model. But given the range of skills within most teams, it is extremely difficult to deliver this training live to a group. There is simply too great a disparity in the speed of doing the exercises. The class would move too quickly for some, too slowly for others. The best mode of DMN training I have found is web/on-demand, where each student progresses at his or her own speed. The DMN Method and Style course gives students 60 days to complete the training and certification requirements. Certified students are listed on the website and can legitimately be considered competent DMN modelers.
Interest in DMN is taking off. Many of your business users can do it, but there is a lot to learn. For more information on the training, go to methodandstyle.com.