Software vendors and others mislead people (badly) about the true meaning of business rule. Let’s set the record straight. The OMG standard SBVR (Semantics of Business Vocabulary and Business Rules, 1.4) defines business rule as a rule that is practicable and is under business jurisdiction. The definition has these three parts: (1) rule, (2) practicable, and (3) under business jurisdiction. Let’s look at each part in turn. 1. Rule Rule in business rule means real-world rule – in other words exactly what the dictionary says rule means. Here are the relevant meanings of rule from Merriam-Webster Unabridged Dictionary [MWUD].

guide for conduct or action [MWUD ‘rule’ 1a]

one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* [MWUD ‘rule’ 1f]

A real-world rule always tends to remove a degree of freedom.  If it does not, it’s not a rule. Also, a real-world rule is declarative. It never does anything. It merely shapes behavior or decisions. If you’re using an approach where rules can actually do things (e.g., execute an action, set a flag or variable, call a function, etc.), they’re not business rules. You’re in TechnologyLand, and a procedural one at that. 2. Under Business Jurisdiction    Business rule includes only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization. The important point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains:

“… legislation and regulations may be imposed on [the company]; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Practicable Practicable means a rule is sufficiently detailed and precise that a person who knows about it can apply it effectively and consistently in relevant circumstances. In other words, the person will know what behavior is acceptable or not, or how some concept is to be understood. A practicable business rule is one ready to become a deployed business rule – i.e., applied in day-to-day business activity. Whether the guidance is to be deployed to staff or ultimately to machines is immaterial. You should get the same results either way. Business policies are generally not practicable in this sense. Business rules always are. ~~~~~~~~~~~~~~~~~~~~ Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015 Get the book:http://www.brsolutions.com/b_building_business_solutions.php Get the training: Instructor-led, online, interactive training: October 4-6, 2016 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php ©Business Rule Solutions, LLC 2016. wwwBRSolutions.com 

Make no mistake, the future lies with automation of white-collar work. Fewer and fewer business problems these days focus on manufacturing and production processes, i.e., the nothing-but-widgets category. For all the non-widget-centric business activity in the world – which includes just about all every conceivable form of white-collar work – the following needs become paramount.

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

What would I do to correct the shortcomings of BPM for non-widget-centric business activity? Our answer is to become more why-centric, as opposed to narrowly how-centric.[1] You should focus on business capabilities, not just business processes. That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM). Business goals and business risks should be drivers of business process design – not the other way around. You need to be strategy-driven, not simply process-driven.
• Designing core metrics around business goals and business risks – the things that concern C-suite executives the most.
• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.
• Treating business rules as a first-class citizen, externalized from process models.[2]
• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.
• Including a Why Button as part of every business solution. Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

~~~~~~~ Read more about the future for processes: BPM and the Knowledge Economy: Nothing But Widgets? http://www.brsolutions.com/2015/11/16/bpm-and-the-knowledge-economy-nothing-but-widgets/ What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

I wouldn’t go so far as to say that process and BPM are meaningless across the board in the digital economy. If you’re manufacturing or producing a physical product, you still do need to think in terms of a modeled and managed business process. Other the other hand, if your products are non-physical – for example, money, time, skills, information, meta-data, etc. – you’d better have a major re-think. The old rules of the game simply don’t apply to white-collar work. Nor do they apply if your business model is about digitally leveraging other people’s idle assets – think Uber. You must still consistently satisfy contractual obligations and regulatory constraints in this new digital world of course. But that’s a business rules problem, not a process problem. A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:

• Continuously make informed operational decisions in the blink of an eye (actually often faster than that).
• Selectively respond to changing circumstances with subtle adjustments.
• Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.

These too are business rule problems, not process problems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

The following statement came up recently in discussing business rules at Global Holdings. (Not the real name of the company.) The statement has significant problems. Sometimes simple is too simple.

Global Holdings must review the corporate account of ABC Company.

Problem 1. In general, it is not a best practice to mention “us” in specifying business rules. Do that once, then every other business rule statement should mention “us” too. That’s clearly not practical or useful, and in most cases, not even intuitive. So the current specification should be revised simply to:

The corporate account of ABC Company must be reviewed.

Problem 2. The ‘rule’ doesn’t pass basic tests of practicality or usefulness. What point would it serve to have a business rule saying that something must be reviewed without indicating one or more of the following?

• some method (how?)
• some location (where?)
• some role (by whom?)
• some timing (how often?)
• some potential goal or constraint (is there potential fraud?)

