Can You Violate Structural Rules? (Part 1) ~ The Difference Between Violations and Bad Decisions
|This issue's column is another installment of my periodic 'notepad' series, which focuses on specific issues facing practitioners seeking to understand business rules and make them part of their company's approach to requirements and system development.|
Let's put the following business rule under the microscope: A gold customer must be allowed access to the warehouse. Clearly this rule can be violated. If a gold customer is denied access to the warehouse (assuming there are no extenuating circumstances, such as exception rules), then a violation has occurred. Presumably, there is a sanction associated with such violation -- for example, the security guard might be called on the carpet. Any rule that can be violated in that sense is an operative rule.
Note that there are additional rules bearing on evaluation of the warehouse rule. Specifically, what criteria are appropriate for determining whether a particular customer is 'gold' or not? Such rules are called structural rules.
If a Customer appears at the warehouse, but the security guard is unaware of such criteria, misapplies them, or uses the wrong ones, quite possibly the Customer will not be given due access. The error, however, manifests itself in the form of a violation of the operative rule, not the structural rule(s) per se. Structural rules can be ill formed or misapplied, but they cannot be directly violated.
This is a significant difference between operative rules and structural rules. To re-iterate, disregard for operative rules leads to violations and possible sanctions; misapplication of structural rules leads to mistakes and undesirable results -- but only indirectly, if at all, to violations.
It would seem then that structural rules, in contrast to operative rules, are more 'definitional' in nature. In a general sense, that is true. However, in practice a clear distinction nonetheless can and should be maintained between definitions and structural rules. Specifically, a definition should focus on the essence of a concept -- its meaning to the business -- whereas structural rules should indicate exact lines of demarcation. Consider an 'essence' definition of Gold Customer as compared to an associated structural rule:
Defining Statement: A Gold Customer is a Customer that does a significant amount of business over a sustained period of time.
Structural Rule: A Customer must be considered Gold Customer if the Customer places more than 12 orders in a calendar year.
The definition provides a clear idea about what 'Gold Customer' means to the business. It is unlikely that basic notion will change -- in other words, the notion as defined in the manner above is very stable. The structural rule, in contrast, gives specific criteria for determining whether a Customer is or is not 'Gold' -- criteria that quite possibly will change over time.
Another difference between definitions and structural rules is that the latter frequently give criteria that would not be obvious given the definition. Here is an example:
Structural Rule: A Customer may be considered a Gold Customer only if the Customer was incorporated more than a year ago.
Incidentally, this rule -- although not in the form of an 'if-then' statement -- is actually an inference rule. Indeed, inference rules are structural, rather than operative.
A complex decision point may involve hundreds or even thousands of inference rules. Their application and evaluation, however -- no matter how many rules are involved -- cannot directly result in a violation. Although the result might be quite serious for the business -- perhaps even calamitous -- technically, no violation has occurred. The result would simply represent a really, really bad decision.
Part 2 of this three-part series will examine rules for mathematical computation, applying the same criteria as above to determine whether they are operative or structural.
# # #