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.

A rule is a bit of declarative logic that is required to be true.  Here is an example:  A salesperson may sell a product only if that salesperson represents some manufacturer that produces that product.  Some action may be implied by the rule to maintain its truth (the point can be debated), but in any case such actions are under the covers (so to speak).  They are not of any direct concern to designers, nor any direct concern to implementors when the class of platform used for implementation is a rule engine.

Actions, on the other, are of direct concern to both designers and implementors (even when the class-of-platform is a rule engine).  In part, the reason is that the sequence of action-taking is always of direct concern because the outcome (of executing the process) depends on it.  The sequence of rule evaluation, in contrast, should make no difference whatsoever to the outcome (of the evaluation).

These distinctions can be difficult to grasp for those who have never been exposed to a rule engine.  Traditionally, rules have often been implemented as actions -- that is, as executable statements in some kind of programming language that executes statements.

The important thing to remember is that execution style depends on the class of platform.  In a rule engine environment, rule statements in declarative form are evaluated (not executed) by the system (rule engine) so the system can take responsibility for ensuring correctness of state, infer new facts, etc.  The system (rule engine) takes whatever actions are required.  That's nothing whatsoever like writing transforms (actions) in some procedural 3GL or 4GL and then deliberately executing them.

A counter-argument might be the observation that rules are often executed as actions in everyday human activity.  Police patrol.  Inspectors inspect.  Courts sentence.  Employee asks, "What are you doing?"  Supervisor replies, "Just checking to see if you are wearing your safety glasses."  Rule enforcement seems like 'actions.'

But to understand rules, you must separate the rule statement from the enforcement regimen chosen for the rule.  The enforcement of non-automatable rule statements (e.g., A hardhat must be worn by any worker working in a construction site) can be implemented only through procedures (scripts) and job responsibilities of those participating (e.g., the supervisor) in the activity.  But that doesn't in any way affect the rule statement.

For automatable rules (e.g., A group must not include both union and non-union members), you have at least two fundamental choices about how to enforce the rule.

1. You can emulate people in the real world, creating some sort of enforcer object (or something) whose 'responsibility' is to enforce the rule.
   
   
2. You can take advantage of the logic processing potential of computers and hand over the 'enforcement' of the rule to a rule engine (just like you hand over the management of data to a DBMS).

The latter choice is clearly better for many reasons.  Let me single out just one.  Analyze the 'group' rule given above, and you will discover there are several specific events where the rule needs to be evaluated, roughly including the following:

1. when a new group (with two or more employees) is formed
   
   
2. when a person (who is a member of a group with at least one other member) joins a union or drops out of a union
   
   
3. when a new member is added to an existing group that already has another member

The problem with procedural approaches to rule enforcement is that you have no guarantee of consistent or comprehensive enforcement across all the procedures and actions that might produce those events.  Multiply that by the hundreds or thousands of rules associated with a typical business process.  At that scale, the quantitative difference produces qualitative differences in the rule-enforcement issue.  Time to move to a better paradigm!

A current goal in the IT industry is to make system models transformable into executable components.  Obviously you want such transforms to be trustworthy and consistent and manageable.  As far as I can see, as complexity in business logic scales up by orders of magnitude, the only conceivable way to achieve these goals is to address the business logic directly -- that is, a as a primitive.  'Directly' here means (a) based on shared semantics (terms and facts), (b) expressed directly as rules, and (c) supported by the right class of platform -- rules engine.

# # #