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

Comment by DMN proponent: In common business use the term “decision” is often overloaded to mean “decision output”. So I “make a decision to do X” is the act, whereas I “use the decision as input to another decision” is referring to the decision output. I’m not sure there are any semantic issues with (i.e. possible problems caused by) this overloading? My response: Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)? In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary): 1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment 1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak[1] an outcome by definition is a decision. Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition *not* a decision. A decision is an act, never the result of the act. Hey, I’m just reading what is written in the standard. If DMN somehow allows ‘overloading’ of the term “decision” — the central term in the standard — all bets are off. A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all. The result is semantic muddle. Pretty big deal. Sorry! www.BRSolutions.com  

      In classifying ‘rules’ I go by the standards … Business Motivation Model (BMM): business policies vs. business rules

• Business rules are always practicable – workers can apply them directly.
• Business policies are not – they must be interpreted first.

SBVR: definitional rules (necessities) vs. behavioral rules (obligations) vs. advices (possibilities or permissions).

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).
• Advices are non-rules; they provide practicable guidance but do not remove any degree of freedom.

I would add only these observations: 

• The kinds of rules you see in decision tables are generally definitional. Since they represent only a subset of all definitional rules I call them ‘decision rules’ for convenience.
• Condition-Action or Event-Condition-Action (ECA) rules are not business rules at all. They are representations of business rules (for a class of implementation platforms).
• My smart phone can tell me in spoken English where the nearest gas station is. It’s only a matter of time before machines start ‘reading’ regulations, contracts, agreements, business policies, etc. to help people formulate (through dialog) practicable (and implementable) business rules. Can you imagine the productivity benefits?!
• Decision tables are great. Everybody should use them. But they are a lot harder to design well than you might think.
• The DMN standard can move things along significantly … if it is good, and it isn’t overhyped (which it already has been in certain quarters). I’m looking forward to it impatiently. But standardization (in equal parts a political process and a technical process) do take some time!

A person close to the DMN (Decision Model Notation) standard recently wrote about its definition of “decision”: “This means a technical rather than business-person definition of ‘decision’, as the businessperson is not the target audience for the specification (metamodel) but of the results of the specification (models).” My Response Well, that’s a shame. Many people will be looking toward the DMN for a business vocabulary they can use in communicating with business people. So the communication gap between IT and business is not being closed in the area. My personal opinion is:

• Computers have become so powerful these days that they should be speaking *our* language (in structured, carefully defined form), not the other way around.
• Standards (and standards organizations) that fail to move the ball forward in that regard are failing its audience in the larger sense, no matter how good the standard for its chosen area. (And I do hope DMN is good in that latter sense.)

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

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:

I can’t see how you can object to the idea that decisions can be automatic, or used for detection, unless you maintain that decisions can only be taken by people?

  My Response Putting theological questions aside, in the beginning there was man. Well, people. Well, animals and people. As far as science is currently aware, there is nothing else in the universe that can “decide” something. Well, let’s put quantum mechanics aside. How things get “decided” there is just plain weird. That’s not human scale anyway (as far as science is currently aware). My point is that the concept “decide” makes absolutely no sense unless you acknowledge that “deciding” is a human concept. People decide stuff (or decide when things have been “decided”.) When Machines “Decide” Can machines “decide” things? Of course. Can they often “decide” things better than humans? Of course. Can they often “decide” things instead of people? Of course. Would you call what it is the machines do in such cases “deciding” if there were no people who could do the thing we call “deciding” in the first place? Of course not. “To decide” is fundamentally a human characteristic. If you try to remove the “human” sense of “to decide” from the verb, it’s not how the average person would understand it. This sense comes across clearly in the real world definition of “decide” [MWUD]: to dispel doubt on. When Machines “Doubt” Can machines “doubt”? I’ll let the philosophers decide that (yes decide). I’ll just say this: I doubt (yes doubt) it would be called “doubt” unless people experienced “doubt” in the first place. So when you use the word “decide”, even for what machines are doing, use it for things that people would call “decide”. If you want to use the word “decide” for machines in some other way – for things that people wouldn’t call “decide” in the real world – then please, just plainly admit you’re in systemland, not in peopleland.

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

“Under DMN we would say that the automatic detection of the violation of a constraint is indeed a decision.”

My Response … Which part of any definition of any of the following terms in your statement would in any way, shape or form lead to the notion of “decision”?!

• automatic
• detection
• violation
• constraint

You’ve put you finger squarely on the three confusions (shortcomings) I fear most from the DMN standard — failure to:

1. Comprehend that behavioral rules are a quite different animal from decision (or definitional) rules.
2. View “decision” from a businessperson’s point of view.
3. Define “decision” as meant in the real world.

Is this going to put another standard emanating from an IT background parading as a “business” paradigm? Another standard where hype beneficial to existing vendor products outweighs true clarity and innovative leadership? I am hoping for the best … I want the standard (if good) to succeed … but fear the worst. I’m afraid your statement doesn’t instill much confidence.