Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘violations of rules’

How to Make Your Business Rules Context-Sensitive

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

Continue Reading

When is a Business Architecture a Dumb One?

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.


[1] 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.”

[2] Refer to “Breaking the Rules: Breach Questions” http://www.brsolutions.com/2012/06/03/breaking-the-rules-breach-questions/

Continue Reading

Decision Analysis: Don’t Drown in Decisions

Consider the following examples of decisions arising in a regulated environment (acks James Taylor):

Government agency in Europe has regulations relating to Social Benefits. The agency itself must make decisions like “Is this person eligible for this benefit?” and “How much benefit, and for how long, is this person entitled to?”” that conform with those regulations.

An individual company might also have a decision like “Is this person entitled to paid leave to care for a sick child?” that is dependent both on company policy/practices and regulations that relate to social benefits (because they might require companies of a certain size to pay for this kind of leave).

My Analysis Indeed, these are operational business decisions. I’m not surprised, by the way, they are in effect about money. Of course money entails decisions! But here are two important observations. 1. Regulations typically include a great many one-off behavioral rules (“one-off” meaning following no particular pattern). Examples might include:
    • Payment of benefits shall cease immediately upon the death of the beneficiary.
    • Payment of benefits shall not be made to any beneficiary living outside the country for more than 9 months of a fiscal year.
    • Payment of benefits shall not be made directly to any minor.
Is decision analysis suited to capturing/interpreting such one-off rules? Is it meaningful to have a decision such as “Should a benefit payment be made?” Shouldn’t such behavior be presumed automatic (but traceable and adaptable)? A better option is to simply have a task or action such as “Make payment”. Violations of related business rules for any particular case produces exceptions, possibly to be addressed by appropriate messages and/or procedures invoked automatically. That’s how basic business behavior becomes autonomous, so the business can concentrate on matters requiring greater skill, experience or intelligence. If you’re not careful everything becomes a decision. Where do you draw the line? Isn’t there a difference in simply being competent vs. being smart in doing business?

Aside:  Business vocabulary is as always obviously important. For example, does “payment” mean “accrual of benefit”, “act of payment”, “amount of payment”, or something else? No small issue.

(2.) Consider the following (one-off) behavioral rule:

A non-citizen may cash a payment of benefits for a citizen only if married to that citizen and the citizen is not deceased.

What happens in the case of death or divorce, and then the non-citizen tries to cash a payment? There’s no organizational decision involved there. There’s a personal decision … the non-citizen can decide to try to violate the rule … but we don’t really care about that. We only care about detecting the violation. We really don’t need or want an (operational business) decision here, do we? Again, if you have a decision for every possible kind of violation of every behavioral rule, you’ll very quickly drown in decisions. Don’t go there!  

Continue Reading