Analyzing and modeling operational business decisions has become a new industry focal point in the past few years. Business-and-rule-friendly techniques have emerged[1], and just this year an OMG standard[2]. These resources address such important questions about operational business decisions as:

• How are they structured?
• How can they be decomposed?
• How can you capture related business rules?

Decision engineering also provides an opportunity for a fresh look at decision tables. Just to be clear, decision tables themselves are not new. They’ve actually been around longer than software engineering, at least back to the 1960s. What’s emerging today is a fresh way of looking at decision tables from a business rather than a software perspective, and important new ideas about how they can help address complexity.[3] ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

My Answer: Look at it this way. If you have no explicit business rules enabling people to do something correctly and consistently, you’ll have no rules for a machine to do it right. Except for speed and memory, machines are no smarter than people. The test of high-quality business rules is whether people could do it right. It’s shocking to me how many people think they can just use a BRMS or decision management platform to address a problem without having to express the rules clearly to other people first. I guess that silver bullet syndrome will always be with us. In any case, making tacit know-how explicit as business rules is first a business and communication problem, then and only then a platform problem.

In a recent blog post I called attention to the fact that there’s a major collision of terminology with respect to the term decision as used by different communities. See: http://www.brsolutions.com/2014/07/06/a-note-to-business-analysts-about-%e2%80%98decision%e2%80%99/ My basic observation was that both communities are correct in their own context – but since the contexts intersect the result is a significant potential for confusion.

• Business Analyst Community. Decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
• General Business Community. Decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.

Let me make some additional observations. A first question one should ask to clarify decision is what is the time horizon? Is it strategic or operational? A second question one should ask is what does decision actually refer to when used by each community for a given time horizon? Table. What Decision Refers to Based on Community and Time Horizon

Time Horizon of Decision	General Business Community	Business Analysis Community
strategic	strategic business decision	strategic project decision or change initiative decision or option analysis
operational	operational business decision	—

  In contrast to operational decisions, strategic decisions are always longer in time horizon, and generally made only once (which isn’t to say they can’t be revisited sometimes). This point is true for both communities. The distinguishing characteristics of an operational business decision is that it:

• Is highly repetitive (100s, 1000s, or more per day, hour, etc.).
• Can be encoded as practicable business rules.

Note: My analysis doesn’t address operational decisions for the Business Analysis Community (the cell show with dashes). That’s not because decision isn’t applicable in that context, but rather simply because it’s outside the scope of the present discussion. I recently saw the following draft definition of decision, which illustrates the problem of mixed meanings quite clearly.

An activity to answer a question or select an option from a known or knowable set of possible options. Typically defined in terms of business rules and made in response to events or at defined points in a business process.

• The first part of the definition is reasonable for decision in any usage. It applies to both communities and to any time horizon.
• The second part of the definition pertains only to the meaning of operational business decision. Strategic decisions, whether for the General Business Community or for the Business Analysis Community, are generally not based on specific business rules and are not made in response to events or at defined points in a business process. Strategic decisions are simply different in kind from operational business decisions.

The focus of a strategic decision is also quite different for each of the two communities.

• General Business Community: The focus is on conducting future business in a certain way.
• Business Analysis Community. The focus is on conducting a proposed initiative in a certain way to change the business itself.

Bottom Line: For clarity, I would always qualify decision to indicate which kind is meant. We certainly don’t need any more confusion in business engineering than already exists! www.BRSolutions.com

Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.    

• In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
• In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.

In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences. In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community. Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions. I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined. www.BRSolutions.com

Consider the following examples of decisions arising in a regulated environment (acks James Taylor):

Government agency in Europe has regulations relating to Social Benefits. The agency itself must make decisions like “Is this person eligible for this benefit?” and “How much benefit, and for how long, is this person entitled to?”” that conform with those regulations.

An individual company might also have a decision like “Is this person entitled to paid leave to care for a sick child?” that is dependent both on company policy/practices and regulations that relate to social benefits (because they might require companies of a certain size to pay for this kind of leave).

My Analysis Indeed, these are operational business decisions. I’m not surprised, by the way, they are in effect about money. Of course money entails decisions! But here are two important observations. 1. Regulations typically include a great many one-off behavioral rules (“one-off” meaning following no particular pattern). Examples might include:

