Modeling Decision Structures Part 1: Kinds of Decision Dependencies
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.
|the outcome from one question can preempt another question|
|the outcome from one question provides or supports a consideration for another question|
|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?
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.
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?
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.
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.
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:
- Both decisions must have the same kind of outcome.
- 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.
- 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 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.
# # #
About our Contributor:
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.