Sample behavioral business rule: A customer that has placed an order must have an assigned agent. A practitioner wrote: In process design this means that an activity ‘Assign agent’ must happen before an activity ‘Take order’. My analysis: Here’s how behavioral business rules like this one should work according to standards[1]:

• If the business rule is violated in performance of the process ‘Take order’, then the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
• In performance of the process ‘Retire agent’ (which hasn’t been mentioned!), if the business rule is violated – i.e., the retiring agent is assigned to some customer who would thereby be left agent-less – the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).

There’s one business rule, but two kinds of events (in separate processes) where the rule can be violated. I’ve literally looked at 10,000s of business rules. Probably 95% or more are multi-event like this, and therefore often multi-process. You can see from this example how easy it is for business analysts to completely miss the second event. My contention is that’s one big reason why systems today often give such inconsistent results – the other event(s) are overlooked or in another process altogether. Conclusions

• It’s highly misleading to say ‘business rules are part of processes’. No, not really. (I run into that statement all the time.)
• We’re not designing processes today in a very intelligent way. Designers shouldn’t have to think, ‘O.K., which process (activity) has to come first because of the business rules?’. That approach forces us into sequences where no natural sequence is meaningful. In any case there are far too many behavioral business rules for it to be practical.

P.S. If you think ‘decisions’ will fix this fundamental problem, sorry, but I’m afraid you’re in for a rude awakening! ~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

How does legality work with business rules? To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved? Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal. SBVR[1] does not have an innate concept/approach for “legality” in the sense of MWUD[2] 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.) 1. Specify a behavioral rule A behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:

The people united in a marriage must not be of the same gender.

Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline. The rule would be active when a relevant state of affairs arose (i.e., specific people get married). 2. Define several definitional rules A definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:

• The people united in a marriage are not to be of the same gender.
• The people united in a same-sex marriage are to be of the same gender.

See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand. 3. Define the relevant definitions

• Marriage: the uniting of people of different genders in wedlock
• Same-Sex Marriage:  the uniting of people of the same gender in wedlock

Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand. Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both. ~~~~~~~~~ www.BRSolutions.com    

The two fundamental kinds of business rules relevant to business analysis are definitional rule and behavioral rule. These two kinds of rule come from OMG’s SBVR (Semantics of Business Vocabulary and Business Rules) standard.[1] They have very precise meanings based on formal logic. Here’s some background about that – more than business analysts really need to know, but informative nonetheless. At the end of the discussion I give pragmatic definitions. And the answer to the photo quiz. The SBVR definition for rule is deeply embedded in formal logic, which deals with propositions.  In modal logic, propositions can claim different modes. For business rules the two relevant modes are alethic and deontic.  

• Alethic rules are true ‘by definition’. As such they cannot be violated.  They are about how concepts, knowledge or information are defined or structured.
• Deontic rules are rules that can be violated. They are rules about behavior, not concepts, knowledge or information. Deontic rules are really about people, what they must and must not do, even if their activity (and the rules) are automated.

Both kinds of rules are important, of course, but deontic rules – people rules – are especially so since ultimately, businesses are about the activity of people. This situation is very different than in the semantic web, for example, where it’s all about only knowledge. Under modal logic, every rule must therefore ‘claim’ one of two modes. (In practice, the ‘claim’ arises naturally from the syntax of a rule statement or as a meta-property.)

• Alethic implications (rules) are established by ‘claiming’ necessity. Things are necessarily true. A concept is what it is; says what it says. That’s just the way things are.
• Deontic implications (rules) are established by ‘claiming’ obligation. Behavior is ‘obliged’ to follow the rule. But of course, people don’t always follow the rules, so there can be violations. Major difference.

So a rule ‘claims’ either necessity or obligation, which establishes what kind of rule it is. Therefore the SBVR definitions for the two kinds of rule are:

• Definitional rule:  rule that is a claim of necessity
• Behavioral rule:  business rule that is a claim of obligation

Why doesn’t the definition for definitional rule say “business rule” like the one for behavioral rule? Because some definitional rules are not ‘under business jurisdiction’ (in other words, business has no choice about them). Examples include the ‘law’ of gravity and all the rules of mathematics. Those rules are simply universally true. I recommend the following pragmatic definitions for business analysts.

• Definitional rule:  a rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge or information
• Behavioral rule:  a business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity

Synonyms:  Early in the development of SBVR I introduced the terms structural rule and operative rule for the two kinds of rules, respectively. That was before the full implications of modal logic became clear. Since then the terms definitional rule and behavioral rule have become preferred, even in all internal SBVR discussion. The synonyms, however, remain valid. P.S. Did you guess correctly which kind of rule is represented in the photograph? Behavioral, of course. And the photo itself is a violation of the rule. www.BRSolutions.com

Re-engineering knowledge work is the central problem of the knowledge economy. In recent work at Centers for Disease Control (CDC) and current work a major bank in Canada we used RuleSpeak® to create what I call a “single source of truth for operational business IP (intellectual property)”. This is far more than a conceptual data model. Beyond structured business vocabulary its central feature is comprehensive rules. It may be like what some professionals call a “conceptual ontology” (as opposed to an operational ontology to be embedded in IT systems). But we would never use the term “ontology” in our work.  Most business people and SMEs simply wouldn’t ‘get’ that. The idea is that all audiences (or subcommunities) in an organization should work off a single trusted source of explicit know-how (business vocabulary and business rules), no matter what their specific responsibilities:

• producing training materials for line workers.
• making changes in operational policies.
• providing proof of compliance for auditors.
• creating new products.
• communicating with IT.

Here are some key observations about our work to create a single source of business truth:

• Our primary audience is not IT. Yet our work is of sufficient precision that straightforward translation into an implementation form can basically be taken as a ‘given’.
• Our approach recognizes that people are the essential ingredient in business (as opposed to other kinds of knowledge problems). People can violate rules. For coordinating the work of people, direct support for behavioral rules, not just definitional or decision rules, is a must.
• Our work could not be undertaken without a structured natural language for business rules like RuleSpeak. The non-IT audiences do need rich business semantics, but they have no desire whatsoever to become semantic programmers. They simply would not commit if the work were conducted on that basis.
• No one today knows what the optimal syntax is for expressing all forms of business know-how in all circumstances. I suspect there isn’t one. That fact, plus the exponential increase in computer capability for processing natural language, indicates clearly that focusing on syntax is simply the wrong direction. RuleSpeak is based on, and was one of the reference languages for SBVR (Semantics of Business Vocabulary and Business Rules, on OMG standard), which supports a non-syntax approach. A language for ‘speaking’ with computers that is not a computer language – now that’s an idea whose time has definitely come!

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!  

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

I’ve written on this subject many times before, but let me summarize my position concisely. By the way, I expect heavy flak on the last point. See what you think. (1) Business rules should be expressed declaratively based on common business vocabulary.

An implication for business rules: No direct invocation of functions.

(2) No reference whatsoever should be made to events in expressing business rules.

Exception: Some business rules (a small minority) truly apply only at the time a given business event occurs. Example: A hotel guest must be given fresh cookies upon check-in.

