Publications by James Taylor and Neil Raden^[2], Barbara von Halle and Larry Goldberg^[1], Ron Ross^[7], and others have popularized "Decision Modeling."  The very short summary is that this is about modeling business decision logic for and by business users.

A recent Decision Modeling Information Day conducted by the Object Management Group (OMG)^[4] showed considerable interest among customers, consultants, and software vendors.  The OMG followed up by releasing a Request for Proposals (RFP) for a Decision Model and Notation (DMN) specification.^[5]  According to the RFP,

"Decision Models are developed to define how businesses make decisions, usually as a part of a business process model (covered by the OMG BPMN standard in Business Process Management Solutions).  Such models are both business (for example, using business vocabularies per OMG SBVR) and IT (for example, mapping to rule engines per OMG PRR in Business Rule Management Systems)."

This quote says a little about how DMN may relate to SBVR^[6] and BPMN^[3], but there are many more open questions than answers.  How do SBVR rules relate to decisions?  Is there just one or are there multiple decisions per SBVR rule?  Is there more to say about how SBVR and DMN relate to BPMN?

This article attempts to "position" DMN against the SBVR and BPMN specifications.  Of course, DMN doesn't exist yet so the concepts presented here are more the authors' ideas about how these three specifications should relate to each other, than reality.  We present these ideas in the hope that they will positively influence the discussions that lead up to the DMN specification.

What is Decision Modeling?

Three main steps are involved in decision modeling:

1. Start with the decision to be made by considering "What is the question to be answered?"
2. List the inputs (considerations) required to answer the question.
3. List the various possible combinations of consideration values and the corresponding outcomes (conclusions).  This answers the question "How does the conclusion depend on the considerations?"

Repeat the three modeling steps in an iterative decomposition process:  for each of the considerations that is not immediately-observable data, evaluate what is needed to produce the consideration as a conclusion of a sub-decision.  Continue iterating until all of the considerations can be grounded in data that is available without further sub-decision.

Consider, for instance, a video store that takes mail orders.  The rules that dictate whether or not an incoming order is accepted should be modelled precisely and unambiguously, in order to be published to customers, to document the corresponding decision in the various business processes where it has to be made, and to serve as the specification for automating the order processing.

"Accept order?" is the conclusion to be reached, and "yes" or "no" are the possible values.  When asked the question, the business owner of the decision says that three factors have to be considered:

• Whether the customer is at least 13 years old or not (because the business does not take orders from customers under that age as a matter of policy);
  
  
• Whether the order contains US-only DVDs; and
  
  
• Whether the shipping address is outside the US (because the business does not have a process for shipping US-only DVDs outside of the US).

For the sake of the example, let us assume that the ship-to address depends on another decision that considers whether or not the country attribute of the customer's address is "U.S."  Putting this all together, the business reaches a precise, unambiguous decision model, complete with associated set of decision rules, which is shown in Figure 1.

Figure 1.  Decision model for the "Order Acceptance Decision" example  

The key benefit of decomposing the overall decision into independent sub-decisions is that they can be managed, maintained, and re-used independently.

The example is simplistic; practitioners and authors writing about decision modeling have pointed out the need for additional features such as support for exceptional considerations, rules that restrict the values of considerations or conclusions, and decision variations.  Several graphical notations have been proposed for decision models, emphasizing the interests of different writers.  These ideas should be considered for the DMN specification.

We have discussed decision modeling here in terms of decision tables and simple rules, and we expect DMN to focus first on decision tables.  But other forms and representations of logic can also be used.  Possibilities include rule sets, decision trees, score cards, predictive models, optimization models, and AI techniques such as neural networks.  We believe that DMN would miss its target if it did not include them, or at least provide an extension mechanism that can be exploited in the future to address them.

OMG Decision Model and Notation

Decision modeling seems so intuitive and appealing that we expect many variations and many graphical notations as business analysts adapt their existing methodologies and as new players come into the field.  A primary goal for DMN is to standardize the notation, the underlying metamodel, and interchange among DMN tools.  To achieve success, these must preserve one of the most appealing properties of decision models:  the way they make communication more reliable, precise, and unambiguous between different stakeholders, such as business decision owners, policy managers, and business process managers.

