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.

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
• The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
• Continues vigorously after deployment, not just during development.
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

---

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

 

---