In other words, the statement mandates a review based on criteria not encoded. Those absent review criteria probably represent the true business rules. To say it differently, a ‘rule’ that simply kicks out work for a human to do is probably not a business rule at all! Problem 3. As it stands, the practical effect of the statement would be to require ABC account to be reviewed as soon as it comes into being (and indicate a violation if it is not). Very few things must be reviewed for unspecified criteria at the very time they are created. Real business just doesn’t work that way. Bottom Line: Unless additional specification is provided, this simpleton ‘rule’ should be discarded. It’s basically just toothless. http://www.brsolutions.com/

It’s become more and more apparent that software vendors are misleading people (badly) about the true meaning of ‘business rule’. Time to set the record straight. Here is an authoritative 3-part explanation. Take a moment and reacquaint yourself. As a business-oriented professional you’ll be glad you did!

Reference Sources
[MWUD]	Merriam-Webster Unabridged Dictionary (Version 2.5).  [2000].  Merriam-Webster Inc.
[SBVR]	Semantics of Business Vocabulary and Business Rules (SBVR) (Version 1.0).  [January 2008].  Object Management Group.

  1. Rule When we say rule we always mean real-world rule. Here’s the dictionary meaning of “rule”. That’s what we mean.

[MWUD ‘rule’ 1a]:  guide for conduct or action; [MWUD ‘rule’ 1f]:  one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* ; [MWUD ‘criteria’  2]:  a standard on which a decision or judgment may be based

A real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule.  2. Under Business Jurisdiction    When we say business rule we mean only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization.  The point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains: 

“The laws of physics may be relevant to a company … ; legislation and regulations may be imposed on it; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Business Rule

[SBVR]:  a rule that is under business jurisdiction

A business rule is a criterion used to:

• guide day-to-day business activity
• shape operational business judgments, or
• make operational business decisions. 

A number of years ago, a colleague of ours, Mark Myers, came up with a highly pragmatic test to determine whether some statement represents a business rule or a system rule.  It almost always works.  Imagine you threw out all the systems running your business and did it all by hand (somehow).  If you still need the statement, it’s a business rule.  If you don’t, it’s not.  A colleague on the SBVR standardization team, Don Baisley, puts it another way:  “Business people don’t set variables and they don’t call functions.” Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  Each should give well-formed, practicable guidance Here are a few simple examples expressed in RuleSpeak:  

A customer that has ordered a product must have an assigned agent. 

The sales tax for a purchase must be 6.25% if the purchase is made in Texas. 

A customer may be considered preferred only if the customer has placed more than $10,000 worth of orders during the most recent calendar year.

Business rules represent a form of business communication and must make sense (communicate) to business people.  If some statement doesn’t communicate, it’s not a business rule. 

Consider this example:  If ACT-BL LT 0 then set OD-Flag to ‘yes’.  Not a business rule. 

Consider another example:  An account must be considered overdrawn if the account balance is less than $0.  This statement communicates and therefore is a business rule. 

More observations about business rules:

• In SBVR a business rule can be either a behavioral rule or a definitional rule.
• Business rules can be technical, but only in terms of the company’s know-how or specialized product/service, not in terms of IT designs or platforms.
• Expression of business rules should always be declarative, rather than procedural.
• A business rule statement should use terms and wordings about operational business things that should be based on a structured business vocabulary (concept model).
• Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.

Business rules are not about mimicking intelligent behavior, they are about running a business.  Mimicking intelligent behavior in a generalized way is far harder (an order of magnitude or more) than capturing the business rules of an organization.  Unfortunately, expert systems have generally focused on the former problem, causing considerable confusion among business practitioners.  ~~~~~~~~~~~~~~~~~~~~  Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs

Rhetorical question? Well maybe, but I’ll answer it anyway. A data model is a tool to organize what a company knows about the world so it can remember it in a systematic way. So yes, that’s like DNA. (I think ‘concept model’ is more accurate than ‘data model’, but let’s leave that discussion for another day.) But DNA does more. It encodes the rules to guide the processes to sustain and reproduce life. For a business, those would be its business rules. That’s the part many people miss. By the way, DNA encodes the building-block concepts and rules in a declarative, not procedural, way … just as data models and business rules should be represented.

