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]:

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[2] 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[3] 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:

• name
• date of birth
• Social Security Number
• current address
• previous address

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.[4] 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

Decision Rule	Breach Response	Breach Message
A fluctuating income must be considered eligible if all the following are true:
Conditions of the Decision Rule
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).[5] 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.[6] 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[7]) 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. ~~~~~~~~~~ www.BRSolutions.com

---

Want context-sensitive business rules? It doesn’t necessarily work the way you think it might. Let’s take an example: A client must have a physical address. That’s the rule; it just says what it says. Separately from the rule itself, several things can be specified:

• How strictly the rule is to be enforced. Such specification might be: ‘strictly enforced’, ‘override with prior authorization’, ‘override with explanation’, ‘guideline’, etc.
• What response and/or message is appropriate when the rule is violated.

Both things can be specified to be context-dependent. Back to the example:

• Suppose the rule is violated in signing up as a member of a website. The enforcement level might be “guideline” and the response might be “We encourage you to provide this information so that we may serve you better in the future.”
• Suppose the rule is violated in placing an order. The enforcement level might be “strictly enforced” and the response might be “We’re sorry. But we need your address to send you this order.”

The rule is (still) the rule. It still reads: “A client must have a physical address.”. It hasn’t changed one iota. But its application has now become context-sensitive. People think often think they have far more rules than they actually do. They simply haven’t provided the differential breach specifications needed. I discuss breach responses in the post: http://www.brsolutions.com/2012/06/03/breaking-the-rules-breach-questions/ www.BRSolutions.com

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[1] (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[2]:

(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.

What should happen when a business rule is broken[1]? As discussed in this post, Business Analysts should answer three questions:

1. How strictly should the business rule be enforced?
2. What message is appropriate?
3. 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 Level How strictly should a behavioral rule[2] 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.[3] Table 1.  Common Enforcement Levels for Behavioral Rules

Enforcement Level	Description
strictly enforced	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.
guideline	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 Message What 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 Response Does 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. Defaults Natural defaults for the three breach questions are listed in Table 2. Table 2.  Defaults for the Breach Questions

Breach Question	Default
enforcement level	strictly enforced
guidance message	the business rule statement itself
breach response	none

 

---

guest post by Jan Purchase, Director of Lux Magi Ltd ~~~~~~~~~~~~~~~~~~~~~ I do see value in distinguishing ‘policy’ rules from ‘expert’ rules. It’s also clear that, at their extremes, these rule types are poles apart. Still I fear that this distinction may be a continuum rather than a discrete dichotomy. Policy rules might be exemplified as the constraints of business operational practice – the rules that dictate what a company should and should not do. They might be mined from the boundary conditions of the fact model of the company’s business capability – as you suggest in your excellent book on this subject[1]. An example policy rule might assert, for example, “A company agent may be assigned to a high-value customer only if the agent is assigned to at most five other clients”. Expert rules, on the other hand, are often seen as more complex – for example, using heuristics to determine the best, anti-cancer drug to apply in a given situation, or forecasting regional sales opportunities. Often these expert rule bases use expert experience, genetic algorithms, fuzzy logic and feedback loops to reach a decision. They seek to augment, or even supplant, the wisdom of a small population of subject matter experts. But isn’t there a middle ground too? Consider an insurance policy decision rule that bin-sorts clients into good, bad and medium risk (the latter to be referred to a human underwriting expert). If this were a simple four-row, decision table based on the value of the policy and the risk profile of a client, you would probably consider it a ‘policy rule’. But if I add scorecarding, heuristics and analytics, at what point does it become an ‘expert rule’? Would you consider all decision rules (as opposed to constraint rules) to be ‘expert rules’? Or do they need to be complex or directly represent the experience of SMEs? Don’t all rules, to some extent, represent the wisdom of experts? Don’t many of them constitute and inform policy? In short: Is there a simple question we can ask (concerning a rule) to determine if it is a ‘policy’ or ‘expert’ rule? ~~~~~~~~~~~~~~~~~~~~~~~~ See my reply to Jan: http://www.brsolutions.com/2012/05/29/the-debate-continues-expert-systems-vs-business-rules/ Answer to Jan’s Question: The question to ask of every rule is whether the end-point is enforcement or is it a decision. An enforcement rule never becomes a decision rule, and a decision rule never becomes an enforcement rule. Once an enforcement rule, always an enforcement rule (assuming you don’t retire it). You can adjust thresholds (e.g., the mph of the speed limit), you can change the enforcement level (e.g., from ‘strictly enforced’ to ‘override with explanation’), you can change the sanctions (or eliminate them), etc., etc. And you can and should use analytics to measure and improve the rate of success in achieving underlying business goals. But it’s black and white. Enforcement is enforcement and decisions are decisions.

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).

In football, when a referee throws a flag, the results of the most recent transform (play) are undone. In effect, by enforcing a rule, the referee prevents or negates the new state (yardline and sometimes the down) and enforces some other state. That’s the way behavioral business rules[1] work. Speed through a school zone and see if your desired state isn’t modified if some policeman happens to be watching. The relationship between behavioral rules and business processes is an indirect one, through state. Business tasks try to produce new states; behavioral rules step in to modify or prevent the new state if a violation occurs … just like the policeman parked in the school zone with a radar gun. More precisely, business tasks precipitate events that try to change state (the outputs, final or interim), and behavioral rules ‘watch’ for the particular events that produce violations. A violation produces a response, which can be another process – e.g., the referee jumping in to whistle the play dead or the policeman putting down his doughnut and chasing you. Yes, it’s important know which business tasks can violate which behavioral rules, but their relationship more complexly networked than you might think. In general, every behavioral rule expressed declaratively can be analyzed to produce two or more events (I call them flash points) where it can be violated and needs to be evaluated. I can provide endless examples. (Refer to http://www.brcommunity.com/b623.php?zoom_highlight=flash+point or to Chapter 8 of Business Rule Concepts, 3^rd ed.) These events are likely to be in different business processes (or procedures or use cases) … and sometimes a given process may not have been modeled at all (or the event occurs ‘spontaneously’). The fact that each behavioral business rule can be violated at two or more flash points is a fundamental insight of the business rule approach. It’s precisely where current platforms, tools and methodologies fall short, and why consistency and compliance are so difficult to achieve. In other words, it’s an essential idea in really ‘getting’ business rules.

Consider the following behavioral business rule: A renter must not have possession of more than one rental car. In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’. Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about? When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.

• There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
• There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
• If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.

A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in. Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules). Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc. We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t. Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.