As Jan and I work on our book, Available now! Real-World Decision Modeling with DMN, we have been discussing some of the common misconceptions about decision modeling that we’ve encountered among adopters. This is going to be one of the chapters in the book, in which we analyze misguided applications of decision modeling and their consequences, but I thought I would take a minute to discuss some of them. Decision modeling is a powerful, potentially transformative approach for organizations that approach it correctly. These misconceptions can really get in your way:
Misconception: Decision modeling only works for business rules
This is one of the most common and dangerous misconceptions— that the only reason to build a decision model is to manage decision logic expressed as business rules and, often, specifically the business rules automated in a Business Rules Management System. While decision models are very good at structuring and managing business rules, a singular focus on this use case means that organizations miss the benefit of using decision models for other purposes, for example to:
- Coordinate structure and improve the rigor of large decisions
- Train personnel in the execution of manual decisions
- Frame analytic project requirements
- Discover gaps in data availability
- Reveal inconsistencies and conflicts of responsibility in organization support for making pivotal decisions
- Promote consistency in decision making across multiple business channels
- Clarify the automation boundary of decision making
Misconception: Decision models are only complete if you can generate code from them
Decision models are complete when they are fit for purpose. This might be when you can generate code but might also be when you can fully describe a decision for training purposes, build an effective analytic, define decision making responsibilities across an organization, plan the incremental advancement of an automation boundary or structure the logic you are managing in a BRMS. The purpose for which you are using a decision model will dictate the extent to which its decision logic needs to be complete.
Misconception: Decision logic is what matters in DMN
A focus on execution can sometimes lead to the misconception that only the decision logic layer really matters in DMN. After all the majority of DMN specification is devoted to documenting this. The value of decision requirements modeling is downplayed, other than perhaps as a thinking tool. This misunderstanding can lead to the bad practice of adorning a process model with DMN decision tables to describe each piece of logic in the process, skipping decision requirements modeling altogether.
This is a dangerous misconception as it: misses the value gained by thinking about the decision as a whole—its structure and dependencies. It also embeds historical, inflexible and unnecessary sequences in the decision model while mixing elements of process and decision making that are better kept separated. Perhaps most importantly it focuses on the trees at the expense of the forest. We discuss this flawed approach to decision modeling in more detail in our book.
Misconception: Decision models are handed off to developers as a technical asset
Decision models are neither an implementation-centric IT asset nor a way to eliminate IT by allowing business analysts to build and maintain executable models in isolation. They are, in fact, a vehicle for effective business/IT collaboration—a jointly owned, evolving consensus of what decisions are to be made, how and why. Decision making expertise is a corporate asset that should not be buried in IT systems; it requires explicit capture, innovation and maintenance. Handing decision models off to developers for a ‘one-shot’ translation into code or trying to pretend that a sufficiently detailed, executable decision model can mean you don’t need IT are both equally dangerous and impractical propositions. Decision models are a precise vehicle for representing the requirements, structure and mechanism of decision making which can be maintained and innovated by business analysts, directly inform systems implementation and demonstrate compliance to a third party.
Misconception: Capture business rules first, decision will emerge from this
In addition, people get sometimes think that business rules should be captured first, independently of a decision model. They shouldn’t be as this is analogous to building a new house by starting with brick walls and doors. Part of the value of a decision model is that it’s a foundation: it structures, supports and scopes the capture and analysis of business rules. Trying to list all the rules without a decision model is just going to waste time and energy.
Decision modeling is a powerful concept—don’t be misled by these common misconceptions.
Available now! Real-World Decision Modeling with DMN
