I get this question all the time, and it’s a painful one, so let me answer on the record. Question: In our enterprise architecture tooling, there’s a business dimension in which we define Business Concepts (the real business language), and an IT dimension containing Information Objects (data organization model). How can we solve the problem that business expresses rules as they relate to Business Concepts, while IT needs to translate these into rules related to Information Objects? We don’t want to bother business with IT model concerns, nor duplicate the rules in two places. Can you please shed light on an elegant approach to this dilemma? My answer: The standard SBVR[1] provides the ‘elegant’ approach, which is technology that can “read” language based on the business vocabulary (e.g., RuleSpeak) and/or dialog with people to disambiguate those statements. Until such technology is commercially available – and why not, look what IBM Watson can do! – two forms of each statement are unfortunately necessary. The key for your rule management regime is to maintain traceability between them. By the way, the mapping is almost certainly 1:m, not 1:1. I wish I had a better answer, but there just is none today. All I can say is that current implementation technologies for business rules are very, very primitive. ~~~~~~~~~~~ Acks: Tom Andries 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

It’s time to come to grips with what is meant by “rule” in the context of big data. There’s much confusion out there. In a recent keynote, Rick van der Lans stated, “… big data leads to more and more interesting insights, and from there to more and more rules.” What does he mean? The funny thing is you can also call ‘insights’ rules … and some people do(!). Not me! Read on. An Example One of Rick’s examples of rules born from big data:

If 2 calls disconnect within 10 minutes, then offer a product discount.

What’s the insight and what’s the rule? Does the statement represent both? Does it express a business rule? The syntax of the statement is in if-then form. Doesn’t that imply a business rule?! No! According to the standards SBVR and the Business Motivation Model (BMM), business rules must be:

• Declarative. The statement above is not declarative because it includes the command “offer”.
• Practicable. The statement above is not practicable – not ready to roll out into prime-time business operations – because it’s ambiguous. More on that momentarily.

My analysis …

• “2 calls disconnect within 10 minutes” … That part of the statement suggests an insight: Calls on hold for 10 minutes or more are likely to disconnect.
• “offer a product discount” … That part of the statement suggests a remedy, a way to recover from a bad situation.

The motivation behind the statement might be:

We can assume people are getting frustrated at the 10 minute mark or before. If we offer a product discount, they’ll be mollified and more likely to hold on or to purchase.

What should we call the statement? It does give guidance and it does clearly have a role in strategy. However, neither the insight nor the remedy is practicable. Here are some unanswered questions that could produce ambiguity.

The insight part: Does the 10 minutes refer the wait period on each individual call? Or to any time interval during which calls are waiting?

The remedy part: How much discount? On which product(s)?

So according to the standards the statement represents a business policy, not a business rule. A corresponding business rule might be:

A caller must be offered a 15% discount off list price on any product in stock if the caller has been on hold for more than 10 minutes.

This version removes the ambiguities. It clarifies that we’re referring to:

• The wait period on an individual call.
• A 15% discount off list price.
• Any product in stock.

Only WonkNerds Beyond This point “Rule” has several meanings – one reason I try to avoid the word as much as possible. Compare the following definitions for “rule”. (All definitions from Merriam-Webster Unabridged Dictionary.)

2a(1): a statement of a fact or relationship generally found to hold good : a usually valid generalization

Let’s call this meaning rule₁. It roughly corresponds to insight … i.e., “as a rule we find that …”. It’s experiential – based on evidence.

1f: one of a set of usually official regulations by which an activity is governed

Let’s call this meaning rule₂. It roughly corresponds to the underlying sense of business rule … i.e., “It’s necessary or obligated that you must …”. It’s deliberate, based on policy. Job one in analysis of big data is to identify interesting relationships (rule₁) and then deliberately formulate business rules (rule₂) to produce outcomes desirable for your company. In other words, starting from rule₁ you want to move expeditiously to rule₂. Logicians have been on top of this distinction for a long, long. Only they speak in terms of implications, not rules. There are two kinds of implications – material and logical. Let’s repeat the discussion above using these terms. Don’t overlook the word strictly in the second definition. material implication (rule₁)

