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

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:

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.

Location: Online Seminar Overview Do your business processes always produce correct and consistent results? If not the problem probably lies with your business rules and decision logic. Business Analysts need the right techniques to fix these problems – process models, use cases, data models and other requirement techniques just aren’t right for the job. This hands-on series will equip you with proven techniques for success. More info: http://www.attainingedge.com/online-training-business-rule-analysis-masterclass.php Register for full series!

Session 1. The why, what and who of business rules

Next Session: October 1, 2013 @ 10:30am – 12:00noon (ET)

• Why business rules
• What benefits you can achieve
• What business rules are, and are not
• Business rules vs. business processes
• Kinds of business rules: definitional vs. behavioral
• How the business should react to violations
• Business rules and decisions
• What skills you need to capture business rules effectively
• What you need to know

Register Session!

Session 2. Eight steps to find and capture business rules

Next Session:October 1, 2013 @ 3:30pm – 5:00pm (ET)

• Capturing business rules from people’s heads
• Capturing business rules from great big documents
• Using facilitated sessions
• Step-by-step approach
• What about reverse-engineering business rules from code
• Do’s and don’ts

Register Session!

Session 3. Eight steps to express clear business rules

Next Session: October 2, 2013 @ 10:30am – 12:00noon (ET)

• Business policies vs. practicable guidance vs. automated rules
• The role of business vocabulary
• Step-by-step approach
• Clarity and completeness
• Eliminating ambiguity
• Addressing exceptions
• Guidelines
• What to avoid and why

Register Session!

Session 4. How to analyze and communicate business rules

Next Session: October 2, 2013 @ 3:30pm – 5:00pm (ET)

• Basic principles for rule analysis
• Rule quality
• Handling conflicts
• Developing business reactions to violations
• Simplification – When, why and for whom
• How to validate business rules with business people and SMEs
• Verification – Examples

Register Session!

Session 5. Eight steps to set-up decision tables

Next Session: October 3, 2013 @ 10:30am – 12:00noon (ET)

• When to use decision tables
• How to set up decision tables
• Decision tables and business process models
• What your decision tables should not do
• Decision tables and business vocabulary
• Best practices
• Alternative formats
• Completeness, subsumption and conflicts

Register Session!

Session 6. Ten steps to start or refine your business rules projects

Next Session: October 3, 2013 @ 3:30pm – 5:00pm (ET)

• Business rules and requirements
• Properties of business rules
• Traceability of business rules
• Retaining corporate memory
• Managing the life cycle of business rules
• Business rule management – examples
• Business rules and rule engines – implementation examples
• How to get started

Register Session!

  Location: Online Interactive Training Why Attend … Working on developing requirements? Wrestling with complex business process models? Harvesting business rules to implement in a rules engine? Many professionals are finding there are big gaps in their current approaches:

• Their requirements methodology fails to capture and specify decision logic.
• Their business process models mangle the logic for making decisions.
• Their decision management platforms support implementation but don’t connect to the business.

This training provides proven, pragmatic solutions. It provides 8 easy steps so you can think clearly before you implement. More info:  http://www.attainingedge.com/online-training-decision-analysis-and-decision-tables.php Register for full series!

Session 1. Business-Friendly Decision Analysis

Next Session: November 20, 2013 @ 10:30am – 12:00noon (ET)

• Why decision analysis
• What decisions and decision logic are about
• The elements of decisions
• Using DecisionSpeak^™ to ask the right questions
• Diagramming decision structures (Q-Charts^™)
• Question, considerations, outcomes, and exceptions (Q-COEs)
• What kinds of business rules are suited for decision analysis – and which are not

Register Session 1

Session 2. Analyzing Decisions and Developing Decision Structures

Next Session: November 20, 2013 @ 3:30pm – 5:00pm (ET)

• How to establish and refine scope for decision analysis
• Identifying exceptions
• Delineating subdecisions
• Kinds of decision dependencies
• Hybrid dependency diagrams
• Critical success factors for conducting decision analysis

Session 3. Designing Decision Tables

Next Session: November 21, 2013 @ 10:30am – 12:00noon (ET)

• How to keep decision tables as simple as possible
• How to maintain business alignment
• How to set-up decision tables using TableSpeak^™
• When to use which format when
• Completeness, anomalies and certainty of outcome
• Vocabulary, integrity (correctness) and validity
• Pitfalls
• Best practices

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(!).