Your ability to respond in appropriate ways to pinpoint circumstances where business rules are breached – automatically and independently of processes – provides the mechanism you need to support very smart, very friendly business systems. Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred. Can breaches occur for decision rules too? The answer is yes and no. Read on!
A breach occurs for a business rule when the business rule isn’t satisfied upon being applied to some set of circumstances (state of affairs). Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit).
The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule:
1. What level of enforcement should be applied.
2. What special response to a violation is appropriate, if any.
3. What special message, if any, should be returned to some worker(s) upon a violation.
Unlike behavioral rules, no definitional rule can ever be violated. Literally, things must be correct under such rules by definition.
Let’s take an example. Suppose somebody asserts “2+2=5”. According to the rules of mathematics, we know the correct answer is 4. The answer “5” is deemed irrevocably wrong. But is the asserted answer ever allowed to stand?
If the rule is defined as a decision rule, the asserted answer is never allowed to stand. More precisely, the assertion would never be recognized to have happened in the first place. If someone asserts “2+2” the answer “4” is concluded immediately. Period. No breach, no opportunity for error.
If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized. How might that capability be useful? Suppose the error were made by a student in grade school. It might be quite useful for the student and/or a tutor to know about it immediately and automatically. Specifying an appropriate violation response can make such notification happen.
In business, of course, definitional rules can be far more complex. Nonetheless, your ability to respond in appropriate ways to the pinpoint circumstances where certain rule-related events occur – automatically and independently of processes – provides exactly the mechanism you need to support very smart, very friendly operational business decision systems.
Decision Rules and Breaches
Decision rules are a special kind of definitional rule involving implications (e.g., A implies B). They support inferences and determinations – identifying an appropriate outcome from among a set of alternatives.
Like all decision rules, definitional rules cannot be violated. They are simply deemed true by definition.
Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred. I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic. You perceive a breach of a decision rule simply because it’s useful to do so, not because any true violation has occurred.
In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the ‘happy path’. Think of a breach of a decision rule as a bump in the road – a gap along the happy path.
Let’s return to the three questions listed earlier. Although the first question about enforcement level obviously doesn’t apply to decision rules, adjusted versions of questions 2 and 3 remain in play.
Consider the following simple business example. Suppose a bank has this decision rule:
A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:
date of birth
Social Security Number
Let’s suppose that an applicant uses just the initial for her middle name on her credit application. If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free.
Note carefully the rule hasn’t been violated; it did its ‘work’ correctly and it did reach the proper conclusion (not discrepancy-free). But a gap – a breach – for her case has been identified from a business perspective because the rule failed on one of the conditions. We should be able to take advantage of that breach to take appropriate action – selectively, automatically and in real time.
For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member: “Review discrepancy and manually ok if appropriate”. (The to-do item should naturally also provide ready access to the related documents.) The breach of the rule causes this action to occur automatically.
Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have. Could you build a responsive system by incorporating the selective responses needed into the related process model(s)? Not a chance – that approach won’t scale. Instead, the selective responses need to be specified based on the business-rule side of things.
Kinds of Breach Specifications for Decision Rules
Breach specifications for a decision rule can be of the following two kinds.Breach Response. A breach response can be an action of virtually any kind. For example, a breach action might be to:
Add some task(s) to a (non-redundant) to-do list in some appropriate work queue.
Add some documentation items to a (non-redundant) not-yet-received list.
By these means very selective follow-up processing/handling (“what to do next”) can be organized pertaining to any specific issue (breach) for a given case. Such selectivity is made possible by the granularity of the rules.
Breach Message. A specially-worded breach message can be forwarded to any involved party either inside or outside the company. A breach message generally explains one or both of the following at any level of detail desired:
Why the rule or condition failed. (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)
What should be done to address the issue.
More Complex Example
Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions. A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application). An example of a decision rule with condition-specific breach specifications is illustrated in Table 1.
Table 1. Example of More Complex Decision Rule with Condition-Specific Breach Specifications
A fluctuating income must be considered eligible if all the following are true:
Conditions of the
the applicant has a 3-year proven track record of consistent income
the applicant is likely to have comparable income in the future
Add to-do item for that credit application: “Contact employer to verify applicant has reasonable opportunity for future income.”
the income is validated
Add required documentation items not yet received to a pending list for the credit application.
To applicant: “[date] Here’s a list of documentation items related to your income we have not yet received. [pending list].”
Using Breach Specifications
Breach specifications can be:
General for an entire decision rule including all its conditions. (The example in Table 1 doesn’t include any whole-rule specifications. If the rule did they would appear in the first row.)
Specific to a given condition.
Specific to collections of conditions (none shown for the example).
A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true. Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred). Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation.
Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition). The goal is to move things forward in the case. In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined. A behavioral rule to that effect should be specified.
In hierarchies of decisions (e.g., as in Q-Charts) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition. A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true. Define breach specifications at the lowest level of granularity.
Although rules can be specified in violation specifications for behavioral rules (e.g., to express some sanction or penalty), they should never be specified within breach specifications for a decision rule. Such ‘nesting’ of rules, especially on the basis of ‘not true’, is inappropriate.
Otherwise the advantages of overall declarative specification can be forfeited.
By default, breach specifications for a decision rule apply only the first time it is evaluated for each case. The assumption is that all business rules, including decision rules, are evaluated on a continuous basis. Re-application of any breach specification for a case therefore requires additional timing and iteration criteria. Whether a case is evaluated iteratively on the same set of decision rules based on timing criteria applied by or for some external process or platform is outside the scope of this discussion. No matter what the scheme of evaluation, the expression of the decision rules – as for all business rules – should be completely unaware of it.
In a recent discussion on social media I was explaining what I thought would make a business architecture smart. Tom Graves replied that he wasn’t sure what made one smart, but that he did know what makes one dumb. His criteria …
rigid rule-based boundaries.
over-reliance on rigid true/false rules.
attempts to implement most or all of that architecture through automated ‘business-rules engines’ that can only work with rigid true/false rules.
He went on to say that these criteria suggest that “a first requirement for a smart business-architecture is that it go beyond all these mistakes.”Tom’s emphasis on ‘true/false’ rules needs to be carefully qualified. After all, you do want the internal workings of a rule engine to be based on formal logic. I believe what he really means is an approach that allows no shades of gray with respect to nuanced enforcement of business rules. On that point I hardily agree.In addition, Tom got me to agree with him on two major points about the current state of the industry. In his words …
1. The quest for ‘certainty’ in an inherently-uncertain world is futile. Rules of all kinds exist to help human thinking and human judgment, not to act as a substitute for it.
2. The software vendors … are frankly not far short of committing fraud with many of the claims they make as to the efficacy and validity of their ‘business-rules engines’.
The term business rule unfortunately has been hijacked by software vendors to mean something very different from the original concept. For example, production rules (the basis for the majority of current product offerings) are not business rules. Full stop.This distorted view of business rule needs to be rectified. Don’t let yourself be sucked into it! For real business rules there are three (optional) supplemental specifications for each business rule statement:
(1) level of enforcement
(2) violation (breach) response
(3) violation (breach) message.
It is through these specifications that the richness of behavioral coordination can arise.
Production rules (also called productions) can be used to implement business rules, but are not business rules per se. Production rules typically provide support for action selection, which results in non-declarative statements. According to Wikipedia, a production rule system (essentially, an expert system) is …
a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules about behavior
Production rule systems are a class of platform whose rule format and operation are aimed toward developers. According to Wikipedia:
“A production system provides the mechanism necessary to execute productions in order to achieve some goal for the system. Productions consist of two parts: a sensory precondition (or ‘IF’ statement) and an action (or ‘THEN’). If a production’s precondition matches the current state of the world, then the production is said to be triggered. If a production’s action is executed, it is said to have fired.”
What should happen when a business rule is broken? As discussed in this post, Business Analysts should answer three questions:
How strictly should the business rule be enforced?
What message is appropriate?
What response is needed?
Developing a friendly, secure business solution requires overt answers to these questions for at least a subset of business rules. (As explained later, defaults can be assumed for the others.) It should also be possible to easily change or evolve the answers (including defaults) after deployment of the business rules, thus permitting the business capability to become incrementally smarter.The goal is context-dependent, pinpoint reaction to breaches in real-time. Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation.Breach Question 1. Enforcement LevelHow strictly should a behavioral rule be enforced?Example …
Business Rule: A service representative must not be assigned to good customers in more than 3 states or provinces.
Ask: How strictly should this business rule be enforced?
Enforcement Level: Override by pre-authorized actor
Table 1 lists the most common enforcement levels for behavioral rules.
Table 1. Common Enforcement Levels for Behavioral Rules
Violations are disallowed in all cases – achieving some newstate successfully is always prevented.
override by pre-authorized actor
The behavioral rule is enforced, but an actor with proper before-the-fact authorization may override it.
override with explanation
The behavioral rule may be overridden simply by providing an explanation.
Suggested, but not enforced.
Be sure not to overlook the last enforcement level Table 1. A business rule that is actively evaluated, but not enforced, is (literally) a guideline. Guidelines are business rules too!
Breach Question 2. Guidance MessageWhat message should be returned when a breach of a business rule occurs?When a business rule is breached, somebody, often a business actor directly engaged in a business process, needs to know about it. The breach means the work being conducted has strayed outside the boundaries of what the business deems acceptable or desirable. From a business perspective an error has been made, so some error message should go out. What should that error message say?As a default, we like to say that the business rule statement is the error message. From a business point of view, that equivalence must always be true – what else are business rules about?! Rather than saying ‘error message’ (which sounds technical) or ‘violation message’ (which sounds harsh, especially for guidelines), we say guidance message.Generally, guidance messages should be as friendly and as helpful as possible. For example, guidance messages can be written in a more personal, informative style. More explanation or suggestions can be appended or substituted as desired. Perhaps a link to other media (e.g., a how-to video) can be provided. Sometimes the best guidance message takes the form of some icon or signal (e.g., a warning light turning to yellow or red). Guidance messages frequently need to be specific to the circumstances in which a breach occurs (e.g., what role or user produced it). In all cases, guidance messages should be made available only to people who are qualified and capable.Breach Question 3. Breach ResponseDoes the breach response for a business rule need to be more selective, rigorous, or comprehensive than simply a message?Example …
Business Rule: A cursory review of a received engineering design must be conducted within 5 business days of the date received.
Ask: What breach response is appropriate for this business rule?
Breach Response: The received engineering design must be brought to the attention of the manager of the department by the morning of the next business day.
Breach responses can take any of the following forms:
business rule (as illustrated above), or set of business rules
processes or procedures
sanctions or penalties
operational business decisions
special notifications, displays or instructions
Multiple breach responses might be desirable for a business rule. They might also need to be specific to the circumstances in which a breach occurs (e.g., what particular part of a process is being performed). Usually, breach responses serve to increase user-friendliness. In cases of potential fraud or malicious business behavior, however, breach responses should be much more aggressive.DefaultsNatural defaults for the three breach questions are listed in Table 2.
Table 2.Defaults for the Breach Questions
the business rule statement itself
Fundamental to business analysis with business rules is the assumption that breaches of business rules can be detected. If you can’t detect breaches, how can you run the business?! To say it differently, if you can’t detect breaches of a business rule, but you can still run the business, perhaps you don’t need the business rule at all(!).
This breach question applies only to behavioral rules. Since definitional rules must always be true, they are in essence strictly enforced.
Table 12-1 of Business Rule Concepts, 3rd Ed. (Chapter 12) discusses additional enforcement levels. It also provides tips for designing procedures with business rules.
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”