(3) Behavioral rules (unlike decision rules) should always be evaluated immediately when any relevant event occurs. Such ability supports real-time compliance. (Read about behavioral rules vs. decision rules on http://www.brcommunity.com/b623.php.)

One Implication: You have to know what those relevant events are.

(4) The events to which a declarative rule applies can (and should) be determined automatically.

USoft proved the principle 20 years ago. SBVR’s treatment of business rules is based on the assumption.

(5) It’s important to determine the events automatically for behavioral rules because that way you can take programmers out of the business of event detection and management.

The benefits of doing so would be immense.

(6) Events bear a direct relationship to business rules in the sense that behavioral rules need to be invoked automatically when events occur.

How else can you achieve comprehensive consistency of behavior?!

(7) Business rules bear no such direct relationship to processes.

Do we really want programmers and designers to remain in the business of event detection and management forever?! In my opinion that’s a very bad idea.

(8) Some (many?) business capabilities (e.g., highly social ‘processes’) could be modeled and run without business process models altogether.

How would it work? You need:

• Declarative business rules.
• Work milestones (states through which loosely organized work still must progress).
• Automatic event identification (as in USoft).
• Event detection and management (as in Tibco).

 

What should happen when a business rule is broken[1]? As discussed in this post, Business Analysts should answer three questions:

1. How strictly should the business rule be enforced?
2. What message is appropriate?
3. What response is needed?

Developing a friendly, secure business solution requires overt answers to these questions for at least a subset of business rules. (As explained later, defaults can be assumed for the others.) It should also be possible to easily change or evolve the answers (including defaults) after deployment of the business rules, thus permitting the business capability to become incrementally smarter. The goal is context-dependent, pinpoint reaction to breaches in real-time.  Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation. Breach Question 1.  Enforcement Level How strictly should a behavioral rule[2] be enforced? Example …

Business Rule:  A service representative must not be assigned to good customers in more than 3 states or provinces.

Ask:  How strictly should this business rule be enforced?

Enforcement Level:  Override by pre-authorized actor

Table 1 lists the most common enforcement levels for behavioral rules.[3] Table 1.  Common Enforcement Levels for Behavioral Rules

Enforcement Level	Description
strictly enforced	Violations are disallowed in all cases – achieving some newstate successfully is always prevented.
override by pre-authorized actor	The behavioral rule is enforced, but an actor with proper before-the-fact authorization may override it.
override with explanation	The behavioral rule may be overridden simply by providing an explanation.
guideline	Suggested, but not enforced.

  Be sure not to overlook the last enforcement level Table 1.  A business rule that is actively evaluated, but not enforced, is (literally) a guideline. Guidelines are business rules too! Breach Question 2.  Guidance Message What message should be returned when a breach of a business rule occurs? When a business rule is breached, somebody, often a business actor directly engaged in a business process, needs to know about it.  The breach means the work being conducted has strayed outside the boundaries of what the business deems acceptable or desirable.  From a business perspective an error has been made, so some error message should go out.  What should that error message say? As a default, we like to say that the business rule statement is the error message.  From a business point of view, that equivalence must always be true – what else are business rules about?! Rather than saying ‘error message’ (which sounds technical) or ‘violation message’ (which sounds harsh, especially for guidelines), we say guidance message. Generally, guidance messages should be as friendly and as helpful as possible.  For example, guidance messages can be written in a more personal, informative style. More explanation or suggestions can be appended or substituted as desired.  Perhaps a link to other media (e.g., a how-to video) can be provided.  Sometimes the best guidance message takes the form of some icon or signal (e.g., a warning light turning to yellow or red).  Guidance messages frequently need to be specific to the circumstances in which a breach occurs (e.g., what role or user produced it). In all cases, guidance messages should be made available only to people who are qualified and capable. Breach Question 3.  Breach Response Does the breach response for a business rule need to be more selective, rigorous, or comprehensive than simply a message? Example …

Business Rule: A cursory review of a received engineering design must be conducted within 5 business days of the date received.

Ask:  What breach response is appropriate for this business rule?

Breach Response:  The received engineering design must be brought to the attention of the manager of the department by the morning of the next business day.

Breach responses can take any of the following forms:

• business rule (as illustrated above), or set of business rules
• processes or procedures
• sanctions or penalties
• operational business decisions
• special notifications, displays or instructions

Multiple breach responses might be desirable for a business rule. They might also need to be specific to the circumstances in which a breach occurs (e.g., what particular part of a process is being performed). Usually, breach responses serve to increase user-friendliness. In cases of potential fraud or malicious business behavior, however, breach responses should be much more aggressive. Defaults Natural defaults for the three breach questions are listed in Table 2. Table 2.  Defaults for the Breach Questions

Breach Question	Default
enforcement level	strictly enforced
guidance message	the business rule statement itself
breach response	none

 

---