Business rules should be externalized from processes and established as a separate resource. Rule Independence permits direct management of the business rules, so they can evolve at their own natural pace rather than that of the software release cycle. Other benefits include better process models, and much closer tie-in to the business side (a.k.a. business alignment). Business rules put your company on the road to true agility.
Excerpted from Chapter 2, Business Rule Concepts: Getting to the Point of Knowledge (3rd Ed.), by Ronald G. Ross, August 2009. ISBN 0-941049-07-8 - Reprinted with permission.
In the human body, control is provided by the nervous system, an organized collection of nerves that connect to the muscles. Business operations must have similar coordination of behavior. This coordination or guidance is supported by business rules.
In the human body, power is provided by the muscles; in business operations, it is supported by processes. Nerves and muscles are separate; business rules and processes should be separate too.
This principle of separation is called Rule Independence. Not embedding business rules in processes has huge benefits.
Working Smart
Rules are familiar to us all in real life. We play games by rules, we live under a legal system based on rules, we set rules for our children, and so on.
Yet the idea of rules in business systems is ironically foreign to many people. Say "rules" and many IT professionals, for example, think vaguely of expert systems or artificial intelligence - approaches deemed appropriate for only very specialized or very advanced kinds of problems. Recognition has come only slowly about how central business rules actually are to basic, day-to-day business operations.
Not coincidentally, many business-side workers and managers have become so well indoctrinated in procedural views for developing requirements that thinking in terms of business rules might initially seem foreign and perhaps abstract. Virtually every methodology has been deficient in this regard, whether for business process reengineering, system development, or software design.
That omission is highly detrimental and very costly. Thinking about the control aspect of any organized activity in terms of rules is actually very natural. For example, imagine trying to explain almost any game you can think of - chess, checkers, baseball, football, tennis, and so on - without explaining the rules on which the moves in the game are based. Even if it were possible (that's doubtful!), explaining things that way would certainly not be very effective.
In short, you need business rules. Without any exaggeration, good business rules are no less important to business operations than a robust, finely-tuned nervous system is to the human body.
You naturally want each business rule to be specified once and only once. One-place specification (single-sourcing) means the business rule will be easier to find - and to change quickly. If you want true agility, business rules are the ticket.
Collectively, the set of business rules represents a separate rulebook for the business game. This rulebook should, of course, be automated, to provide scalable support for the origination and management of the business rules. You need special tooling for the rulebook, which I call a general rulebook system (GRBS).
Do business rules complicate matters for the business? No! Doing business is no more complicated by having independent business rules than are the games of chess, baseball, and football by having their own independent rulebooks.
Are business rules all that matter? Of course not! You still need artifacts for other needs, including process models, use cases, etc. These latter deliverables are needed to produce the raw power to do work - muscles for the business to flex. Business rules represent a well-developed nervous system, a way to ensure your business works smart.
The Basics of Business Rules
A first step in understanding business rules is simply to relate them to the issue of guidance. The sidebar below presents a light sampling of typical business rules, each categorized informally according to the kind of guidance it provides. Note how far-ranging these categories really are. Every aspect of guidance for business operations can be addressed by business rules.
Restriction
A customer must not place more than three rush orders charged to its credit account.
Guideline
A customer with preferred status should have its orders filled immediately.
Computation
A customer's annual order volume is always computed as total sales closed during the company's fiscal year.
Inference
A customer is always considered preferred if the customer has placed more than five orders over $1,000.
Timing
An order must be assigned to an expeditor if shipped but not invoiced within 72 hours.
Trigger
'Send-advance-notice' must be performed for an order when the order is shipped.
A second step in understanding business rules is to understand how they relate to a structured business vocabulary (often portrayed as a graphical fact model). Rules build directly on fact types. Basically, expression of a business rule simply adds a sense of obligation or necessity to terms and wordings already set up in the fact model.
Terms, Facts and Rules
The focus of business rules has often been described as terms, facts, and rules. Under the rigorous formal prescriptions of the new standard Semantic of Business Vocabularies and Business Rules (SBVR) this mantra, which dates to the early 1990s work of the Business Rules Group (www.BusinessRulesGroup.org), is not 100% technically accurate. Nonetheless it's memorable and certainly adequate for an initial understanding.
Here is a sample business rule: A customer must be assigned to an agent if the customer has placed an order. Figure 1 shows the relevant terms and wordings for this statement. Note how the fact types worded customer places order and customer is assigned to agent are used directly in the statement, with only minor adjustments in tense as appropriate for English grammar.
Figure 1. Terms and Wordings for the Agent-Assignment Business Rule.
In business problems involving hundreds or thousands of business rules - not at all uncommon - there is no way to achieve consistency across such large numbers of statements without a common base of terms and wordings. This vocabulary scaffolding is indispensable for scaling up.
Basing verbalizations directly on wordings for fact types is a key feature of business-oriented notations for business rules such as RuleSpeak (www.RuleSpeak.com, in English, Spanish, German and Dutch).
A third step in understanding business rules is appreciating the importance and power of expressing business rules declaratively. When statements are based directly on wordings for fact types, the result is always declarative. The Agent-Assignment Business Rule presented above illustrates. Expressing business rules declaratively is a key means of liberating the business from the perils of IT-speak. The sidebar below explains how you can determine whether specifications are declarative.
When Are Specifications Declarative?
In graduate school in the early 1970s, I learned this highly pragmatic test for determining whether specifications are declarative:
-
Take each statement of the specification and type it on an individual punch card. (It's really hard to find punch cards these days, but for the sake of discussion, let's ignore that.)
-
Assemble the deck.
-
Test it to make sure it works.
-
Throw the whole deck up in the air.
-
Pick up all the cards in random order.
-
Re-test it.
If the logic still works, the statements are declarative. If not, they are procedural. The point is that in declarative specifications no logic is lost 'between the lines' - i.e., none is intrinsic to the sequence of presentation. In other words, there is no hidden semantics (meaning).
Violation of Business Rules
Let's examine more closely business rules that can be violated. Consider the Agent-Assignment Business Rule. What happens when an event occurs that might violate this business rule?
-
The business rule needs to be evaluated with respect to the event. We call that a flash point.
-
If a violation is detected, appropriate intervention should ensue.
-
Assuming the user is authorized and knowledgeable, some explanation should be provided about what triggered the intervention. You might call that explanation an error message, but we prefer guidance message. The intent should be to inform and to shape appropriate business behavior, rather than simply reprimand or inhibit it.
What should that guidance message say? The guidance message should contain exactly the same text as given for the business rule. For the Agent-Assignment Business Rule it should literally read: A customer must be assigned to an agent if the customer has placed an order. To put this more strongly, the business rule statement is the guidance message.
Now I overstated the case a bit to make the point. Obviously, additional or customized text can be provided to explain the relevance of the business rule to the specific event, to suggest corrective measures, to give examples, and so on. Also, in a truly-friendly business rule system, you often wouldn't want simply to present the message, then shut down the work. For example, you might offer a procedure or script to the user to assist in taking immediate corrective action. But for now, let's stick to the main point.
And that main point is this: The guidance messages that business workers see once an operational business system is deployed should be the very same business rules that knowledgeable workers on the business side expressed as requirements during development. Guidance messages, business rule statements, rule-related requirements - these are all literally one and the same. Well-expressed business rules during the requirements process mean well-expressed guidance messages; poorly-expressed business rules during the requirements process mean poorly-expressed guidance messages.
This approach has proven potential for closing the requirements gap between business people and IT that still plagues many companies today. In traditional approaches, much is usually lost in the translation of up-front requirements into the actual running systems. Using business rules, the business side gets back whatever guidance it puts in - a truly business-oriented approach.
Direct assistance in expressing the business rules up-front will prove very valuable to the managers and workers involved in business rule capture. It will enable them to be far more articulate about their requirements. We see the ability to assist in expressing business rules as a key skill for business analysts.
Decisioning
Business rules are not an end in themselves; ultimately, they are about enabling the business to make good, consistent operational decisions. Think of business rules simply as criteria for making operational decisions.
An operational decision is where some minute-to-minute, day-to-day determination must be made in performing business activity. Such a decision typically might have to do with configuration, allocation, assignment, classification, assessment, compliance, diagnosis, and so on.
Generally, operational decisions are concerned with either of the following:
Examples of operational decisions that fall into the latter category might include whether or not to:
-
Approve an application for automobile insurance.
-
Pay a claim.
-
Buy a stock.
-
Declare an emergency.
-
Accept a reservation.
-
Indicate possible fraud.
-
Give an on-the-spot discount to a customer.
-
Assign a particular resource to a given request.
-
Select a health care service for a patient.
-
Certify a ship for safety.
You can expect business rules to generally align according to the kind of operational decision they support - coordinating some business process or applying some specialized know-how.
Business rules concerning the company's product/service invariably involve the company's special area(s) of expertise. They often use more arcane (knowledge-rich) vocabulary. For that reason, such business rules are typically more difficult to capture and express. And there tends to be significantly more of them. Decision tables are particularly helpful for them. Your approach needs to be prepared for all that.
How far can you take operational decisioning in a company? I don't know the ultimate answer. At the present time, no one does.
But let me try to answer the question a different way. Suppose you take any given operational decision in the business. Is it always possible to capture and encode all relevant business rules such that the decision could be made precisely or optimally with no human intervention? No. Some problems are just too difficult - e.g., accurate weather forecasting.
In the typical business, however, a large number of crucial everyday decisions come nowhere near that degree of complexity. For all those decisions, you can capture and encode all the business rules and make precise or optimal decisions. That's a proven fact.
Author: Ronald G. Ross is recognized as the “father of business rules.” He serves as Executive Editor of www.BRCommunity.com and its flagship publication, Business Rules Journal, and as Co-Chair of the Business Rule Forum Conference. Mr. Ross is the author of eight professional books, including the Business Rule Concepts (2009) and Principles of the Business Rule Approach, Addison-Wesley (2003).
At his company Business Rule Solutions, Mr. Ross engages in seminars, consulting services, publications, the Proteus® methodology, and RuleSpeak®. He gives popular public seminars through Attaining Edge and IRM UK.
Copyright 2009. Business Rule Solutions, LLC. All rights reserved. 4
Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (3rd Ed.),
by Ronald G. Ross, 2009. ISBN 0-941049-07-8 - http://www.brsolutions.com/publications.php