If you’ve never been to India or Latin America, take a look at the following short video. Is what you’re seeing the absence of rules … or something else? http://www.evolvingexcellence.com/blog/2011/11/control-or-chaos.html In my travels in Latin America, I long ago perceived that there are two fundamental kinds of driving and traffic: 1. Obedient. In this style, drivers usually follow the official rules, or some approximation thereof. Accidents occur when road conditions are bad, drivers aren’t paying attention, or somebody thinks the rules don’t apply to them (chooses to violate the rules). 2. Positional. In this style, nobody pays much attention to the official rules. Instead, a driver is generally allowed to proceed in the direction he/she wants if the driver’s vehicle has better physical position (or is significantly larger in size) in relation to other nearby vehicles. Accidents occur when road conditions are bad, or drivers aren’t paying attention. Why aren’t there continuous accidents in the positional style of driving? It’s not because there are no rules. There are – the rules of ‘position’. You’re not really looking at anarchy or chaos – i.e., the absence of rules. If you were, everyone you see would be running into everyone else all the time. A good analogy is a flock of birds or school of fish. How do they all suddenly seem to turn in the same direction? The rules of position. Each bird or fish must always maintain its distance from his neighbors. Is the positional style of driving/traffic safer than the obedient style? Theoretically, I suppose you could argue it is. All drivers know the rules of position apply to them and that the sanction for violating those rules can be immediate and injurious. In practice, I wouldn’t bet on it. Flocking birds and schooling fish are probably equipped genetically for positional maneuvering. They’re been at it for millions of years. Humans have been driving for what – maybe a 100?! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Acks to Roger Tregear, Leonardo Consulting, Australiawho sent me a link to the video post.

This is an excerpt from our new book: Building Business Solutions: Business Analysis with Business Rules coming out in October. Watch for it! “Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Basic reasons why requirements are not rules:  Business people don’t naturally think of a ‘requirement’ as a ‘rule’. To ensure the best possible communication with business people, use of ‘rule’ should remain consistent with the real-world understanding of ‘rule’. Say ‘rule’ to business people and they will naturally think “guide for conduct or action” or “criteria for making judgments or business decisions.” If a business person says ‘rule’ he/she almost certainly means a rule for the business (e.g., no shirt, no service), not ‘requirement for a software system’. Many ‘requirements’ never become rules. The “no shirt, no service” rule doesn’t happen to be automatable (at least easily). Many other rules of the business are – e.g., no credit card, no sale. When interpreted into an implementation form, the business rules ideally should still be recognizable as a form of rule. The same cannot be said, however, for other aspects of a business model, say processes. In designing a business process for implementation, why would you ever say, “Now it represents rules.”?! Rules are rules, processes are processes, locations are locations, people are people. Each can be cast into some design-level counterpart (e.g., GUIs can substitute for face-to-face communication between people.) Nonetheless, each retains some sense or reflection of what it was originally (or should anyway). Looking at operational business design any other way inevitably leads to a break-down in communication and needless complexity.  Avoid confusing business people or IT professionals – or yourself – by calling requirements ‘rules’. Requirements are not rules! But Are Business Rules ‘Requirements’?? Clearly, requirements are not rules. What about the reverse question? Can it be helpful to think of business rules as requirements? To answer it’s essential to keep in mind what business rules are about. In plain English, business rules are about guiding and shaping day-to-day operations of the business. Business people would need business rules to operate the business even if there were no systems. The business rules just are what they are. And if well-specified, they essentially speak for themselves. All the following, though, are certainly true about business rules:

• They should arise from, or at least be approved by, business people.  
• They should be considered very carefully in designing a system.  
• They should be automated whenever possible.

All said and done, whether business rules are a form of requirement is really a judgment call. The best answer is whichever is likely to prove most productive for your work.

One of the interesting things about consulting with different organizations on business rules and publishing a Journal on that subject (the Business Rules Journal on BRCommunity.com) is that a lot of really silly rules cross my desk. Sometimes it feels like a Dilbert parade! We’ve even started a LinkedIn group about them – Rules Say Must Not.  A colleague recently forwarded a rule that raises some interesting questions. He observes that in his apartment building the doors to the stairwells all have signs on them saying, Door must be kept closed at all times. His question was, “Is a door you must never open really a door?” If the rule is followed religiously, he observed, the door might as well be considered part of the wall. Well obviously not quite! Before addressing that tongue-in-cheek question, let’s do some analysis of this rule. I think we can safely assume that the rule as stated is actually a shorthand. A more complete and accurate version might be, You may use this door for entry, but it must be closed behind you. If we wanted to be very complete, we might explain the basic motivation for the rule by adding, Fire Door. Further analysis of this simple rule reveals the basic ideas of business rules: 