The DMN metamodel will formally describe decision modeling concepts (e.g., in UML) to enable consistent implementation by tool vendors.  It will standardize decision terminology and semantics, and enable interchange between tools.

The DMN notation will specify one or more business-oriented, computation-independent, graphical diagrams that describe business decisions.  The notation should be sufficiently rich to address complex decisions.  It must include a standard notation for decision tables, and may also define graphical forms for some of the other forms and representations of decision logic mentioned above.

The DMN RFP asks submitters to focus on decision models, and to link to other existing OMG specifications for related concepts such as rules and vocabularies and business processes.  The remainder of this article discusses how DMN may relate to SBVR and BPMN.

SBVR and DMN

The choice to use the SBVR vocabulary as the basis for the considerations and conclusions of a decision seems obvious.  Attractive features of an SBVR vocabulary include its semantic richness (noun concepts, verb concepts, definitions, etc.), support for ordinary business terminology (rather than programming terms), and extensive business documentation features such as notes and examples.  Adopting the SBVR vocabulary for DMN agrees with our view that SBVR rules are complementary to DMN.

So what should be the relationship of SBVR rules to DMN?  We start by pointing out several fundamental differences between decisions and rules as captured in SBVR:

1. Each decision is made at one or more specific places in business processes, whereas SBVR rules are "global" to an organization.  Consider a rule such as "The age of each registered customer must be greater than 13."  The rule is "global" in the sense that it applies within all the processes of a business.  In comparison, a decision such as "Do we accept this potential customer?" is made at a particular step (or steps) in business processes.
   
   
2. Decisions have specified inputs ("considerations") and outputs ("conclusions" or "outcomes").  These inputs and outputs complement the way that decisions are "called" from particular tasks in business processes because the tasks must be set up to pass the required inputs and outputs to the decisions.  In effect, decisions operate as programming subroutines or SOA services with respect to business processes.  Contrast these aspects of decisions with SBVR rules, which are not defined in terms of inputs and outputs.
   
   
3. The relationship of SBVR rules to decisions is many-to-many.  That is, each SBVR rule may apply to multiple decisions, and each decision may implement more than one SBVR rule.  To see this, consider two rules:  the one cited above about the age of each registered customer and a second rule, "No US-only DVD may be shipped outside the U.S."  Imagine that a business has three business processes that must implement these rules.  The top table in Figure 2 shows which rules apply in each business process and relate those cases to the associated decisions via gray dashed arrows.  The blue arrows relate the rules to the considerations in those decisions.  The arrows show the traceability links that DMN should support among rules, decisions, and process activities.

Figure 2.  SBVR Rules Affect Multiple Decisions  

Each of the business processes has one decision.  Two of the three decisions implement one business rule, while a third decision implements both business rules.  So, you can see in the example that a decision (e.g., "Order Acceptance Decision") may implement multiple rules and that a single rule may apply in multiple decisions.

An alternative to the combination "Order Acceptance Decision" shown in the chart is to use the other two decisions as separate steps in the "Order Acceptance" business process.  While this could be viable, it forces the "Order Acceptance" business process to have two steps where there is only one real business decision, "Should the business accept the order?"

In summary, SBVR rules are business-level requirements formally stated, while decisions are implementations of the rules.

DMN and BPMN

The BPMN 2.0 standard defines a "BusinessRuleTask" for calling rules from business processes, and it seems natural to reuse this task type for decisions.  BusinessRuleTasks provide inputs to and receive outputs from the invoked tasks.  Those inputs and outputs can serve as the considerations and conclusions of decisions.  BPMN is open to modeling the kinds of inputs and outputs in many ways.  If SBVR is used to model the vocabulary for decisions, then it makes sense to use this vocabulary to model the types of inputs and outputs for BPMN.

We note that decisions may be invoked from other business artifacts, not just processes.  In particular, decisions are often decomposed into sub-decisions that jointly contribute to an overall business decision.  And decisions may often be called from business application software.  So DMN needs to support both BPMN-based and other usage scenarios.

