Modeling Decision Structures Part 1: Kinds of Decision Dependencies

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
Extracted from Decision Analysis — A Primer:  How to Use DecisionSpeak™ and Question Charts (Q-Charts™), by Ronald G. Ross, 2013, available (free) on http://www.brsolutions.com/IPSpeakPrimers

Decision analysis aims toward capturing and encoding the logic used to make decisions. These decisions are always operational business decisions — not programming, personal, strategic, or governance decisions.  Operational business decisions are common in business processes.  Examples:

  • Should an insurance claim be accepted, rejected, or examined for fraud?

  • Which resource should be assigned to a task?

  • Which service should be used to ship a package?

As these examples suggest, decision analysis involves identifying and analyzing key questions arising repetitively in day-to-day business activity.

In DecisionSpeak, the structure of an operational business decision is diagrammed using a Question Chart (Q-Chart™ for short).  Q-Charts involve two fundamental elements:

  • An elongated hexagon, called a Q-COE™, to stand for an operational business decision.  Each Q-COE indicates what question ("Q") is being asked, and usually one or more of the following:  considerations ("C"), outcomes ("O"), and exceptions ("E").

  • Decision dependencies are represented by special connectors.  A dependency between operational business decisions occurs when one decision is logically a prerequisite for another.

DecisionSpeak recognizes three kinds of decision dependencies as given in Table 1.  Each kind of decision dependency is discussed individually below.

Table 1.  The Three Kinds of Decision Dependencies in DecisionSpeak.

 

Basis

Kind

        Effect

1 question relevance
dependency
the outcome from one question can preempt another question
2 consideration consideration
dependency
the outcome from one question provides or supports a consideration for another question
3 outcome outcome
dependency
the outcome from one question can restrict the outcomes of another question

 

Why aren't mathematical dependencies among the decision dependencies shown in Table 1?

An example of a mathematical dependency:

A first expression (C - D = E) depends on a second expression (A + B = C) in that the first expression depends on computation of C as prescribed by the second expression.

Business rules for computation are best given by formulas featuring appropriate re-use of terms (e.g., 'C' in the two expressions above).  Such formulas can (and should) be expressed as individual business rule statements — e.g., using RuleSpeak®.

Use of Q-Charts generally anticipates decision tables, rather than individual business rule statements.  Part 2 of this two-part series discusses further.

In Q-Charts, decision dependencies are connected using vertical connectors.  Why?  Horizontal connectors might suggest process or flow.  Since decision logic under DecisionSpeak is always declarative, horizontal connectors are avoided.

The decision on the top (the upper decision) is always dependent on the decision below it.  If a Q-Chart shows multiple levels of decision dependency (not unusual), the same is true pair-wise at each level below.

As illustrated in the discussion that follows, every depiction of a dependency connection includes a 'hitch point' (a solid circle) at the bottom end.  The operational business decision on that end is always the one most able to stand on its own — i.e., the lower decision is always the more independent.

Relevance Dependency

In relevance dependency, one operational business decision depends on the outcome of another operational business decision such that the outcome of the other decision may completely eliminate the need for any outcome from the dependent (upper) decision.

In other words, the dependent operational business decision can be preempted — indeed, made meaningless in certain cases.

In determining eligibility of applicants for auto insurance, for example, if an applicant is not eligible for coverage, there is no need to determine what to charge the applicant as a premium.  This relevance dependency between operational business decisions is illustrated in Figure 1 using a dashed connector (with hitch point at bottom).  The dashed line extends from the question area of the Q-COE representing the dependent (upper) decision.

Figure 1. Relevance Dependency between Operational Business Decisions.

Do processes always have to address the questions involved in a relevance dependency in bottom-to-top sequence?

No, but caution should be exercised.

For the questions in Figure 1, for example, a customer-friendly, web-based application might permit price-conscious consumers to ask about the premium before asking about eligibility.

If supported, however, including some disclaimer would probably be appropriate to indicate that securing coverage at the given price is subject to eligibility.  An explicit business rule should be written for that purpose.  The business rule ensures a disclaimer is given by any process or use case that supports a price-before-eligibility sequence.

Consideration Dependency