2b(1) : a logical relationship of the form symbolically rendered *if p then q* in which p and q are propositions and in which p is false or q is true or both

logical implication (rule₂)

2b(2) : a logical relationship of the form symbolically rendered *if p then strictly q* in which q is deducible from p

Let me repeat myself on job one in analysis of big data using implication:

Job one in analysis of big data is to identify material implications (rule₁) and then deliberately formulate logical implications (rule₂) to produce outcomes desirable for the company. In other words, starting from material implications (rule₁) you want to move expeditiously to logical implications (rule₂).

I use “business rule” only for a statement of the rule₂ variety, and only if that statement is both declarative and practicable. A statement has to prove itself to be a business rule – it’s only a pretender if it fails to meet the standards.

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

RuleSpeak^® (free on www.RuleSpeak.com) is a set of guidelines for expressing business rules in concise, business-friendly fashion using structured natural language.  The guidelines arose from over 15 years of real-life consulting work by our company on hundreds of projects. They’ve been thoroughly road-tested(!). RuleSpeak was one of three reference notations for the 2007 OMG standard SBVR[1], a very deep body of work in the fields of logic, linguistics and software engineering, and is fully consistent with that standard. (SBVR does not standardize notation.) It’s been thoroughly guru-tested as well(!).            Emily Springer, business architect at a major insurance company, says[2]: 

“Before we started using RuleSpeak to express business rules, business people had no idea what they were signing off on.  Introducing RuleSpeak to express business rules was fundamental to getting business people really engaged up-front in truly understanding the business side of requirements.”

RuleSpeak is not a formal language or syntax per se, but a set of best practices.  Its purpose is to bring greater clarity and consistency in communicating business rules among business people, Business Analysts, and IT, especially behavioral rulesand those many definitional rules that cannot be handled by decision tables. Originally for English, parallel versions for Dutch, Spanish, and German were released in 2009.  Versions for other natural languages are under development.  RuleSpeak and SBVR recognize that business rules need to be expressed declaratively as complete sentences.  If sentences aren’t the best way to communicate many kinds of know-how, we sure do waste a lot of money on all those years of grade-school and university education!

---

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, October, 2011, 304 pp, http://www.brsolutions.com/bbs You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf

