WHAT IS A 'BUSINESS RULE'?

By Ronald G. Ross, March 2000

In a way, everybody knows what "business rules" are -- they are literally what you use to run your business. In that general sense, of course, everybody is right. Business rules are what guide your business in running its day-to-day operations. Without business rules, you would always have to make decisions on the fly -- choosing between alternatives on a case-by-case, ad hoc basis. Doing things that way would be very slow. It would likely produce wildly inconsistent results. I doubt it would earn very much trust from your customers.

In today's world, you could not really operate that way -- at least not for very long anyway. So every organized business process has business rules. But what are they? What exactly do you use to "guide your business in running its day-to-day operations"?

In a minute, I would like to revisit several definitions of "business rule." Before doing that, however, we should be clear about what business rules are not.

First, business rules are not software. Let me be a little more precise. Business rules are often implemented in software, but that is a different matter. In fact, application software is only one of several choices in that regard. Alternative implementations include supporting them in manual procedures (not very efficient, but sometimes necessary), or implementing them as rules in a rule engine or expert system (a better choice, but not that many companies have them today). The point is that business rules arise as an element of the business -- as the name "business rules" suggests -- not from any particular hardware/software platform that supports them.

Second, business rules are not "process" in any sense of the word. Roger Burlton recently expressed the business rule message this way: "Separate the flow from the know." Business rules represent the "know" part of that -- the stuff that guides the "flow." Guidance means following rules, of course -- hence the name "business rules."

There are several more points about Roger's dictum, but let me get to those in just a moment. First let's review the several definitions of "business rule" I have listed in the table below. (If you are interested in a historical view, the entries appear in chronological order, more or less reflecting an evolution in precision and understanding.)

Several observations are worth making about these definitions.

• First, whereas the definitions are consistent in theme, if you look closely, you will see tension between a purely business perspective (see the Business Rule Group definition from 1998) versus a system perspective (see the BRS definition from 2000). The bottom line is that both perspectives are correct -- just different in their viewpoints.

• Second, a general consensus emerged among experts in the 1990s that there are three basic categories of business rules -- terms, facts, and rules. (This important breakthrough is credited to the GUIDE Business Rule Project, and was originally reported in its 1995 paper.) Literally, in the business rule approach, the ‘know' part always comes in the form of a term (definition), a fact (type), or a rule. A business rule is never anything else. By the way, terms are the most basic of the three basic categories because facts must build on terms, and rules must build on facts. That works out to be a very nice building-block approach for the ‘know' part.

• Third, note the term "business structure" in the 1997 GUIDE Business Rules Project definition. This term refers to basic structure for the ‘know' part -- literally, how terms relate to one another in the form of facts. A ‘data model' is one way to express such structure. A BRS Fact Model is another.

• Fourth, note that the 1997 GUIDE Business Rules Project definition includes both the word "control" and the word "influence" in reference to business behavior. If you think of "rules" only as hard and fast "constraints" (asserting strict control), you miss at least half the scope of business rules. Guidelines, heuristics, inferences, etc. are also business rules!

• Fifth, note the word "atomic" that appears explicitly or implicitly in several of the definitions. This reflects an important goal for business rules -- to achieve the most granular level of specification possible. Why is that so important? Because it allows for fine-grained change in business practices.

• Sixth, note the terms "re-usable" and "declarative" in the BRS 2000 definition. "Declarative" specifications are what you get when you express business logic in the form of "terms, facts and rules." This has crucial advantages, not the least of which is that your business logic becomes "re-usable" across both processes (the ‘flow') and hardware/software platforms. As such, it becomes both highly re-engineerable and highly re-deployable. I think of this as ‘business-rules-in-a-suitcase' -- just the thing for a business always on the go.

Before closing, let me return to Roger Burlton's dictum about separating the ‘flow' from the ‘know.' There are two other important points to make about that.

First, business rules really mean establishing the ‘know' part of your business processes as a resource in its own right. Along with that comes both advantage and responsibility. The advantage lies in being able to change elements of the ‘know' directly, which in turn means being able to change them faster. (What business does not want to be able to change faster these days?!) But there is a price for that -- this new resource must be managed. Therein lies the responsibility -- you must now come to grips with management of that ‘know' part.

The second point is this. In real life, some of the ‘know' part has always been separated from the ‘flow' in the sense that workers carry it around in their heads. Does such "tacit" knowledge represent "business rules"? I would say no. You really have business rules only when tacit knowledge is made explicit. (If you need any proof of that, just think what happens when the workers retire -- or go to work for the competition!)

Business rules therefore are that portion of the ‘know' part that is written down -- i.e., encoded -- for ready re-use (or revision) as needed. Here then follows an additional way to define business rules -- a very crucial one. "Business rules" are literally the encoded knowledge of your business operations. By the way, in case there is any doubt, yes -- I am talking here about the very same kind of "knowledge" as in knowledge management!

© 2000, Ronald G. Ross.