In last month's column, we discussed the difference between decomposition of processes vs. reduction of the business logic expressed in rules.  In this month's column, we take a closer look at rule or logic reduction itself.^[1]

Business Rule Solutions (BRS) broadly categorizes rules into governing rules, operating rules, and automated rules.  Traceability for business logic results when information about the 'what, how, where, who, when, and why' of rule reduction from one level to the next is retained in an organized manner (e.g., in a rule repository).

• Governing Rules tend to be high-level directives with broad applicability -- for example, Thou shalt not steal.  In business, such rules are often called policies.  On their own, governing rules are usually not directly actionable.  (For example, what is the meaning of 'steal' and how does that interpretation apply in various specific circumstances?)  Nonetheless, they do (or should) govern all actions in a general way.

• Operating Rules are interpreted from governing rules.  An operating rule must be actionable -- that is within the specific context(s) to which it applies, it should provide unambiguous guidance.  For example in context of settlement activity, an operating rule might be:  The amount settled for an item on an order must be equal to the amount ordered for that item.

• Automated Rules are representations of rules in a form that a computer (e.g., rule engine, 3GL, etc.) can directly evaluate.  They are the 'coded' counterparts of operating rules, sometimes having gone through significant translation and/or re-composition to satisfy the syntax understood by the given class of platform.

What are the linguistic properties of governing rules?  Since we are not likely to have much luck reinventing the language of lawyers, politicians, regulators, or CEOs and other company managers, this should probably be considered outside our control.

What about the linguistic properties of operating rules?  In RuleSpeak™, a rule statement must include one of the keywords must or only.  Everything else in the rule statement (except for articles to increase readability and quantifiers of various kinds) are explicit fact statements from the associated fact model (i.e., structured business vocabulary).

Let me clarify what I mean above when I say an operating rule must be actionable.  It literally means that a worker can read it and know how to act in a given situation.  I do not mean that the operating rule could necessarily be understood in the context of a knowledge/record-keeping system.  (Translation to that format should happen eventually -- sometime during system design -- but this is not the discriminator for operating rules.)

I definitely do not mean that the operating rule could be understood (i.e., evaluated or interpreted) by any kind of hardware/software platform!  That would put things into the realm of class of platform -- that is, models for automation -- and that's nothing you should be worrying about for either the business model (Zachman row 2) or system model (Zachman row 3)!

References

[1] Acks to Stan Hendryx for his input to this column.  

# # #