A recent email exchange proposed the following statement as a rule.  My evaluation of this statement follows below.

The system shall have the capability to record rules and use them to guide its behavior, and shall include among those rules this rule: R.

My response was that in addition to this "rule" I would want to add the following five statements about the system^[1], which seem equally important.

What:  The system shall have the capability to record data and use that data to guide its behavior, and shall include among that data, data such that the system suits this requirement:  R1.

How:  The system shall have the capability to execute processes and use them to effect its behavior, and shall include among those processes ones that give the system the capability to suit this requirement:  R2.

Where:  The system shall have the capability to communicate between locations and use this ability to support its behavior, and shall include among those capabilities the ability to communicate this requirement:  R3.

Who:  The system shall have the capability to interact with users and support them in achieving desired behavior, and shall include among those interactions the capability to query and modify this requirement:  R4.

When:  The system shall have the capability to schedule execution of processes and use such schedules to trigger its behavior, and shall include among those processes the capability to schedule processes in such a way that the system suits this requirement:  R5.

To complete the set, I would reword the original statement as follows.

Why:  The system shall have the capability to evaluate rules and use them to guide its behavior, and shall include among those rules this requirement:  R6.

My point is that what the original statement R described as a 'rule' is really not a rule at all.  Rather, it is simply one of the six innate areas of capability that any complete system should offer.  A well-balanced system, in fact, should provide all six kinds of capabilities in primitive fashion.  This idea, of course, comes straight from Zachman.

Zachman sheds a great deal of light on the issue.  First he says there are six basic varieties of requirement -- corresponding to the six interrogatives.  These are the columns in his Framework.  (Actually, you might say there are twelve because each interrogative has a two-part generic model.  However, that's a little deeper than we need to go here.)  Rule statements fall under the 'why' interrogative.

Second, Zachman says there are distinct viewpoints for which the requirements need to be expressed/developed -- business viewpoint, system viewpoint, class-of-platform viewpoint, and platform-specific viewpoint.  For rule statements, this means there is not just a single variety of rule statement, but actually four.  (There are six rows in the Framework, but in the present context, only four viewpoints mentioned really matter.)  The Zachman answer is simple, elegant and powerful.

By the way, the real sleeper among the above requirements is R4.  Note the prescription "… users can query and modify …".  Extrapolating a bit, this means that the users of the system can report on and change the very requirements for the system.  The class-of-platform implication is that the system must be able to modify itself to suit the changed requirements.

Think of rules as one variety of business requirement that can be externalized (from processes, to users) such that users can change them directly -- and have the system itself instantaneously "changed" (in terms of the logic it will use).  That's the very potent message of the business rule approach.

By the way, we could also talk about externalizing (the specification of) schedules, interfaces, distribution specifications, etc. -- but for now, I'll settle for the rules (business logic).  By using rule engines to run the business logic directly, the rules become highly visible (directly accessible) to authorized parties.  That's the giant step forward that businesses today need desperately!

Notes

[1]  By 'system' in this discussion, I mean a knowledge/record-keeping system to support business requirements.  

# # #