Premise and Conclusion

Rules and Compliance Tactics

by Ronald G. Ross

In this one-per-month special 'notepad' series, I am taking a quick look at important issues facing practitioners who are seeking to understand and apply the business rule approach for capturing business requirements and developing business systems.

Actions of some kind are almost always associated with rules.  Consider the following sample rules and how you might go about enforcing them.^[1]  These samples are rejector-type rules, which are loosely about preventing undesirable things from happening.^[2]

Never put your finger in an electric socket.

• Provide a live demonstration by showing what happens when the rule is violated.  (Not recommended.)
• Follow your children around and pull them away every time they try it.  (Very tiring.)
  
• Put caps in the plugs so they can't put their fingers in it.
  
• Teach the rule to your children.

Hard hats must be worn by anyone on a construction site.

• Stand by the gate and make sure everyone entering the site has a hard hat on.
  
• Hire hard-hat monitors to patrol the site looking for violations.
  
• Put up a sign.
  
• Include this rule as a training item for orientation of new employees.

Organizations almost always take measures to enforce their rules.  Sometimes, because of the degree of risk involved, these measures are extreme.  Just consider an airport's rule, Never bring guns or knives on board an aircraft.  Some rules, on the other hand, are rarely enforced at all.  For example, most cities have rules against jaywalking, but I can think of quite a few cities where I've never actually seen those rules enforced.

• Is a rule still a rule even if there is no enforcement action currently taken for it?  Yes. It may be a rule without teeth, but it's still a rule nonetheless.
  
• Is the action taken to enforce a rule the same as the rule itself?  Obviously not.  As above, the enforcement action can change, while the rule stays the same.  So they are obviously different.
  

  Aside:  I would call such actions compliance tactics.  These should be specified for each rule as part of modeling business requirements.

• Is the level of desired enforcement for a rule the same as either the rule itself or the action taken to enforce the rule?  No.  Level of desired enforcement is a property that can be specified for a rule itself; the enforcement action is a process intended to achieve that rule's level of enforcement.

In closing, let's consider an additional sample rule:  The in-basket-status-light shall be red when the in-basket is empty.  For the sake of argument^[3], let's assume that the rule will automatically change the state of the light to red when the last item is removed from the basket, and change the state to not red (or off) when the first item is placed into it.

Several important observations can be made about this rule.

• Assuming a physical in-basket (say, made out of wood), this rule really refers to a class-of-platform (non-automated in-baskets).^[4]  So we are no longer dealing with rules at a conceptual (business) level; we are now actually starting into implementation of the business requirements.
• The expression of the rule is based on the specific technology of that platform -- e.g., a red light attached to the wooden in-basket that can be switched on or off automatically.  The business-level counterpart for this rule might be something like:  A new work item should be assigned to an idle worker.
• The act of switching light on or off is actually a process -- not a rule.  However, it is a process that can be performed automatically by a rule^[5]. So the final word about rules and actions is that a rule can sometimes automate a required process arising within the chosen technical solution.

References

[1]  Examples courtesy of Stan Hendryx.

[2]  Refer to Principles of the Business Rule Approach, by Ronald G. Ross. Addison-Wesley, Boston, MA, 2003, Chapter 6.

[3]  We cannot tell for sure from the rule statement whether this automatic action is actually intended or not -- this is a point that should be clarified with the designers and the rule revised accordingly.

[4]  We could have also made the in-basket automated -- that too is a class-of-platform -- but a wooden in-basket provides a more tangible example here.

[5]  Specifically, an enabler-type projector rule.

standard citation for this article: Ronald G. Ross, "Rules and Compliance Tactics," Business Rules Journal, Vol. 5, No. 3 (Mar. 2004), URL:  http://www.BRCommunity.com/a2004/b157.html