BPMN 2.0 also defines a "GlobalBusinessRuleTask" — a kind of BusinessRuleTask that can be reused in multiple business processes.  We believe that many decisions are global in this sense.  We show an example in Figure 3, where the "Order Acceptance Decision" from Figure 2 is applied in three business processes that support different sales channels.

Figure 3.  Reuse of a Decision in Multiple Business Processes  

Note that the business action taken when the decision is "no" varies among the processes:  when the customer is available (on the web page or on the phone), the process can ask the user to change the order.  In the mail order process, the customer is not available so the only choice is to revise the order without customer input.  This illustrates that although decisions may be reused among multiple processes, the subsequent actions taken may vary considerably among processes.

Considering both that there is a many-to-many relationship between processes and decisions and that decisions may be used independently of processes, we propose that DMN define decisions as a unique kind of business artifact that exists outside of, and as a peer to, BPMN processes.

Conclusion

Figure 4.  Relationship among SBVR, BPMN, DMN, and Executable Rules  

Figure 4 illustrates the relationship among DMN, BPMN, and SBVR.  SBVR formally models the vocabulary and rules found in business sources such as corporate policies, regulations, and contracts.  Capturing these as "global" rules enables businesses to analyze how the rules apply throughout their operations.

The SBVR global rules are refined and implemented in DMN decisions that may be applied as activities within BPMN processes, or in other software.  The decisions depend upon the SBVR vocabulary concepts.  The BPMN processes pass runtime instances of these concepts into the decisions as considerations and receive instances as conclusions.  The decisions may be executed in business rule engines.

This view of DMN promises several benefits to business users and business architects:

• It provides an integrated notation for decision management, in much the same way BPMN does for business processes.
  
  
• It offers a bridge among rule-oriented, process-oriented, and information-oriented views of businesses.
  
  
• It enables modellers to address business modeling from any of these three views.

As an integrated notation, DMN will provide a standard way for business people to model their decisions.  These decisions can be traced from their source SBVR global rules and to executable rules via runtime rule formats such as W3C RIF.^[8]

DMN will define a computation-independent but decision-specific model that bridges the gap between the computation-independent and decision-neutral business vocabulary and business rules modeling framework offered by SBVR, and the process-specific decision model level provided by BPMN.  Where users had previously to choose between modeling from a pure business rules or a pure business process view point, DMN will enable tools that support switching back and forth between modeling decisions, processes, rules, and vocabularies.  In short, by bridging the fields of business vocabulary, business rules, business decisions, and business process modeling, DMN will provide a key component that is missing in the field of business modeling.

Notes

[*]  While the authors are IBM employees, this article represents their personal opinions and not any plans, designs, or commitments of IBM  

References

[1]  Barbara von Halle and Larry Goldberg, The Decision Model, Auerbach Publications, October 2009, ISBN 978-1420082814.  URL: http://www.kpiusa.com/index.php/tdm_text/the-decision-model.html  

[2]  James Taylor and Neil Raden, Smart (Enough) Systems:  How to Deliver Competitive Advantage by Automating Hidden Decisions, Prentice-Hall (June 2007).  ISBN: 978-0132347969.  URL: http://smartenoughsystems.com/  

[3]  Object Management Group (OMG), Business Process Model and Notation (BPMN), Version 2.0 (January 2011).  URL: http//www.omg.org/spec/BPMN/2.0/  

[4]  Object Management Group (OMG), Decision Modeling Information Day, March 23, 2011.  URL: http://www.omg.org/news/meetings/tc/agendas/va/Decision_Modeling_Info_Day_Agenda.htm  

[5]  Object Management Group (OMG), Decision Model and Notation RFP, March 2011.  URL: http://www.omg.org/cgi-bin/doc?bmi/11-03-04  

[6]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/   

[7]  Ronald G. Ross, Decision Analysis Using Decision Tables and Business Rules, Version 1.2, Business Rule Solutions LLC, December 2010.  URL: http://www.brsolutions.com/b_decision.php  

[8]  World Wide Web Consortium (W3C), Rule Interchange Format (RIF).  URL: http://www.w3.org/TR/rif-overview/  

# # #