• Payment of benefits shall cease immediately upon the death of the beneficiary.
• Payment of benefits shall not be made to any beneficiary living outside the country for more than 9 months of a fiscal year.
• Payment of benefits shall not be made directly to any minor.

Is decision analysis suited to capturing/interpreting such one-off rules? Is it meaningful to have a decision such as “Should a benefit payment be made?” Shouldn’t such behavior be presumed automatic (but traceable and adaptable)? A better option is to simply have a task or action such as “Make payment”. Violations of related business rules for any particular case produces exceptions, possibly to be addressed by appropriate messages and/or procedures invoked automatically. That’s how basic business behavior becomes autonomous, so the business can concentrate on matters requiring greater skill, experience or intelligence. If you’re not careful everything becomes a decision. Where do you draw the line? Isn’t there a difference in simply being competent vs. being smart in doing business?

Aside:  Business vocabulary is as always obviously important. For example, does “payment” mean “accrual of benefit”, “act of payment”, “amount of payment”, or something else? No small issue.

(2.) Consider the following (one-off) behavioral rule:

A non-citizen may cash a payment of benefits for a citizen only if married to that citizen and the citizen is not deceased.

What happens in the case of death or divorce, and then the non-citizen tries to cash a payment? There’s no organizational decision involved there. There’s a personal decision … the non-citizen can decide to try to violate the rule … but we don’t really care about that. We only care about detecting the violation. We really don’t need or want an (operational business) decision here, do we? Again, if you have a decision for every possible kind of violation of every behavioral rule, you’ll very quickly drown in decisions. Don’t go there!  

A person close to the DMN (Decision Model Notation) standard recently wrote:

In DMN a decision is deliberately defined very broadly … 

“a decision is the act of determining an output value (the chosen option), from a number of input values, using decision logic defining how the output is determined from the inputs”.

Decisions in DMN can be automatic, they can be used for detection, the logic they use can concern the violation of constraints; I see no problem with any of this.

My Response

• A motorist goes thundering down the motorway, well over the speed limit. A radar gun detects it. What “decision” was made? Would a business person ever say the radar gun “decided” the motorist was speeding? … “Determined” maybe; “decided” no.

• A company has the (behavioral) business rule:

 A customer that has placed an order must have an assigned agent.

An agent servicing customers who have placed orders retires and moves to Florida (this last part irrelevant). What “decision” is it that says, hey, now have some unrepresented customers and somebody ought to do something about it ASAP?? What “decided” there are now violations?? … “Detection yes”, “decision” no. 

P.S. That definition of decision seems a bit circular. To know what a “decision” is I need to know what “decision logic” means. But since “decision logic” says “decision”, seems like I need to know what “decision” means. Hmmm.

A person close to the DMN (Decision Model Notation) standard recently wrote:

In DMN a decision is deliberately defined very broadly … 

“a decision is the act of determining an output value (the chosen option), from a number of input values, using decision logic defining how the output is determined from the inputs”.

My Response I’ve already written that the DMN definition of “decision” seems to be a bit circular. (To know what a “decision” is you need to know what “decision logic” means. But since “decision logic” says “decision”, seems like you need to know what “decision” means.) Let me tell you what else I find wrong with the definition. (All dictionary definitions from MWUD.) Problem 1. MWUD defines “decision” as (1a) the act of deciding. It defines “act” as (1a) a thing done or being done. So which is it? Is a decision a thing “done” or a thing “being done”? In other words, is a decision the result of an action or process, or the performance of an action or process? Big difference! Which does the standard mean? Some clarity would be nice. Problem 2. MWUD defines “decide” as: to dispel doubt on: (a) to arrive at a choice or solution concerning which ends uncertainty or contention *decide what to order for breakfast*  (c) to infer or conclude from available indications and evidence So the real-world definition of “decide” talks about …

• Arriving at “a choice or solution”.
• Basing that choice or solution on “indications and evidence”.

