What You Need to Know About Business Rules


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.

What You need to Know about Business RulesIn 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.

A customer must not place more than three rush orders charged to its credit account.

A customer with preferred status should have its orders filled immediately.

A customer's annual order volume is always computed as total sales closed during the company's fiscal year.

A customer is always considered preferred if the customer has placed more than five orders over $1,000.

An order must be assigned to an expeditor if shipped but not invoiced within 72 hours.

'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?

  1. The business rule needs to be evaluated with respect to the event. We call that a flash point.

  2. If a violation is detected, appropriate intervention should ensue.

  3. 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.


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:

  • Coordinating some business process.

  • Applying specialized know-how in the context of some product/service.

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. 

Ronald G. RossAuthor: 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

Like this article:
  4 members liked this article


Tony Markos posted on Wednesday, December 2, 2009 5:36 PM

Very good article. Can you expand upon "a vocabulary scaffolding is indispensible for scaling up"?

I create data dictionaries to supplement data flow diagrams. In the dictionary the definition for a high-level term might be decomposed down into definitions for sub terms. Is this what you mean?

Tony Markos
Anonymous User posted on Wednesday, December 2, 2009 6:09 PM
How do you explicitly identify between Guideline and Inference based Business Rules? Looking at the example given above, i can restate it the following way:

A customer with more than five orders of value exceeding a $1,000 each, is assigned a preferred status

A customer's order are always filled-up immediately if the status is preferred.
Abhirup posted on Wednesday, December 2, 2009 6:17 PM
the thing is both refer to the rule: 'Condition X=True' execute 'process/task=Y'
Ron Ross posted on Tuesday, December 8, 2009 3:24 PM
Tony, You wrote: Can you expand upon "a vocabulary scaffolding is indispensible for scaling up"? I create data dictionaries to supplement data flow diagrams. In the dictionary the definition for a high-level term might be decomposed down into definitions for sub terms. Is this what you mean?"

>>No, there's more to it than than. Business rules are expressed by sentences (... as many requirements should be. And as most business communications should be). To write sentences, you need verbs. What is missing from most data dictionaries and other IT artifacts are the standard words (verbs and verb phrases) for the verb concepts.

Your company probably has many thousands of rules. How can you bring coherence to such complexity without a blueprint of both noun concepts and verb concepts for communicating about day-to-day business operations? It's "only" a matter of (business) semantics ... And it will always remain "just" a matter of semantics.

Thebest answer to date is fact modeling, the verbish counterpart to data models and BOMs. We didn't invent it. This school of thought has been around since the 1970s, and was standardized within SBVR in late 2007.

That's the short answer. For more, read Part II of Business Rule Concepts, 3rd. Edition.


Ronald G. Ross
Executive Editor, Business Rules Journal, BRCommunity.com
Co-Founder & Principal, Business Rule Solutions, LLC (BRSolutions.com)

Ron Ross posted on Tuesday, December 8, 2009 3:37 PM
Anonymous: You wrote:
How do you explicitly identify between Guideline and Inference based Business Rules?

>> A guideline is a rule about what people might do or not. In SBVR, such business rules are called behavioral rules (even if automatable). A guideline is a behavioral rule that is lightly enforced (if at all). Enforcement level should be specified separately from a behavioral rule since it could change independently of the rule itself.

When you say "inference", in SBVR you are talking about business rules that by definition (not as a matter of human choice) must be true. Such rules are called definitional rules, and really address the issue of knowledge (how do you know when a thing is a thing?). The definition of concepts is simply a different problem than the coordination of human behavior.

I may or moy not have answered your question. For additional discussion, see Chapter 7 of Business Rule Concepts, 3rd Edition.


Ronald G. Ross
Executive Editor, Business Rules Journal, BRCommunity.com
Co-Founder & Principal, Business Rule Solutions, LLC (BRSolutions.com)
Ron Ross posted on Tuesday, December 8, 2009 3:43 PM
duttasaab: You wrote [probably in reference to the distinction between guideline and inference]: "the thing is both refer to the rule: 'Condition X=True' execute 'process/task=Y' ".

>>One of the SBVR principals wrote (I paraphrase): "Business people don't set functions and don't call functions". Business analysts should really think about how business people think about rules naturally, rather how the rules are categorized by some implementation language or software paltform. Just to be clear, I only ever talk about the former (*business* rules), not the latter.


Ronald G. Ross
Executive Editor, Business Rules Journal, BRCommunity.com
Co-Founder & Principal, Business Rule Solutions, LLC (BRSolutions.com)
Abhirup posted on Tuesday, December 8, 2009 5:02 PM
Thanks for the response.

Actually i was trying to bring out the similarity between a guideline and an inference based rule as evident from the example given by you in the article. It was never meant to be a function as such:)

The thing is when i look at the exAmples, the way the rule has been written under both the category, it seems to me that both the rules refer to some sort of condition which if is fulfilled, is asking for a defined (not desired) action to be taken henceforth.

A customer with preferred status should have its orders filled immediately.


A customer is always considered preferred if the customer has placed more than five orders over $1,000.


I really do not see how these two are different? As you can see how i restated both these rules interchanging their categories (see Anonymous post at the very beginning).
Abhirup posted on Tuesday, December 8, 2009 5:09 PM
ok. So based on the example under Guideline, are you saying there is an option to either fill-up or not fill-up the order immediately (text indicator 'should'), even if status is preferred?So some times u can fill-up and at other times not? If yes, how can this rule be automable? As automation defines a binary behavior-u either fill-up or u don't.
Ron Ross posted on Tuesday, December 8, 2009 7:54 PM
The rule is the rule is the rule. Either an order 'is filled' (a state, not a process per se) immediately ("immediately" needs some definitional rule(s)) -- or not. If not, a violation occurs.

How the business analyst decides to respond to any violation should be considered a business question. If a guideline, maybe a flashing message on a GUI. If strictly enforced, maybe the matter is escalated to a supervisor. But that's a different question from what the business rule is. The rule is the simply rule.


Ronald G. Ross
Executive Editor, Business Rules Journal, BRCommunity.com
Co-Founder & Principal, Business Rule Solutions, LLC (BRSolutions.com)
HyperonRules posted on Monday, August 3, 2020 4:42 AM
I'm under the impression that the business analysts should create the business rules independently from software limitations. I can see the benefits of such an approach. The requirements are more precise and unbiased. However, sometimes a business rules engine, for instance, Hyperon - https://www.hyperon.io/lp/business-rules-engine, forces a strict way of formatting a business rule (decision table). How should I tackle this challenge?
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC