Business Rules vs. System Design Choices

by Ronald G. Ross

Excerpted from Chapter 7, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/b_concepts.php

A colleague and I were recently discussing some basic principles of business rules.  In particular, we were discussing what the word "continuous" means in the following statement from the Business Rules Manifesto:^[1]

6.1. A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.

To me, it's rather obvious that "continuous" is as the business would define it, as in "never-ending," "on-going," "all the time," "never know when."  Don't some (probably many) of your business rules change continuously?!  "Continuous" might have some special technical meaning under certain classes of platform, but the Manifesto wasn't written about that.

My colleague went on to said, "Depends on your definition of 'business rule'... if I change a structural rule like 'customers only have 1 address' to 'customers can have multiple addresses' then that can have deep consequences on [automated] systems."

Let's stop right there.  Under Clause 12 of the OMG's 2007 standard, Semantics of Business Vocabulary and Business Rules (SBVR),^[2] "customers only have one address" is not a structural rule.  Structural rules (also called "definitional rules") are rules that are true by definition.  There is nothing in the definition of "customer" or "address" or "have" that requires (in the real world) a customer to have only one address.  (More about definitional rules later.)

Actually I'd say this is not a business rule at all!  Rather, it's a (probably poor) design decision some IT person (probably) has made.  The business wouldn't make a real-world behavioral rule about customers having only one address.  Why?!  But they might make a design decision to record only one.

Until business analysts really begin to understand the difference between rules of the business (business rules), and choices about system design, we'll keep falling to the same requirements and legacy traps as always.  So let's probe the two fundamental categories of business rules:  behavioral and definitional.^[3]

Behavioral Rules

Consider the business rule expressed as:  A gold customer must be allowed access to the warehouse.  Let's assume for now we don't need to consider any exceptions.  Clearly this business rule can be violated.  If a gold customer is denied access to the warehouse, then a violation has occurred.  Presumably, some sanction is associated with such violation — for example, the security guard might be called on the carpet.