Reference Sources
[BMM]	The Business Motivation Model (BMM) ~ Business Governance in a Volatile World.  [May 2010].  Originally published Nov. 2000.  Now an adopted standard of the Object Management Group (OMG).
[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.

  rule:    [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

              Note:  When we say rule we always mean real-world rule. business rule:  [SBVR]:  a rule that is under business jurisdiction

Discussion:  A business rule is a criterion used to guide day-to-day business activity, shape operational business judgments, or make operational business decisions. 

Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  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.

Each business rule gives well-formed, practicable guidance.  Each uses terms and wordings about operational business things that should based on a structured business vocabulary (concept model, also called fact model).  Each expression is declarative, rather than procedural.  Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.

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.  Except for eCommerce, 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.”

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

SBVR provides the semantics for business rules.  In SBVR a business rule can be either a behavioral rule or a definitional rule.  Incidentally, SBVR does not standardize notation.  We use RuleSpeak to express business rules (including ‘exceptions’) in structured natural language.  

In SBVR, a real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule, but rather an advice.  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. 

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.

business policy:  a means that limits or establishes a degree of freedom for day-to-day business activity

Discussion:  Business managers create business policiesto control, guide, and shape day-to-day business activity.  Business policies are an important element of business strategy (e.g., Policy Charters) and the source of core business rules.

A business policy is not a business rule per se.  To become some business rule(s) first the business policy must be interpreted into a practicable form.  The Business Motivation Model [BMM] contrasts business policies and business rules this way:

“Compared to a business rule, a business policy tends to be less structured, less discrete, less atomic, less compliant with standard business vocabulary, and less formally articulated.” 

In general, business policies can address any of the concerns in Table 1, often in combinations (e.g., how many people are needed to produce a desired yield in the desired cycle time).  Business policies can also address exceptions (rules).

 Table 1.  Concerns that Business Policies Can Address

Question Word	General Focus of Concern	More Selective Examples
What	what things should (or should not) be available	required kinds, quantities, states, or configurations
How	how things should (or should not) be done	required outputs or yields
Where	where things that should (or should not) be done	required facilities, locations, or transfer rates
Who	who should (or should not) do things	required responsibilities, interactions, or work products
When	when things should (or should not) be done	required scheduling or cycle times
Why	why certain choices should (or should not) be made	required priorities

           

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).

Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:

• When the first order is placed by a customer.
• When an agent leaves the company (which could leave an order-placing customer without an agent).

How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:

• Detect violations of behavioral rules (like cops and referees).
• Permit dynamic invocation of selective (read “selectively different”) responses.

Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/

In current discussions, I find people are not being careful about the difference between “event” and “business rule”. An event is something that happens. A business rule gives guidance. An event is an event and a business rule is a business rule. A business rule can produce a fact (‘automatically’) that an event has occurred. But that fact is not the same as the event or the business rule either. To see the whole picture, you need to relate 3 distinct things. The following example Illustrates. The Event …

A credit card is used to purchase something. The purchase happens in the real (or virtual) world.

The Business Rule …

A credit card event must be considered potentially fraudulent if all the following are true:

• The credit card is used to purchase a very low value item.
• The credit card is used to purchase a very high value item that is easily resellable.
• The second purchase occurs after the first purchase by less than an hour.

The Fact …

“Credit card event is potentially fraudulent.” This fact is what we know (or infer) about what happened in the real world.

These are three distinct things representing how what we know is derived from what happens in the world around us. P.S. This position represents the SBVR view.

guest post by Jan Purchase, Director of Lux Magi Ltd ~~~~~~~~~~~~~~~~~~~~~ I do see value in distinguishing ‘policy’ rules from ‘expert’ rules. It’s also clear that, at their extremes, these rule types are poles apart. Still I fear that this distinction may be a continuum rather than a discrete dichotomy. Policy rules might be exemplified as the constraints of business operational practice – the rules that dictate what a company should and should not do. They might be mined from the boundary conditions of the fact model of the company’s business capability – as you suggest in your excellent book on this subject[1]. An example policy rule might assert, for example, “A company agent may be assigned to a high-value customer only if the agent is assigned to at most five other clients”. Expert rules, on the other hand, are often seen as more complex – for example, using heuristics to determine the best, anti-cancer drug to apply in a given situation, or forecasting regional sales opportunities. Often these expert rule bases use expert experience, genetic algorithms, fuzzy logic and feedback loops to reach a decision. They seek to augment, or even supplant, the wisdom of a small population of subject matter experts. But isn’t there a middle ground too? Consider an insurance policy decision rule that bin-sorts clients into good, bad and medium risk (the latter to be referred to a human underwriting expert). If this were a simple four-row, decision table based on the value of the policy and the risk profile of a client, you would probably consider it a ‘policy rule’. But if I add scorecarding, heuristics and analytics, at what point does it become an ‘expert rule’? Would you consider all decision rules (as opposed to constraint rules) to be ‘expert rules’? Or do they need to be complex or directly represent the experience of SMEs? Don’t all rules, to some extent, represent the wisdom of experts? Don’t many of them constitute and inform policy? In short: Is there a simple question we can ask (concerning a rule) to determine if it is a ‘policy’ or ‘expert’ rule? ~~~~~~~~~~~~~~~~~~~~~~~~ See my reply to Jan: http://www.brsolutions.com/2012/05/29/the-debate-continues-expert-systems-vs-business-rules/ Answer to Jan’s Question: The question to ask of every rule is whether the end-point is enforcement or is it a decision. An enforcement rule never becomes a decision rule, and a decision rule never becomes an enforcement rule. Once an enforcement rule, always an enforcement rule (assuming you don’t retire it). You can adjust thresholds (e.g., the mph of the speed limit), you can change the enforcement level (e.g., from ‘strictly enforced’ to ‘override with explanation’), you can change the sanctions (or eliminate them), etc., etc. And you can and should use analytics to measure and improve the rate of success in achieving underlying business goals. But it’s black and white. Enforcement is enforcement and decisions are decisions.

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).