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

           

I’ve written on this subject many times before, but let me summarize my position concisely. By the way, I expect heavy flak on the last point. See what you think. (1) Business rules should be expressed declaratively based on common business vocabulary.

An implication for business rules: No direct invocation of functions.

(2) No reference whatsoever should be made to events in expressing business rules.

Exception: Some business rules (a small minority) truly apply only at the time a given business event occurs. Example: A hotel guest must be given fresh cookies upon check-in.

(3) Behavioral rules (unlike decision rules) should always be evaluated immediately when any relevant event occurs. Such ability supports real-time compliance. (Read about behavioral rules vs. decision rules on http://www.brcommunity.com/b623.php.)

One Implication: You have to know what those relevant events are.

(4) The events to which a declarative rule applies can (and should) be determined automatically.

USoft proved the principle 20 years ago. SBVR’s treatment of business rules is based on the assumption.

(5) It’s important to determine the events automatically for behavioral rules because that way you can take programmers out of the business of event detection and management.

The benefits of doing so would be immense.

(6) Events bear a direct relationship to business rules in the sense that behavioral rules need to be invoked automatically when events occur.

How else can you achieve comprehensive consistency of behavior?!

(7) Business rules bear no such direct relationship to processes.

Do we really want programmers and designers to remain in the business of event detection and management forever?! In my opinion that’s a very bad idea.

(8) Some (many?) business capabilities (e.g., highly social ‘processes’) could be modeled and run without business process models altogether.

How would it work? You need:

• Declarative business rules.
• Work milestones (states through which loosely organized work still must progress).
• Automatic event identification (as in USoft).
• Event detection and management (as in Tibco).

 

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:

• business rules 
• operational business decisions 
• structured business vocabularies (concept models, also known as fact models) 
• business goals and risks 
• business events

From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

Business governance and business rules are directly linked. Bear with me for a moment while we go over what some words mean. So as not argue over them, let’s go to an authoritative source. The following definitions are from Merriam-Webster Unabridged Dictionary. govern [1a]: to exercise arbitrarily or by established rules continuous sovereign authority over; especially: to control and direct the making and administration of policy in Note the high-profile roles of (business) policies and (business) rules in this definition. I didn’t make that up. So ‘governing’ a business involves coordinating how business policies and business rules are created (the making … of) and deployed (managed, distributed and monitored) within day-to-day business operations (administration). governance [1]: the act or process of governing [2a]: the office, power, or function of governing [4a]: the manner or method of governing [5]: a system of governing Based directly on these definitions, here’s my definition for business governance. business governance:  a  process, organizational function, set of techniques, and systematic approach for creating and deploying business policies and business rules into day-to-day business activity Why haven’t more people recognized the direct link between business governance and business rules?! I wish I knew. Sooner or later, they will. ~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

In the real world, we communicate with sentences … just like we are doing now. If a “data model” can’t support writing meaningful and consistent sentences, then surely something is amiss. Business rules are always sentences, so you can see where I’m going with this. So I come to this radical and provocative suspicion: The reason data models remain so often disconnected from other things in the business and IT, and why data modelers generally so under-empowered, is that data modeling practices have been removed them from direct engagement with business logic. Shouldn’t be that way. Won’t ever work well. I’m sure there are a whole lot of people who disagree with me. So I am going to write a series of posts this week on the subject … and call this ‘data model’ week.

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.

It almost goes without saying (but I’ll say it anyway) that you must know exactly what the words mean in all parts of your business requirements. In running a complex business (and what business isn’t complex these days?!), the meaning of the words can simply never be taken as a ‘given’. Some IT professionals believe that if they can model the behavior of a business capability (or more likely, some information system to support it), structural components of the know-how will somehow fall into place. That’s naïve and simply wrong. Business can no longer afford such thinking. A single, unified business vocabulary (fact model) is a prerequisite for creating a scalable, multi-use body of business rules – not to mention good business requirements. It’s what you need to express what you know precisely, consistently, and without ambiguity. Certainly no form of business rule expression or representation, including decision tables, is viable or complete if not based on one. And I pretty certain that’s true for most other forms of business communication about day-to-day business activity too. What am I missing something here?  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

A restaurant sometimes allows members of a party to split the bill for a meal so each person can pay just part. Business Rule: The amount paid for a meal may be split among the members of the party served the meal only if all the following are true:

• Each member initials his or her portion of the amount paid on the bill for the meal.
• Each member provides the room number in which he or she is currently registered in the hotel

Does the restaurant have some business process for collecting payment? Of course. The bill for meals usually does get paid (usually involving a transform of my personal financial resources!). But that’s not the right question. The real question is whether the business process is simply ad hoc, or modeled and prescribed (or somewhere in between). No matter, the business rule always applies. That’s important because there will always be at least some ad hoc business activity – and perhaps quite a lot. ~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

A practitioner recently wrote: ” … businesses typically have over a thousand different business processes. There are often variations of business processes for different regions, products, exceptions and business areas as well as other reasons, that’s why there are so many …”. What kind of “process” could he possibly mean!? A business couldn’t possibly have over a thousand business processes. Such a business would be unmanageable. (Unfortunately, some businesses probably aren’t.) The practitioner’s view misses the crucial insight that for both operational and financial reasons, a business must have a small set of core business processes that are standard. Variations can be handled … within what is acceptable … by business rules. Such variation might have to do with geography, products, best practices, etc. Without business rules, the complexity is simply unmanageable.