• The rule was posted; that is, written down. Why? The answer lies in the motivation for the rule – its purpose is to protect the inhabitants against the dangers of fire. When a rule becomes important enough, it is always written down.
• The rule was written in plain English. If the rule were difficult to understand, or encoded in such way that many of the inhabitants could not readily interpret it, it would not serve its purpose very well. A rule important enough to write down is worth writing down plainly.
• A process or procedure for this situation is not really needed. We could write one, of course, but in this case, it would probably be trivial (approach door; grasp doorknob with hand; twist doorknob is clockwise direction; pull/push carefully …). Nonetheless, the rule is still crucial. Rules can exist independent of processes.
• This rule – like all rules – serves to shape behavior. The posting of the rule reminds inhabitants, staff and others to close the door, and presumably they are therefore less likely to forget, or perhaps even block the door open. The purpose of a rule is always to guide or influence behavior in desired ways.
• The rule serves a purpose – it is neither frivolous nor arbitrary. Fire is a deadly risk, and all reasonable measures must be taken to protect against it. Business rules never arise in a vacuum; there are always by identifiable and important business factors motivating them.
• The rule was posted right where the action is – that is, where actual entry can occur. This proximity to the action helps ensure the rule is followed as events actually unfold. The best way to ensure rules are followed is to get them right in front of people at the exact point where the guidance is relevant.
• The rule is undoubtedly part of a larger body of fire code rules for buildings. Even though the rule may be posted thousands of times for enforcement purposes, these postings arise from a single source. This ensures consistency. If rules are important enough to be enforced, they are important enough to be single-sourced.  
• The body of fire-code regulations was undoubtedly produced by experts experienced in the field, and is backed by the political authority of the city or state. Changes must be reviewed, incorporated, and disseminated carefully. Because new dangers and liabilities can be discovered at any time, this process should be streamlined and efficient. In other words, the rules must be managed.

These commonsense observations represent the basic ideas of business rules. Your business has many hundreds or thousands of such rules guiding its operational business activity. Yet in practice, these basic business rule principles are seldom followed. Can you do anything about it? Yes! The business rules approach offers proven solutions. Now back to that question, “Is a door you must never open really a door?” The answer is obvious – yes, of course it is. A wall without a door will always just be a wall. If you need a door sometime in the future, you must remodel, and that means time and money (not to mention disruption for the inhabitants). If you have ever remodeled your home, you know exactly what I mean. The wall with a door acts like a wall until such time that the must-remain-closed rule is discontinued. Then, with relatively little delay, expense or disruption, it becomes a functional door. Think of business rules as a relatively inexpensive way to build potential doors for your business in all those many cases they might one day be needed. That way you can avoid walling yourself in. In a world of constant and accelerating change, business agility is the name of the game!

Gladys has started a new LinkedIn Group ‘Rules Say Must Not’. She’s looking for silly or dumb rules. I’m sure you know some — we run into them all the time! Share for the fun of it. (Prizes  offered for the best — uhm, worst — including an iPod!)   See  http://goo.gl/0tLD3  … Here’s my own first post. ~~~~~~~~~~~ A recent graduate from a top-ranked university registered for the MCAT, the gateway test to medical school. Let’s call him Jeffrey Hamilton (not his real name). Someday Jeffrey, known to all as Jeff, will make a great doctor. But Jeff made the mistake of actually calling himself ‘Jeff’ in registering and paying for the MCAT. Go figure.  Jeff knew the MCAT rules called for two forms of id. (Rule 1: A person’s name must be verified by two government-issued identity cards.) Not a problem. He had a passport and a driver’s license, both with photos and signatures. (Not great photos, but you know how id photos go.) He had not signed either one with his full name – just ‘Jeff Hamilton’.  As the date of the test approached, Jeff was talking to friends who had already taken the test. Just to make sure, it occurred to him to check whether his having registered as ‘Jeff’ instead of ‘Jeffrey’ might cause any problems.  As it turned out, big problems. The full names had to match. (Rule 2: A person’s full name must be given in an MCAT registration.) Only “Jeffrey” (the id’ed person) could take the test. ‘Jeff’ (the registered person) could not. O.K., he had messed up. So ‘Jeffrey Hamilton’ (the real person), being a poor recent college graduate, naturally asked for a refund of his registration fee (considerable for college kids). Not allowed – the rules said must not.  You would think that ‘Jeffrey Hamilton’ (the real person) had to be either ‘Jeff’ (the registered person) or ‘Jeffrey’ (the id’ed person). Since ‘Jeffrey Hamilton’ (the real person) could not take the test, he must not have been ‘Jeffrey’ (the id’ed person). So he must have been ‘Jeff’ (the registered person). But ‘Jeff’ (the registered person), couldn’t take the test, nor could he get a refund, even a partial one. (Rule 3 (presumably): A refund may be issued only if the name of registered person matches the full name on two government-issued id’s.) Bottom line: Poor Jeff was not himself. He was lost in identity limbo.