In consideration dependency, one operational business decision depends on the outcome of another operational business decision such that the outcome of the latter decision provides or supports one of the considerations for the dependent (upper) decision.

For example, it might not be possible to decide what coat to wear unless you decide whether it is cold.  Deciding whether it is cold might have considerations all its own.  This consideration dependency is illustrated in Figure 2 using a solid-line connector (with hitch point at bottom).

Figure 2.  Consideration Dependency between Operational Business Decisions.

The consideration cold? in the dependent (upper) decision is conditional.  Whether or not it is cold depends on the three considerations of the lower decision:  temperature, wind, and humidity.

If a consideration is not conditional in that sense (i.e., not based on other considerations), a consideration dependency is not needed.  For example, suppose you can say Yes, it's cold. or No, it's not cold. without needing to know anything about the temperature, wind, and humidity.  Then the lower decision Is it cold? is not needed.

Outcome Dependency

In outcome dependency, one operational business decision is dependent on the outcome of another decision such that the outcome of this other (lower) decision dictates some outcome(s) of the dependent (upper) decision.  Two essential rules always apply to outcome dependencies:

  1. Both decisions must have the same kind of outcome.

  2. The set of considerations of the less dependent (lower) decision must be the same as, or a subset of, the set of considerations of the more dependent (upper) decision.

Figure 3 illustrates an outcome dependency using a dashed connector (with hitch point at bottom).  The dashed line extends from the outcome area of the Q-COE for the dependent (upper) decision.

Figure 3.  Outcome Dependency between Operational Business Decisions.

Observations:

  • The lower (independent) Q-COE represents the question What set charges are there for shipping an order? and has the outcome fixed shipping charge.

  • The upper (dependent) Q-COE represents the question What should be charged for shipping an order? and has the outcome shipping cost.

  • The structured business vocabulary (concept model, not shown) must indicate fixed shipping charge and shipping cost to be the same kind of thing.

  • The lower Q-COE uses the considerations zip code and season, a proper subset of the four considerations for the upper (dependent) Q-COE.

  • The net effect is that the lower Q-COE will dictate ("set") some (but presumably not all) outcomes for the upper (dependent) Q-COE.  For example, if the zip code is in Alaska, and the season is winter, all shipping costs might be $250, regardless of weight or kind of package.  This business rule might be just one of many that dictate ("set") shipping cost for multiple cases.

Relevance Dependency vs. Outcome Dependency

Relevance dependencies and outcome dependencies are alike in one important way — they both represent dependencies that can eliminate the need to ask the question for the upper (dependent) decision.  Because of this similarity, a dashed line is used to represent both.

Relevance dependencies and outcome dependencies are different, however, in the following fundamental way:

  • For relevance dependencies, the outcome from the lower (independent) decision makes any outcome from the upper (dependent) decision meaningless in certain cases.  In other words, the upper (dependent) decision simply cannot produce any valid outcome for those cases.

  • For outcome dependencies, the outcome from the lower (independent) decision dictates the outcome for the upper (dependent) decision in certain cases.  That outcome is the only one the upper (dependent) decision can produce for those cases.

In DecisionSpeak, relevance dependencies and outcome dependencies are always distinguishable by the form of the question specified for the lower (independent) decision.  In other words, the question is always worded distinctly.

  • A relevance dependency always asks a yes/no question (e.g., eligible/ineligible?).

  • An outcome dependency always asks about a fixed or set outcome (e.g., fixed shipping charge).

Finally, in Q-Chart notation the dashed line for a relevance dependency properly attaches to the question area of the top Q-COE.  The dashed line for an outcome dependency, in contrast, properly attaches to the outcome area of the top Q-COE.

In Part 2

Part 2 of this two-part series provides a comprehensive example of a Q-Chart, as well as an example of a hybrid diagram also showing derivation dependencies.

# # #

Standard citation for this article:


citations icon
Ronald G. Ross , "Modeling Decision Structures Part 1: Kinds of Decision Dependencies" Business Rules Journal Vol. 14, No. 9, (Sep. 2013)
URL: http://www.brcommunity.com/a2013/b717.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal , and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the IPSpeak methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.