Can the same business rule be enforced differently in different contexts? The answer – an important one for re-use of business rules – is yes. This article explains. It also outlines what business analysts need to know to specify contexts of enforcement for a business rule effectively.
Behavioral rules are one of the two kinds of business rules, the kind that can be broken.1 The possibility of violations raises two important questions for business analysts to answer for each such business rule, as follows:
-
How strictly should the rule be enforced? Possible levels of enforcement are presented in table 1 below2
-
How should the rule be enforced – what violation response is appropriate? Such responses can be in the form of sanctions (more business rules), reactive procedures, human intervention, or some combination thereof.
The choice of appropriate enforcement level and violation response for a behavioral rule is always a question of business policy – or if you prefer, a special kind of business requirement.
One question remains though: Can the same behavioral rule have more than one enforcement level and violation response? The answer to this question – an important one for re-use of the rule – is yes.
Let’s take an example. From health insurance we might have the following rule. (On a personal note, I broke my arm several years ago, so this one really hits home!)
|
Rule: The amount claimed for a “sling” must be LE the special limit for an
incidental if the claimant is out-of-state and the claim amount is LE $500.
|
What happens if this rule is violated? The answer is probably ‘it depends’. In other words, both the enforcement level and the response to a violation may be selective to circumstances. That’s especially true if we consider re-use of the rule cross-functionally.
From a business perspective, re-use of the rule means the rule is to be applied at different points with the company’s business process(es). For example, the rule might be used both in responding to customer queries (e.g., “Would I be covered if …?”) and for validating actual claims. Clearly, the appropriate level of enforcement and violation response depends on the situation.
-
For customer queries, there might be no real enforcement at all, simply a polite informational message.
-
For validating claims, the rule is strictly enforced, with outright rejection a real possibility.
Specifying Context for Behavioral Business Rules
Here then is a more complete specification about the business rule using RuleSpeak.3
|
Rule: The amount claimed for a “sling” must be LE the special limit for an
incidental if the claimant is out-of-state and the claim amount is LE $500.
|
|
|
Applicability Condition
|
Enforcement Level
|
Violation Response
|
|
1.
|
The claim is submitted for inquiry only.
|
guideline
|
Return polite message to the submitter.
|
|
2.
|
The claim is submitted for payment.
|
strictly enforced
|
Mark the claim non-payable.
|
This more complete specification introduces the notion of applicability condition. Essentially, applicability conditions represent a kind of externalized “if” condition.
Note that the rule statement remains exactly as it was before – no changes in its expression. Think of the actual business rule then as that part of the decision logic that remains constant even if enforcement levels and violation responses vary for different circumstances.
Why is that important? In a business with 1,000s of rules, keeping your eye on the ‘constants’ is not merely helpful, it’s essential. Otherwise, the number of rules starts to balloon out of control. By the way, that’s one highly undesirable consequence of if-then syntax of rule expression. More on that in an upcoming article.
From a business perspective, an applicability condition can be viewed as a context of enforcement. Potential contexts might fall into any of the following six categories :4
-
A business thing, or verb concept (fact type) about some thing(s).
-
A business process, or input/output thereof.
-
A business location or jurisdiction, or linkage between locations.
-
An organizational unit or role within a business, or work product that is handed-off between such units or roles.
-
A business event (point in time), or period of time.
-
A business goal or objective, or means to achieve it.
The earlier sample business rule specification was based on the second of these, business processes. Since business rules and business processes are so often addressed by business analysts in tandem, that kind of applicability condition is the most commonly recognized in today’s work with business requirements.
Table 1. Levels of Enforcement for Behavioral Rules and Their Implications for Designing Procedures
|
Level of Enforcement
|
Description
|
Implication for Designing Procedures
|
|
strictly enforced
|
If an actor violates the behavioral rule, the actor cannot escape sanction(s).
|
When a violation is detected, the event producing the violation is automatically prevented, if possible, and a designated violation response, if any, is invoked automatically.
|
|
deferred enforcement
|
The behavioral rule is strictly enforced, but such enforcement may be delayed — e.g., until another actor with required skills and proper authorization can become involved.
|
When a violation is detected, the event producing the violation is allowed, and the relevant work is handed off to another worker (possibly by insertion into a work queue). Additional business rules giving timing criteria may be desirable to ensure that action is taken within an appropriate timeframe.
|
|
override by pre-authorized actor
|
The behavioral rule is enforced, but an actor with proper before-the-fact authorization may override it.
|
When a violation is detected, if the actor involved is pre-authorized, that actor is given an opportunity to override the rule. Overrides by actor and business rule should be tracked for subsequent review.
|
|
override with real-time waiver
|
The behavioral rule is enforced, but an actor may request a real-time waiver from another actor having before-the-fact authorization to give such waivers.
|
When a violation is detected, the actor involved is given an opportunity to interactively request a waiver from a duly-authorized actor. Additional business rules giving timing criteria may be desirable to ensure that some action is taken within an appropriate timeframe. Waivers should be tracked by actor and business rule for subsequent review.
|
|
post-justified override
|
The behavioral rule may be overridden by an actor who is not explicitly authorized; however, if the override is subsequently deemed inappropriate, the actor may be subject to sanction(s).
|
When an override of a violation occurs, a review item (with all relevant details) should be inserted into the work queue of an appropriate actor for review and possible action.
|
|
override with explanation
|
The behavioral rule may be overridden simply by providing an explanation.
|
When a violation is detected, the actor involved is given an opportunity to override the business rule by providing a mandatory explanation. Overrides should be tracked by actor and business rule for subsequent review.
|
|
guideline
|
Suggested, but not enforced.
|
When a violation is detected, the actor involved (if authorized) is simply informed/reminded of the behavioral rule.
|
Author: Ronald G. Ross - Featured Speaker, www.AttainingEdge.com. Ron is also Co-Founder & Principal, Business Rule Solutions, LLC
Chair, Business Rules Forum Conference
For more about the author, see www.RonRoss.info.
1 The other kind is called definitional. For more, see What Is a Business Rule?, by Ronald G. Ross, Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL: http://www.BRCommunity.com/a2010/b525.html
2 Business Rule Concepts: Getting to the Point of Knowledge (3rd Ed), by Ronald G. Ross, 2009. p. 135. ISBN 0-941049-07-8 http://www.brsolutions.com/b_concepts.php
3 Basic RuleSpeak guidelines are available for free in English, Spanish, German and Dutch on www.RuleSpeak.com.
4 Based on the six columns (primitives) of the Zachman Architecture Framework.