My Idea: Business Rules Are the Error Messages
Just-in-Time Processes and Knowledge Companions Too

To understand my idea, first you have to "get" business rules. If you're reading this from the web and you're new to rules, I suggest you start with My Story.

When you do start to get business rules, a whole lot of other pieces of the puzzle fall right into place. You arrive at smart knowledge management, smart processes, and smart architectures, which I call point-of-knowledge architectures. You'll see why in just a minute. For these reasons, as I've said many years, 'Business rules are inevitable!'.

I first started talking publicly about these ideas in 1994. The insights arose from many years of applied research starting in the mid-1980s and culminating in the publication of The Business Rule Book (first edition) also in 1994. Actually, that milestone was just the beginning of a long and exciting journey, which continues to the present day.

Sketching Smart Architectures

Let me use an example to sketch the way business rules should work in a business system architecture. This example, illustrated in figure 1, is the very same one I've been using since 1994 ¹.

• Suppose you have a process model or procedure that can be executed 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.

• There are business rules that pertain to this event. One of those rules is, "A customer that has placed an order must have an assigned agent."

• We want real-time compliance with business policy, so this rule needs to be evaluated immediately for the order.

• So the system evaluates the rule. Again, it doesn't much matter what component in the system does this evaluation; let's just say some rule service knows how.

• Suppose the customer placing the order does not have an assigned agent. The system should detect a fault (technically a violation of the rule); that is, the system should become aware that the rule is not satisfied by the current state of affairs.

• The system should respond immediately in some way to this 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 actor is authorized and capable).

• The question is, what exactly should the error message say?

Obviously, the message can include all sorts of 'help'. But the most fundamental thing it should say is what kind of fault has occurred from the business perspective. In other words, it should start off simply by literally saying, "A customer that has placed an order must have an assigned agent."

So here we arrive at the first and most basic part of my idea: The business rule statement is the error message! If your IT development methodology has not yet integrated its handling of 'error messaging' with the notion of business rules, it's simply missing the boat.

Actually, this idea is hugely simplifying. What you capture up-front as business rules is the real thing the system can then show you day in and day out, once it becomes operational. That's a system putting on a smart face, a knowledge-friendly face. And by constantly reminding workers of the current business rules in real-time, it yields an environment perfectly suited to rapidly identifying opportunities to evolve and improve the rules. That's an open door to continuous improvement and business agility.

Smarter and Smarter Responses

To make this approach work, you need business-friendly guidelines for writing and communicating rules in declarative form. We offer RuleSpeak® for this purpose (see www.RuleSpeak.com). RuleSpeak was one of three reference notations used in the creation of SBVR, Semantics of Business Vocabulary and Business Rules, and is consistent with that standard. You will also need to sharpen your business vocabulary, something producing all sorts of benefits.

Is it enough for the system to simply return a business rule statement as the error message and stop there? Can't it do more?

Of course. A friendly business rule system would immediately offer the user the means to correct the fault (again assuming the user is authorized and capable), and if successful, then move on with processing the order. In other words, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.

This smart approach to process models knits procedures together in a just-in-time manner based on rules, dynamically supporting highly variable patterns of work. It enables pinpoint responses to events - truly business events rather than system events.

As expressed by the BRG's Business Rule Manifesto in 2003, this architectural vision requires seeing that each business rule is fundamentally "a first-class citizen of the requirements world." The Manifesto also said 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 incursions in real time. By the way, the Manifesto is a great, short (2-page) read, so I encourage you to have a look on www.BusinessRulesGroup.org. (If English is not your first language it's in about a dozen other languages too.)

Is that as smart as processes can get? Not yet. One would hope that over time, the rules for assigning appropriate agents would become well enough understood that they could be captured and made available to the system. Then when a fault occurs, a decision service could be called upon by the system to assign an agent automatically. At that point, this whole bit of knowledge work can be tucked very neatly under the covers.

A business rules architecture is therefore unsurpassed for what is often called incremental design. What's being designed or captured, however, is real business know-how, not just better GUIs or dialogs. 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.

Smarter and Smarter Workers

What I have to say next might surprise you. So far we've been talking about business systems from an architectural point of view; now let's talk about them from a service point of view. As we think about today's business challenges, what role should business systems play?

First let's talk about some people-challenges facing your business.

Time shock. As the rate of change accelerates, workers are constantly thrust into new roles and responsibilities. They must be guided through unfamiliar procedures or business know-how as thoroughly and as efficiently as possible. The business pays a price, either directly or indirectly, if getting the workers up to speed is too slow (or too painful). Time shock is like culture shock - very disorienting if you're not prepared for rapid immersion.

Training. The flip side of time shock is training - how to get workers up to speed. Training is expensive and time-consuming. Yet as the rate of change accelerates, more and more (re)training is required. Where do you turn for solutions?

A foremost cause of time shock for business workers is rapid change in the rules. At any given time, workers might be found at virtually any stage of time shock. Sometimes, you might find them completely up-to-speed, other times completely lost. Most of the time, they are probably somewhere in between. That poses a big challenge with respect to training.

The only approach to training that will truly scale is on-the-job self-training. That requires smart processes, ones coordinated with rules so that pinpoint know-how can be put right in front of actors in real time as the need arises - that is, right at the points of knowledge.

Where do you find these points of knowledge? You find them at the fault lines, at the points in processes where business rules need to be evaluated in real time.

What guidance message should be returned to a user when a fault is detected? As earlier, the message should succinctly express a business rule. What that means, in effect, is that the relevant portion of the company's know-how is 'read' to the actor on-line, right as the actor bumps up against the rules.

So the big idea here is simply that business systems must become knowledge companions for the business actors of the knowledge economy. After all, isn't making people smarter the whole point of knowledge?!

Footnotes:
1. Portions of this material is extracted from Business Rule Concepts (3rd edition), chapter 10, 3rd quarter, 2009.