Part 1 of this three-part series distinguished between operative rules and structural rules.  To summarize briefly, operative rules can be violated directly; structural rules cannot.  Instead, structural rules provide criteria that serve as basic building blocks for knowledge.  For example, structural rules determine whether a Customer is or is not a Gold Customer.  Inference rules are clearly of that variety.

What about rules that express how to compute some mathematical result?  Are such rules operative or structural?  Consider the following example:

The total price of an order item must be computed as the product unit price times its quantity.

This rule prescribes criteria for exactly how the result, total price of an order item, is to be computed.  When evaluated or fired, the rule actually produces that result.  The prescribed criteria might, of course, be inadequate or mis-specified, but that simply represents poorly developed logic -- not any violation.  This rule therefore, like all computation rules, is structural rather than operative.

It might be argued that someone could attempt to calculate total price of an order item using some criteria other than that specified by the rule above.  Would not that be a violation?

First of all, if a rule has been specified for how to compute the result, it 'wins' over any other non-rule means to compute that named result.  Otherwise, why bother to specify the rule?!  So if some business worker(s) or IT developer(s) wish to calculate the result using other criteria, they need to name the result differently.  They are certainly free to do so.  For example, they might call the result amount charged to customer for order item.  However, in that case the business would probably want an additional rule:  The amount charged to a customer for an order item must be equal to the total price of that order item.  This new rule could clearly be violated -- so it is therefore operative.

Another argument might be that the original rule could be violated by, say, a salesman who decides to give a special volume discount to a personal friend.  Again, it is important to understand that the original rule merely computes; it does not prohibit such behavior.  For that, the business would need a separate (operative) rule -- for example:  A special volume discount may be given only to high-volume customers.

In general, a best practice for rules is never mix criteria for how a computation should be performed in the same rule as do's and don'ts for how the result of that computation should be applied in actual business operation.  In other words, never intermingle structural and operative elements in the same rule.  Following this guideline not only enhances clarity in both respective aspects, but also improves granularity.  To illustrate, consider the following extension to the sample computation rule given above:

The total price of an order item must be computed as the product unit price times its quantity minus 10% if the order is the first order ever placed by the customer.

Following the best practices advice above, this rule should be broken into several more granular rules, as follows.

Rule 1 (Structural):

The first-time discount must be computed as 10% times the total price of an order item.

Rule 2 (Structural):

The first-time discount must be considered an applicable discount for each order item of the first order that a customer places.

Rule 3 (Structural):

The total price of an order item must be computed as the product unit price times its quantity, minus applicable discounts.

Rule 4 (Operative):

The amount charged to customer for an order item must be equal to the total price of that order item.

Part 3 of this three-part series re-examines the consequences of ill-conceived or misapplied structural rules.

# # #