An Introduction To Decision Modeling With DMN
An Introduction To Decision Modeling With DMN
contradictory or short descriptions that lack the necessary detail. All this has to be
sorted out during development, creating delays and additional costs.
By modeling the decisions identified, a clear and concise definition of decision-
making requirements can be developed. A separate yet linked model allows for
clarity in context.
“Decision modeling enables us to model our business by dividing it into concrete parts that are
understandable to business people without being too detailed. It also helps us not to lose sight of
the overall picture of the process while delving deep into the details of business rules.”
Timo Laukkanen, Process Director, Finnish Tax Administration
The decisions-first decision management approach begins with the higher level
concept of the decision. This provides:
A higher, overarching principle to impose some business oriented structure on
this complexity.
The separation of a declarative definition of these rules from the sequence-
oriented business process – improving both.
A structure that can be expanded in a series of iterations, allowing progress to
be made in a more agile and less waterfall approach.
Specifying a graphical decision requirements model based on the DMN standard
provides a repeatable, scalable approach to scoping and managing decision-making
requirements, making it easier to:
Draw the automation boundaries.
Re-use, evolve, and manage rules beyond the first business rules project.
Consolidate business rules across multiple implementations and platforms.
Assign ownership, governance and sources appropriately.
Decision Management streamlines and focuses business rules projects for faster,
more effective deployment. Learn more in our white paper, Maximizing the Value of
Business Rules.
In both cases, then, it is essential to first define the decision-making required and
only then focus on details like the specific business rules or predictive analytic
models involved. Specifying a decision model provides a repeatable, scalable
approach to scoping and managing decision-making requirements for both business
rules and analytic efforts.
will require them to escalate to supervisors. What business analysts have lacked
until now is a standard, established way to define these requirements.
Enterprise Architects meanwhile are chartered with fitting business rules and
analytic technologies like data mining and predictive analytics into their enterprise
architecture. A service oriented platform and architecture, supported by integration
and data management technology does not have obvious “holes” for these
technologies. Decisions are both the shared framework and the technical
mechanism to easily implement these technologies.
Decision modeling is a powerful technique for business analysis and for enterprise
architecture. Using the standard DMN notation to specify Decision Requirements
Diagrams and so specify a Decision Requirements Model allows the accurate
specification of decision requirements. Decision Modeling is also central to Decision
Management, a proven framework that ties business rules and analytics to business
objectives.
Most process models today are developed using the Business Process Model and
Notation (BPMN) standard published by the Object Management Group. The
DMN standard has been designed to work alongside BPMN, providing a
mechanism for modeling the decision-making represented in a Task within a
process model. DMN need not be used with BPMN but it is highly compatible.
“What used to be one week of requirements work was done in a few hours with decision
management.”
Lead Business Analyst, North American Insurance Company
This process repeats until the Figure 1: Iterative Decision Modeling Cycle
decisions are completely
specified and everyone has a
clear sense of how the decisions
will be made.
At this point you can generate a
requirements document,
packaging up the decision-
making requirements you have
identified. This can act as the
specification for business rules
implementation work or for the
development of predictive
analytics.
Alternatively you can extend the
model with decision logic, such as decision tables, to create an executable
specification of your decision-making.
For a detailed discussion of decision modeling with DMN, download our white
paper Decision Modeling with DMN.
Identify Decisions
Decisions are identified as part of the overall requirements gathering process.
Decision-making appears in business processes, in use cases or as a specific
requirement. Not every decision is equally appropriate for decision modeling as we
will see in the Suitable Decisions for Decision Modeling section and as you iterate you
will also identify additional decisions.
Describe Decisions
Decisions are the core of the Decision Model and Notation
standard. Decisions are shown using a simple rectangle that
contains the name of the decision.
A Decision Requirements Diagram contains one or more Decisions and it is
common to create one such diagram for each area of focus on the project. Critical
information is captured about each Decision:
Question and Allowed Answers.
Business context.
Organizational context.
Application context.
A decision model also puts decisions in context by linking them to the KPIs and
objectives they impact, the organizations involved in the decision-making as well as
the processes and systems within which the decisions are made.
The value of BKMs in allowing reuse is real when one is trying to store the
implementation definition outside the BRMS and then generate code for it. If you are
linking directly to a BRMS for implementation, then BKMs are unnecessary.
For more information, download our Best Practices Brief, Knowledge Objects in
DMN.
Tactical Decisions
Regular tactical decisions
involving management and control are also made. There is generally still time and
energy for significant analysis but there is time pressure too, a need for consistency
and the opportunity to learn what works.
Operational Decision
Finally, every organization makes large numbers of operational decisions about
individual transactions or customers. Time pressure is often extreme and these
decisions must generally be embedded into operational systems and processes.
Decision Categories
We can categorize operational decisions into various types, though some decisions
include characteristics of several types. For instance:
Eligibility or Approval—Is this customer/prospect/citizen eligible for this
product/service?
Validation—Is this claim on invoice valid for processing?
Calculation—What is the correct price/rate for this product/service?
Risk—How risky is this supplier’s promised delivery date and what discount
should we insist on?
Fraud—How likely is this claim to be fraudulent and how should we process it?
Opportunity—What represents the best opportunity to maximize revenue?
Maximizing—How can these resources be used for maximum impact?
Assignment—Who should see this transaction next?
Targeting—What exactly should we say to this person?
Decision Services
Having identified high- Figure 3: Decision Services At The Center
ROI operational
decisions and modeled
them so you know what
to do to improve them,
your next step is to
design and build an
automated decision
making solution. The aim
is to create independent
Decision Services to
replace the decision
points currently
embedded in business
processes and
operational systems.
Learn More
We offer a comprehensive set of white papers, webinars and other education
materials See the Reference section for suggested further reading.
Hands-On
Get started quickly with decision modeling. Go to www.decisionsfirst.com for
information about our decision modeling software DecisionsFirst Modeler. Our
online DecisionsFirst Support site includes free tutorials and training videos.
Training
Register for our IIBA Endorsed live online training courses. Email us at
[email protected] for information about IIBA member
discounts. See our website for session dates.
Free Consultation
We offer strategic guidance on when, where, and how to adopt Decision
Management and Decision Modeling best practices and technologies, coupled with
concrete tools for becoming analytically-driven.
We are one of the most experienced decision management and decision modeling
consultants and trainers in the world. Many of our clients use our decision modeling
software DecisionsFirst Modeler and many do not – our approach and training are
vendor neutral. We are also one of the original submitters of the Decision Modeling
and Notation (DMN) standard. Contact us for a free consultation today.
References
Other Publications
Taylor, James (2011). Decision Management Systems – A Practical Guide to Using
Business Rules and Predictive Analytics. IBM Press.
DeBevoise, Tom and Taylor, James (2014). The MicroGuide to Process and Decision
Modeling with BPMN/DMN.
DMN Standard
Object Management Group. Decision Model and Notation (DMN) Specification 1.0
Current version at http://www.omg.org/spec/DMN/Current
1.1 is approved but not yet publicly available
Contact Us
Email : [email protected]
Phone : +1 650 400-3029
Web : www.decisionmanagementsolutions.com