Today the world of decision management finds itself in roughly the position of business process management a decade ago: A shrinking number of highly optimized tools and runtime engines, each with its own modeling notation and execution language, struggling with inefficient translation of “business requirements” into executable decision logic. The solution then for BPM vendors was to unify modeling and execution in a single tool-independent language based on a standard diagramming notation. Just as BPMN created a new era of process management back then, we now stand at the doorstep of a new decision management era based on DMN, the Decision Model and Notation standard from OMG. As with BPMN 2.0, it has taken a year or so for tool vendors to fully implement the standard in working software. But now a few such implementations have been released, and more are on the way. The new era is beginning, and it’s time for you to begin thinking about how to adapt your decision management practices, or how to initiate a new one.
In the old era, everything depended on which tool you were using: the modeling notation and methodology, the execution language, even the basic terminology of decision management. Available education, training, consulting and support services likewise were specific to a particular vendor offering. That works only until a better alternative comes along, and with DMN we now have that. With DMN, the decision modeling notation is tool-independent. The meaning is defined in a spec, not in tool-specific documentation. That means there are many sources of information about it, including free articles on the web, an increaing number of books, and hands-on training courses from independent consultants and educators.
Even better, the decision models you create are more than business requirements handed over to programmers using a different decision language. DMN models are directly executable, not only in the modeling tool for testing purposes, which is critically important on its own, but in production. Now think about this for a minute: The decision models created by “the business” – analysts and regular business users – do not need to be translated by programmers into some foreign execution language. With DMN, what you model is what you execute. And here is something that many established rule engine vendors still have not grasped. DMN is not for “toy” decision models. It’s designed for real, mission-critical work, and it won’t be long before DMN decision engines achieve the same level of runtime performance as proprietary rule engines.
One more nail in the coffin of “traditional” decision management: DMN models, although defined graphically, can be interchanged between tools using an XML format defined by the standard. That means no more vendor lock-in. Even with a standard decision language, there will be plenty of differentiation among tools, including ease of use, methodological “guardrails” for business users, runtime performance, and “whole product” features such as governance, glossary, and so forth. Going forward, if you change tool vendors, you will be able to bring your existing DMN models along with you.
All of this means the practice of decision management is changing. It’s now about learning a standard language, not a particular tool. And it’s about more directly involving business users in what have traditionally been thought of as IT projects. The business has long complained about long implementation cycles and low user acceptance when decision requirements are handed off to IT. With DMN, business can now play a more direct role. With DMN they can test their requirements themselves and verify them for completeness and consistency. The BPMN experience has shown that more direct business involvement does lead to a more efficient and agile implementation style. But that comes with a price. It requires decision management practitioners on the business side to invest in a bit of training and follow a more disciplined methodology.
Every organization with a stake in decision management needs to begin exploring this new era. Look for tools that fully implement DMN. That means not only decision requirement diagrams (DRDs) and decision tables, but DMN’s standard expression language FEEL and all the “boxed expression” types, standard tabular formats for handling complex decision logic. That also means the ability to execute the models you create, both in the tool and deployed to a production engine. And ideally that also means the ability to interchange models using standard DMN XML.
Effective use of such a tool, especially by the business, also requires a bit of training, ideally hands-on in the tool. While you can learn how to understand DMN models by reading a book or article, to create models yourself you need to be hands-on. In addition to learning the language of DMN and the mechanics of creating it in a tool, the training ideally should provide some kind of methodology to help modelers frame their conceptual understanding of the decision logic in DMN terms.
Of course, this is all decision management in the abstract. Real organizations want to begin applying it from the beginning to their own specific scenarios. That is often easiest with a short consulting engagement to get started with the DMN tool and runtime, leading to a small pilot project to get a sense of the difference between the “new era” of decision management and the traditional tools and methods. And this applies even to organizations new to decision management, possibly those who have been using BPM and wondering how standards-based decision management might further improve efficiency and business agility.
These are the three essential elements: software that fully implements DMN, training on the language and a business-oriented methdology, and a pilot project, assisted if necessary by a short engagement. With this modest investment, your organization can get a great head start on this new era.