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!  

Consider the following example.

Behavioral Rule: A student with a failing grade must not be an active member of a sports team.

This business rule:    

• Is not about selecting the most appropriate sports team for a student – i.e., not about the decision, Which sport team is best for a student?.
• Does not apply only at a single point of determination – e.g., when a student joins a team.

Instead, the business rule is meant to be enforced continuously – for example, if a student who is already active on some sports team should let his or her grades fall. What’s the business decision for when a student’s grades fall and they should be taken off a team? Be real, there’s no good answer to that question. This example is no outlier. Businesses have 1,000s of behavioral rules like this. Let’s be clear – I believe a business-decision-based approach is very powerful for decision rules. I have written much about that. And I don’t disagree that many business-rule projects have floundered due to lack of pragmatic organizing principles (e.g., “decisions”). But if you take a decision approach to behavioral business rules, either it will prove woefully incomplete with respect to integrity, or you’ll quickly start to drown in (system-level) decisions. In my opinion, an application that has to be designed and to operate to treat violations of behavioral rules as just more decisions is not a smart enough system. The detection of violation events for behavioral rules can be, and should be, completely under the covers (identified, detected and supported by a platform). Otherwise the solution won’t scale. And there will be so many decision dependencies it will steal from the very real value of a business-decision-based approach. This frankly is a sign of immaturity … or lack of imaginative leadership … or IT bias … or whatever … in some parts of the decision-model community. The detection of a violation of a behavioral rule is an event, not a decision. A business decision is a business decision; a system decision is … well … why even go there?! P.S. There are 3 specific examples and more complete discussion about this topic on http://goo.gl/NCnLi.      

      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:

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:

“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.

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 OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).

Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:

• When the first order is placed by a customer.
• When an agent leaves the company (which could leave an order-placing customer without an agent).

How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:

• Detect violations of behavioral rules (like cops and referees).
• Permit dynamic invocation of selective (read “selectively different”) responses.

Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/

guest post by Jan Purchase, Director of Lux Magi Ltd ~~~~~~~~~~~~~~~~~~~~~ I do see value in distinguishing ‘policy’ rules from ‘expert’ rules. It’s also clear that, at their extremes, these rule types are poles apart. Still I fear that this distinction may be a continuum rather than a discrete dichotomy. Policy rules might be exemplified as the constraints of business operational practice – the rules that dictate what a company should and should not do. They might be mined from the boundary conditions of the fact model of the company’s business capability – as you suggest in your excellent book on this subject[1]. An example policy rule might assert, for example, “A company agent may be assigned to a high-value customer only if the agent is assigned to at most five other clients”. Expert rules, on the other hand, are often seen as more complex – for example, using heuristics to determine the best, anti-cancer drug to apply in a given situation, or forecasting regional sales opportunities. Often these expert rule bases use expert experience, genetic algorithms, fuzzy logic and feedback loops to reach a decision. They seek to augment, or even supplant, the wisdom of a small population of subject matter experts. But isn’t there a middle ground too? Consider an insurance policy decision rule that bin-sorts clients into good, bad and medium risk (the latter to be referred to a human underwriting expert). If this were a simple four-row, decision table based on the value of the policy and the risk profile of a client, you would probably consider it a ‘policy rule’. But if I add scorecarding, heuristics and analytics, at what point does it become an ‘expert rule’? Would you consider all decision rules (as opposed to constraint rules) to be ‘expert rules’? Or do they need to be complex or directly represent the experience of SMEs? Don’t all rules, to some extent, represent the wisdom of experts? Don’t many of them constitute and inform policy? In short: Is there a simple question we can ask (concerning a rule) to determine if it is a ‘policy’ or ‘expert’ rule? ~~~~~~~~~~~~~~~~~~~~~~~~ See my reply to Jan: http://www.brsolutions.com/2012/05/29/the-debate-continues-expert-systems-vs-business-rules/ Answer to Jan’s Question: The question to ask of every rule is whether the end-point is enforcement or is it a decision. An enforcement rule never becomes a decision rule, and a decision rule never becomes an enforcement rule. Once an enforcement rule, always an enforcement rule (assuming you don’t retire it). You can adjust thresholds (e.g., the mph of the speed limit), you can change the enforcement level (e.g., from ‘strictly enforced’ to ‘override with explanation’), you can change the sanctions (or eliminate them), etc., etc. And you can and should use analytics to measure and improve the rate of success in achieving underlying business goals. But it’s black and white. Enforcement is enforcement and decisions are decisions.

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).

Consider the following behavioral business rule: A renter must not have possession of more than one rental car. In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’. Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about? When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.

• There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
• There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
• If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.

A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in. Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules). Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc. We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t. Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.