I am often asked about how rules relate to processes.  I should really say, how business rules relate to business processes.  The simple answer is that business rules off-load various kinds of work from business processes.  There is, of course, more to the story than that.  Since examples sometimes work best, I am devoting this entire column to a sample set of rules, all in RuleSpeak, to illustrate six different kinds of significant off-loading.  See if you agree with these six categories or if you can add more.

1. Branching.  Suppose a process includes the task 'Verify Basic Claim Information', which has the three conditional branches coming out of it:  Valid, Invalid, and Incomplete.  What are the criteria for going one way as opposed to another?  A relevant structural business rule might be:

A claim can be considered valid only if it has all the following:

* An active policy.

* A claimant.

* An incident.

2. Derivation.  Suppose a process involves determining whether an insurance claim is large.  This determination might be off-loaded to some structural business rule(s) such as the following:

A claim is always considered large if the claimed amount exceeds $50,000.

3. Timing.  Timings can make or break effective business operation.  Since timings can cover a highly generalized set of criteria, they should be off-loaded from business processes in the form of operative business rules, as the following example illustrates.

A claimant must be notified within 5 days once their claim has been denied.

4. Iteration.  What limits need to be placed on performing a repetitive task or cycle of tasks within a business process?  Limits on iteration can be expressed as operative business rules, such as the following:

The total number of requests made for additional information for a claim must not exceed 10.

5. Service Level Agreement.  Suppose an unresolved problem or circumstance needs to be escalated to a higher level of authority as it becomes more urgent.  The specifications for such escalation can be expressed as some operative business rule(s), as follows.

A customer service request must be brought to the attention of a supervisor if the request is not resolved within 4 hours.

6. Business Consistency.  One of the most difficult goals for effective business operations is achieving simple consistency in business practice across different situations or scenarios.  Treating rules as a first-class citizen in business architectures (as prescribed in the Business Rules Manifesto) off-loads a significant share of this concern from business processes.  The following operative business rule (which depends on the rule given for "large" in item #2 earlier) illustrates.

A client must be monitored by a specialist if the client has filed a large claim.

This full import of this rule might not immediately meet the eye.  The rule obviously must be enforced when a large claim is filed.  However, there are two other events where a potential violation could also occur, as follows.  The business rule innately covers all these scenarios.

1. A specialist assigned to a large claim leaves the company or retires.  This could leave a large claim without a specialist to monitor it.
2. A claim originally not large when first filed becomes large later (say, because of adjustments, new charges, etc.).  This could also result in a large claim without a specialist to monitor it.

By the way, this rule is not unusual or peculiar at all.  The large majority of business rules are of this type -- that is, multi-event.  A solid architecture supporting both business rules and business processes takes that into account -- indeed, I believe this is nothing less than a defining characteristic of true business rule architectures.

# # #