Any business rule that can be violated directly is a behavioral rule.  (It doesn't matter whether it is automatable or not.)  Behavioral rules are really people rules.  Basic business operations typically involve significant numbers of behavioral rules.

Behavioral rules always carry the sense of obligation or prohibition.

One way or another, behavioral business rules are always preventative, as the following examples illustrate.

•  Surgical gloves must be worn in performing surgery.
            This business rule is intended to prevent infections.

•  A nurse must visit a patient at least every 2 hours.
            This business rule is intended to prevent inattention to patients.

•  A gold customer must be allowed access to the warehouse.
            This business rule is intended to prevent any denial of access.

Behavioral rules (also called operative rules) enable the business to run (i.e., to operate) its activities in a manner deemed suitable, optimal, or best aligned with its goals.  Behavioral rules deliberately preclude specific possibilities (of operation) that are deemed undesirable, less effective, or potentially harmful.  Behavioral rules remove those degrees of freedom.  Often, sanction is real and immediate if a behavioral rule is broken.

Although the examples of behavioral rules above are not automatable, many can be automated.  Here are some examples:

An order over $1,000 must not be accepted on credit without a credit check.

A high-risk customer must not place a rush order.

An order's date promised must be at least 24 hours after the order's date taken.

Behavioral rules — people rules — are a distinctive feature of the business rules paradigm.  Behavioral rules have fundamental implications in several areas:

Reasoning.  Since behavioral rules can be broken, they require special care in reasoning (automated or otherwise).  Consider the behavioral rule:  A gold customer must be allowed access to the warehouse.  It cannot be assumed that the business rule has always been faithfully enforced; therefore, it cannot be inferred that in every situation where it was appropriate for a gold customer to be allowed access to the warehouse, the customer actually was allowed such access.  Violations happen.  Reasoning must be carefully restricted in this regard for behavioral rules.

Processes.  Behavioral rules have significant (and perhaps surprising) consequences for modeling processes.  A key question in that regard is how the business responds selectively to violations of any particular business rule (if at all!).  That question, in turn, raises the issue of how strictly each behavioral rule should be enforced — that is, its appropriate level of enforcement.

Guidelines

Consider the behavioral rule: An order over $1,000 must not be accepted on credit without a credit check.  Suppose this behavioral rule is restated with a should instead of a must such that it reads: An order over $1,000 should not be accepted on credit without a credit check.  Now does it express an advice (non-rule)?

No.  It is still a business rule, only with a lighter sense of prohibition.  What actually changed was its presumed level of enforcement.  Rather than strictly enforced, now the business rule has the sense:  It's a good thing to try to do this, but if you can't there's no sanction.  In other words, now it's simply a guideline (or suggestion, if you prefer).

Should you use should or should not (or similar forms) to express a lightly-enforced behavioral rule?   Not recommended.  In general, it's better to use consistent wording for all behavioral rules (e.g., must or must not).  Remember, the level of enforcement for any given business rule often varies with changes in business practice.  Guidance is one thing; level of enforcement is another — best not to mix the two!

Two other things about guidelines:

Vocabulary.  A guideline for business operations — just like an advice (non-rule) or any other business rule for the same business — is expressed using the same underlying vocabulary.  Let's put it this way:  If you have the vocabulary to express your business rules, you already have the vocabulary you need to express any guideline.

Guidance Message.  We say that a business rule statement is the guidance message.  (That's something to think about if your methodology treats error messages separately from business rules.  Take a quick look back at the examples of business rules presented thus far in the discussion and think it over.) The same remains true for guidelines.  A guideline can indeed be violated, but no enforcement action is taken.  Instead, the end user (if authorized) is simply informed.  If you think of business rules simply as hard-and-fast constraints, you're missing an important part of the picture.  In the larger sense, business rules are always about dispensing basic business knowledge in real time.  Guidelines are an important part of that overall scheme.

Definitional Rules

Additional business rules would be relevant to evaluating the behavioral rule:  A gold customer must be allowed access to the warehouse.  Specifically, what criteria should be used for determining whether a particular customer is gold or not?  Here is an example:  A customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

Such business rules are called definitional rules.  Definitional rules always carry the sense of necessity or impossibility.

Let's return to our two business rules.  Suppose a customer appears at the warehouse, but the security guard is unaware of the criteria expressed in the definitional rule, or misapplies those criteria.  Quite possibly the customer will not be given due access.  The error, however, manifests itself as a violation of the behavioral rule, not the definitional rule per se.  Definitional rules can be ill-conceived, misunderstood, or misapplied, but they cannot be directly violated.

Evaluation of a definitional rule always classifies or computes something using known facts.  For example:

Classification Rule:  A customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

Given any customer, evaluation of this definitional rule indicates whether the customer is or is not gold given known facts.

Computation Rule:  The total price of an order item is always computed as the product unit price times its quantity.

Given any order item, evaluation of this definitional rule indicates the one result for total price that the known facts justify.

During business operations, definitional rules are used to evaluate 'where you are' — that is, the current state of affairs — as the need arises.  For example:

• Is this customer a gold customer or not?
  
  
• Do we owe this customer a discount on this order?
  
  
• Does this patient have cat scratch fever or something else?

The result reached in each case is only as good as the decision logic given by the business rules.  Poor or misapplied guidance yields poor or inconsistent results.  In that case, some aspect of the knowledge 'breaks down' — it simply does not work properly.

Behavioral rules and definitional rules are fundamentally different.  Disregard for behavioral rules leads to violations and possible sanctions; misapplication of definitional rules leads to miscalculations and off-base conclusions — but only indirectly, if at all, to violations.

If you are concerned about violations, you always need a behavioral rule. Consider the example of a definitional rule given earlier:  The total price of an order item is always computed as the product unit price times its quantity.  Suppose a salesman decides to give a special volume discount to a personal friend.  Again, the original business rule is merely computational; it does not prohibit inappropriate conduct.  For that, you would need a separate behavioral rule — for example:  A special volume discount may be given only to high-volume customers.

Definitional rules (also called structural rules) are about how the business organizes (i.e., structures) its basic knowledge.  They give shape — i.e., structure — to core concepts of the business. 

Definitional Rules and Definitions

Definitional rules clearly contribute to the meaning of concepts.  Obviously definitions do as well. In practice, can a clear distinction be maintained between definitions and definitional rules?

Yes.  A good definition focuses on the essence of a concept — the core meaning of the concept to the business.  Definitional rules, in contrast, indicate the exact lines of demarcation — that is, the precise 'edges' of the concept.  Establishing these lines of demarcation is how definitional rules remove degrees of freedom.

For example, consider an 'essence' definition of gold customer:  a customer that does a significant amount of business over a sustained period of time.  Now compare that with the associated definitional rule:  A customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

The definition expresses the fundamental notion about what gold customer means to the business or, more precisely, to business people.  It is unlikely that basic notion will change — in other words, the notion as defined is very stable.  That stability helps maintain continuity of knowledge within a community over time.  It also aids in training newcomers, as well as in communicating with people outside the business area.  In short, definitions should be aimed at people.^[4]

The definitional rule, in contrast, gives precise criteria for determining whether a customer is or is not gold — criteria that quite possibly will change over time.  Any aspect of business practice subject to change should be treated as a business rule, not embedded in definitions.

References

[1]  Available at:  businessrulesgroup.org/brmanifesto.htm  
The Manifesto is free, only two-pages long, and translated into over a dozen languages.  If you haven't done so already, have a quick look.  No sign-up required.

[2]  This discussion is based on, and consistent with, SBVR.  For more about SBVR, refer to BRCommunity's SBVR Insider section.

[3]  All sample business rules in this discussion are expressed using RuleSpeak^®.  Refer to www.RuleSpeak.com.

[4]  Aiming definitions toward people is a BRS-recommended best practice.  It is supported but not required by SBVR.