Rules and Processes: Examples Showing How They Relate
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.
- A specialist assigned to a large claim leaves the company or retires. This could leave a large claim without a specialist to monitor it.
- 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.
# # #