These days we can automate operational business decisions reasonably well — meaning decision rules in decision tables. Not perfectly, but tolerably well. Coding that kind of business logic can currently be off-loaded from programmers to a rule platform, a significant boost for IT productivity.

But programmers are still responsible for another kind of rule-related coding — one that consumes not only huge amounts of resources but has profound impact for both quality of service and quality of data.

Let's explore this issue by looking at a sample rule. A small concept model diagram is shown below to help illustrate the vocabulary the rule uses.

Rule: A customer must be assigned to an agent if the customer has placed an order.

As I always recommend for business rules, the rule has been expressed in purely declarative manner. So, the rule statement does not indicate any particular process, procedure, or other means to enforce or apply it.

Now ask yourself this fundamental question: Why would I need any process model whatsoever to enforce it?! A human can understand and enforce the rule properly without any reference to a process model. So why couldn't a machine?!

In today's world, a huge amount of programmer workload comes from building process models and writing code to enforce rules just like this one. It's a massive workload. There are literally 1,000s of rules like this in a business of any size or complexity — probably 10,000s or more.

Flash Points

Digging deeper, note carefully that the rule expression makes no reference whatsoever to any event when the rule could be potentially violated or needs to be evaluated. The rule expression for example does not say, "When a customer places an order, then [do something]."

That observation is extremely important for the following reason. "When a customer places an order" is not the only event when this rule could potentially be violated and therefore needs to be evaluated. There is another event when this business rule could be violated: "When an agent leaves our company…". When an agent leaves, his assigned customers can be left high and dry, violating the rule. So, the business rule needs to be evaluated at that kind of event as well.

In other words, this rule could potentially be violated during two quite distinct kinds of operational business event:

• The first, "When a customer places an order …", is rather obvious.
• The second, "When an agent leaves our company …" might be much less so.

Both events are nonetheless important because either could produce a violation. I call these clear-cut events the rule's flash points.

If you like to think in terms of decisions, ask yourself what business decision that second flash point corresponds to. Perhaps you could invent one for the purpose, but it wouldn't be very natural from a business point of view.

Now ask yourself this follow-on question: What in current IT approaches and tools ensures you will get consistent results for the rule across all the processes, procedures, and use cases where both the flash points for the rule might occur? And don't forget about ad hoc activity; that is, lightly-scripted or even unscripted business activity.

Unfortunately, the answer today is almost nothing. If the job gets done at all, it's a job for programmers. In other words, it's programmer workload.

And since it's a programmer responsibility, it's error prone. It produces brittle systems that are hard to maintain, especially when your rules change.

By the way, this black hole of programming is one big reason why data quality is frankly so bad many organizations.

Definitional Rules vs. Behavioral Rules

Standing back to look at the whole rules space, this example suggests that from a business (and logic[1]) perspective there are actually two distinct kinds of rules, not just one.

• Definitional Rules

This kind of rule cannot be broken. A definitional rule might be bad or wrong, but it can't be violated. Of course, you can choose to ignore the results, but that's an entirely different matter.

Example: A customer must be considered a gold customer if the customer places more than 12 orders during a calendar year.

Decision rules and decision tables fall into this first category.

• Behavioral Rules

Behavioral rules can be violated or broken. They govern the conduct of on-going activity and so are critical to people, organizations, and business activity. Very roughly, you can think of behavioral rules as business constraints.

Example: A customer must be assigned to an agent if the customer has placed an order.

Usually, behavioral rules can be violated at multiple flash points.

The Watcher

Let's use soccer to illustrate and analyze the enforcement of behavioral rules. Well-known behavioral rules in soccer include offsides and no tackling from behind. These rules are evaluated by a referee watching the on-going activity and judging in real time when there is a violation.

There is no process model needed for playing a game of soccer. What a strange notion that would be!

Instead, for enforcement of behavioral rules soccer features a referee, which I call the watcher, who is external to the activity and able to interrupt it at any time. Detection of, and responses to, violations of behavioral rules occur in real time.

The notion of real-time intervention for enforcement of behavioral rules is critical. As in soccer, you simply can't wait to a later point in the activity to enforce many or most behavioral rules because by then it's too late. The harm done by a violation can compound itself many times over.

The Sources of Behavioral Rules

Are behavioral rules rare? No, not at all!

Our company has been doing business rule projects for more than two and a half decades. We've done many, many 100s of projects across the globe, some with as many as 10,000 captured rules. Not rare at all! I'd say well over 50% of all the rules we capture are behavioral rules.

The natural sources of behavioral rules include laws, acts, statutes, regulations, contracts, agreements, MOUs, deals, licenses, certifications, deeds, warranties, citations, receipts, notices, etc. Last but not least are most business policies.

The fact that we 'find' so many behavioral rules surprises some in the decision community. Respectfully, it's because our approach doesn't restrict itself to looking at just decision models and decision tables.[2] Instead, we think the proper focus is the larger problem of business governance and knowledge coordination.

Notes

[1] Specifically modal logic — alethic vs. deontic.

[2] For example, as under DMN — Decision Model & Notation, OMG (Object Management Group).

# # #