In the real world (not software), rules can be broken. Why two decades into the 21^st century that obvious reality is still not taken into account in software (e.g., rule engines) is a complete mystery to me. It needs to be corrected!

Rules that people or organizations can break are called behavioral business rules. Think laws, regulations, contracts, service level agreements, etc., etc.

A unique feature of behavioral business rules is enforcement level. How strictly you want a behavioral rule enforced is a different question from the logic it expresses. (See later for more discussion about enforcement level.)

The second major category of business rules is definitional rules. As the name suggests, this kind of rule pertains to forming concepts. Definitional rules cannot be broken; they indicate how things have to be understood.

Definitional rules often take the form of decision rules — rules by which decisions are made. The rules you find in decision models and decision tables are decision rules. Decision rules imply new facts from existing facts — that is, they are about logical implication, able to support what is commonly called inference.

Do behavioral business rules and decision rules ever cross paths? Yes, indeed! All the time.

What happens when they do? Understanding this question brings significant clarity to how business logic should fundamentally work. Indeed, it is basic to handling real-world rules.

Example

To understand the issue, let's take a relatively simple example. Suppose a city is operating its recreational facilities and needs to assess usage fees.

The city has the following behavioral business rule (expressed in RuleSpeak®[1]):

A senior citizen must not be charged a recreational fee for use of facilities.

The city has also created a decision table to determine appropriate usage fees for its recreational facilities based on length of usage and when the usage occurs.

The decision table is actually a set of decision rules, specifically nine of them (the cells highlighted in green). These nine rules could, of course, have been written out as nine individual statements. For example, the rule in the lower right-most cell could have been written as follows (also in RuleSpeak®):

The recreational fee for use of facilities must be specifically $15 if on a weekend during peak hours and for more than 2 hours.

With a well-formed decision table[2] such as the above, however, there is fortunately no need to do so.

In the case of senior citizens, the earlier behavioral rule is in direct conflict with all the decision rules in the decision table. A senior citizen is never to be charged a recreational fee no matter what the circumstances of usage. So, which rule 'wins' in any given case of usage by a senior citizen? Let's consider each of the two possible scenarios.

Scenario 1. The Decision Logic Should Win

Let's suppose you want the decision logic to override the behavioral business rule. (That seems a bit odd in this example, but no matter for this discussion.) Achieving this result is a whole lot easier than you might imagine. That's because definitional rules always win over behavioral rules. Period.

The reason is that definitional rules are about structuring concepts — how you understand the world. That understanding is simply more basic than behavior. Logic dictates it.

Scenario 2. The Behavioral Business Rule Should Win

Let's suppose you want the behavioral business rule to override the decision logic. This is actually a very important case because you want an effective, fail-safe way to deal with exceptions. You also want to keep your decision table logic as simple as possible.

That last point is extremely important. Exceptions have a way of complicating decision tables terrifically! And there are often quite a few of them.

A behavioral business rule over-riding some decision logic is so important that BRS gives it a special name — knock-out rule. A knock-out rule excludes specific cases from 'normal' treatment as specified by the decision logic because the results might be unfair, unseemly, high-risk, or perverse. In the present example, the city wants to honor its senior citizens — not sanction them for exercising(!).

Properly addressing this scenario requires a two-part solution, as follows:

1. The outcome of the decision logic is named differently from the outcome referenced by the behavioral business rule. For example, the outcome (conclusion) of the decision logic in our example might be called suggested recreational fee.


2. The outcome referenced by the behavioral business rule (recreational fee) is 'set' to the outcome referenced by the decision logic (suggested recreational fee). This is a purely procedural step. If the 'set' operation fails due to the behavioral business rule then the behavioral business rule has overridden (knocked-out) the decision logic.

Why is this the correct approach? Remember, definitional rules (including decision rules) can never be broken. Their results have to be taken at face value.

So, if a decision rule indicates the recreational fee has to be $15 under a given set of conditions, then the recreation fee has to always be $15 in those conditions. Full stop.

If there are circumstances when the recreational fee is not $15 in those conditions then you have simply not said what you actually meant. You have named the outcome inaccurately or inappropriately. Perhaps you really meant suggested recreational fee (as above) or normal recreational fee. With business rules you literally always need to say what you mean — and mean what you say.

More About Enforcement Level

As mentioned earlier, each behavioral business rule has an enforcement level (which can be allowed to default). Enforcement level is a fundamental innovation of the OMG's standard Semantics of Business Vocabulary and Business Rules (SBVR).[3] SBVR does not standardize enforcement levels, however; it merely provides business semantics for specifying them.

Enforcement levels are an important means by which highly-adaptable business solutions can be supported. The enforcement level for any particular behavioral business rule is always completely independent of the explicit logic expressed by that rule so either can be changed on its own at any time. A set of common-sense enforcement levels is presented in Table 1.[4]

Another crucial point about SBVR's treatment of enforcement level is that any and all guidelines are business rules too — just not enforced per se. Refer to the last entry in the table.

There's more. When violation of a behavioral business rule is detected, you might have specified some specific violation response(s) (e.g., a procedure to be executed) or some guidance message(s) to be sent to selected actor(s). What a powerful way to automatically spread operational business knowledge to workers in real time in pinpoint fashion!

Table 1. Enforcement Levels for Behavioral Rules and Their Implications for Designing Procedures

References

[1] Refer to www.RuleSpeak.com.

[2] Refer to Decision Tables — A Primer: How to Use TableSpeak (free download) http://www.brsolutions.com/publications/decision-tables-a-primer/.

[3] For explanation and discussion of SBVR, refer to the SBVR Insider section under Standards on www.BRCommunity.com.

[4] Ronald G. Ross, Business Rule Concepts: Getting to the Point of Knowledge (4th ed), (2013), p. 135.

# # #