Do you see anything in that definition that reduces what is used in making decisions to “inputs” and “outputs”?! That’s ITspeak, not businessSpeak. So let’s not pretend the DMN standard is really about business modeling per se. It’s business reduced to a system view. Problem 3. “Input value” is definitely ITspeak. Fields and attributes in files and databases are what have this kind of “value”. In the business world, people talk about cases, applications (appeals, requests, petitions), communications, situations, circumstances, trends, profiles, and the like. They don’t talk about “input values” to a decision. Get real. Again, the authors of the DMN standard should either be clear it’s really about system stuff … or admit to causing confusion, deliberately or otherwise.

A decision management tool vendor recently wrote:

“The relation between business rules and decisions is I think pretty well agreed by all – it’s just that some focus on 1 or the other, and some both – any “disagreement” is more on the value in the different approaches.”

I respectfully disagree (strongly).  There are fundamental differences between decision rules and behavioral rules including these: 1. Behavioral rules are usually one of a kind. They don’t fit in decision tables. Some might appear in decision models if you are concerned about such things as integrity (will the DMN standard be?), but the large majority don’t. 2. Decisions are generally single point of determination for any given real-world case. Most behavioral rules are multi point of determination, meaning they could be violated under quite different circumstances. 3. The detection of violations of behavioral rules should be automatic and event-based. There’s no “decision” involved in the detection … it should be automatic. (This is where the current generation of rule engines … mostly based on 1980s expert-system thinking … fall woefully short. It’s also probably one reason they haven’t become more mainstream in industry mindshare.) 4. Behavioral rules generally have a different source than decision rules … laws, regulations, contracts, agreements, deals, certifications, warranties … and business policies. Decision rules sometimes arise from those sources, but if so, have limited coverage. Decision rules in contrast often arise from the heads of knowledge workers and inspection of big data and event streams. (Behavioral rules do too, but likewise don’t begin to cover everything.) So the issue is by no means simply a “matter of approach”. Spinning it that way might be useful for vendors, but it won’t be helpful to business analysts. We need to think soberly about the true range of business rules and the fundamental distinctions that exist. If not people will end up very frustrated on the other side of the DMN hype cycle. We can do better than that, and for the sake of the DMN standard, we should. P.S. For discussion and examples of the fundamental distinction between behavioral rules and decision rules see Appendix 3 in the DecisionSpeak Primer … available for free download on http://www.brsolutions.com/b_ipspeakprimers.php.  By the way, DecisionSpeak and its companion TableSpeak are *quite* concerned about integrity in decision models.

The answer is no, but read on. RuleSpeak 3.0 featuring tabulation was just recently released. See http://www.brsolutions.com/b_ipspeakprimers.php (free download). RuleSpeak is structured natural language for expressing business rules in the clearest way possible, yet very precisely. I know some people argue that decision models will supplant the need to express any and all individual business rules. Pardon me, but that’s either highly uninformed or not-so-innocently misleading. Having said that, do I think there’s much to be gained from decision analysis and a revival of decision tables (a very old technique)? Absolutely. We’ve been busy fine-tuning methods for a good number of years. I’m glad we waited. The results speak for themselves. See the new DecisionSpeak and TableSpeak (free downloads) on that same webpage. All 3 ‘Speaks’ are highly complementary … as of course they should be! You need all these tools to be successful with business rules. By the way, all 3 ‘Speaks’ are business-oriented and tool-independent … as they should be(!).

written in response to Jacob Feldman: http://www.brsolutions.com/2013/05/07/response-to-decisionspeak-tablespeak-annnouncement/ Jacob, Thanks! And I agree with you about the ‘executable’ part. Our emphasis is on business-friendly, business-driven models. I believe DecisionSpeak and TableSpeak move things forward significantly in that regard. There’s no reason why decision models have to be oriented to IT development. If they are robust, they will nonetheless be executable. I would sound a note of caution. Decision models are no silver bullet. There are issues of semantics (vocabulary) and integrity (restrictions) to be addressed. And they don’t cover even the majority of all business rules – especially behavioral rules. If you throw everything you (should) know about business rules out the window when you use decision models, you will be in for a very rude awaking. I’m glad we did not rush to the market. We’ve taken our time to do our homework with respect to theory (which has been out there for a great many years) and to hone our approach in real-life consulting work. I think the results speak for themselves!