In classifying ‘rules’ I go by the standards … Business Motivation Model (BMM): business policies vs. business rules
Business rules are always practicable – workers can apply them directly.
Business policies are not – they must be interpreted first.
SBVR: definitional rules (necessities) vs. behavioral rules (obligations) vs. advices (possibilities or permissions).
Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
Behavioral rules are about shaping conduct (and can be violated).
Advices are non-rules; they provide practicable guidance but do not remove any degree of freedom.
I would add only these observations:
The kinds of rules you see in decision tables are generally definitional. Since they represent only a subset of all definitional rules I call them ‘decision rules’ for convenience.
Condition-Action or Event-Condition-Action (ECA) rules are not business rules at all. They are representations of business rules (for a class of implementation platforms).
My smart phone can tell me in spoken English where the nearest gas station is. It’s only a matter of time before machines start ‘reading’ regulations, contracts, agreements, business policies, etc. to help people formulate (through dialog) practicable (and implementable) business rules. Can you imagine the productivity benefits?!
Decision tables are great. Everybody should use them. But they are a lot harder to design well than you might think.
The DMN standard can move things along significantly … if it is good, and it isn’t overhyped (which it already has been in certain quarters). I’m looking forward to it impatiently. But standardization (in equal parts a political process and a technical process) do take some time!
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, 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:
“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!
Semantics of Business Vocabulary and Business Rules – See the SBVR Insider section on www.BRCommunity.com for discussion.
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
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).
Merriam-Webster Unabridged Dictionary (Version 2.5). . Merriam-Webster Inc.
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
what things should (or should not) be available
required kinds, quantities, states, or configurations
how things should (or should not) be done
required outputs or yields
where things that should (or should not) be done
required facilities, locations, or transfer rates
who should (or should not) do things
required responsibilities, interactions, or work products
when things should (or should not) be done
required scheduling or cycle times
why certain choices should (or should not) be made
The OMG standard SBVR distinguishes between two fundamental kinds of business rules:
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 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.
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).
In football, when a referee throws a flag, the results of the most recent transform (play) are undone. In effect, by enforcing a rule, the referee prevents or negates the new state (yardline and sometimes the down) and enforces some other state. That’s the way behavioral business rules work. Speed through a school zone and see if your desired state isn’t modified if some policeman happens to be watching.The relationship between behavioral rules and business processes is an indirect one, through state. Business tasks try to produce new states; behavioral rules step in to modify or prevent the new state if a violation occurs … just like the policeman parked in the school zone with a radar gun.More precisely, business tasks precipitate events that try to change state (the outputs, final or interim), and behavioral rules ‘watch’ for the particular events that produce violations. A violation produces a response, which can be another process – e.g., the referee jumping in to whistle the play dead or the policeman putting down his doughnut and chasing you.Yes, it’s important know which business tasks can violate which behavioral rules, but their relationship more complexly networked than you might think. In general, every behavioral rule expressed declaratively can be analyzed to produce two or more events (I call them flash points) where it can be violated and needs to be evaluated. I can provide endless examples. (Refer to http://www.brcommunity.com/b623.php?zoom_highlight=flash+point or to Chapter 8 of Business Rule Concepts, 3rd ed.) These events are likely to be in different business processes (or procedures or use cases) … and sometimes a given process may not have been modeled at all (or the event occurs ‘spontaneously’). The fact that each behavioral business rule can be violated at two or more flash points is a fundamental insight of the business rule approach. It’s precisely where current platforms, tools and methodologies fall short, and why consistency and compliance are so difficult to achieve. In other words, it’s an essential idea in really ‘getting’ business rules.
 In SBVR, there are two kinds of business rules; the second kind is definitional rules. As their name suggests, definitional business rules shape concepts and provide criteria for making decisions.
For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly.But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters.True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today.Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules.~~~~~~~~~~~~~~~~~~~~~~~~~~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 a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use. Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class.Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world.But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world.Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used.In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVRThe world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart.What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:
The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”.
The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”
There is no other practical way to communicate business concepts and establish relationships among them. You need nouns and verbs to write sentences and convey meaning – it’s as simple as that.Once you look at the problem this way, forcing “fact model” and “fact type” on business people is unnatural and unnecessary. It commits a cardinal sin in business analysis – using unnatural terms for natural business concepts. The most natural terms for the concepts meant by SBVR are “concept model” and “verb concept”. About Business RulesFor my part, I didn’t arrive at this understanding through the path above – or for that matter any other path you are likely to guess. The need for the shift dawned on me when I saw business rules being included in populations of facts. Hold on, how could a rule be treated as a fact?! Well, exactly!To a logician or database guru, however, treating a rule as a fact makes perfect sense. Formal logic is all about propositions. A business rule is a proposition taken to be true – in other words, a fact. So of course business rules belong in populations of facts and therefore in fact models. It couldn’t be any other way. And I agree. The only problem is that in SBVR we want to talk directly about the real world.The Bottom LineSo a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts. Actually, it’s more than that. By ‘map’ I don’t mean either of the following on its own:
A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential.
Some diagram(s) – although often quite useful.
Rather, I mean a non-redundant, integrated, anomaly-free structure of concepts based on interlocking definitions – a blueprint of meanings. How is an SBVR-style concept model different from (and better than) a traditional “conceptual data model” (or entity-relationship diagram)? Instead of mere lines to represent relationships between noun concepts, with an SBVR-style concept model we have verbs. These verbs reveal the intended meanings of the relationships. With verbs I can verbalize – literally communicate (and demonstrate) what is meant. No more hidden meaning!
 But not in the underpinning of SBVR in formal logic.
 Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
 I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
 I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.
One thing that concerns me about ‘decision’ or ‘decision management’ is that everything potentially becomes a decision. Software vendors love it when complex problems can be reduced to a single buzzword. Engineers of true business solutions should hate it.
I’m sure I’ll be accused of negativism, so for the record, let me say that top down analysis of operational business decisions is extremely useful, either along with, or outside of, business processes. We have a highly pragmatic approach for decision analysis based on ‘question charts’ (Q-Charts). We use it extensively to capture decision rules.
But do I think that decision analysis is the most important part of delivering a winning business solution? Not by a long shot. Your strategy for the business solution is much more important. Even that’s not enough though – strategy only tells you why. We need business models that cover all aspects of a business solution (think what, how, where, who, and when).
So no, it doesn’t (or at least shouldn’t) all boil down to ‘decisions’ … unless by that you mean anything and everything. And what good is that?
I’m always very careful to say ‘operational business decision’ instead of simply ‘decision’. Immediately that excludes governance decisions (e.g., creating a business policy) and strategy ‘decisions’ (as in MBA-school ‘business strategy’). That’s an important first narrowing of the field.
Something else commonly mistaken for an operational business decision is a simulation of “what would happen if we did this operational task right now”. For example, let’s run a claim by all the behavioral business rules and see if the claim is acceptable before we do it for real. That’s simply a test, not a decision. That’s a second important narrowing of the field.
Clearly we need a solid definition of what a decision is and isn’t in the context of business analysis. We define an ‘operational business decision’ as: a determination in day-to-day business activity requiring know-how or expertise; the resolving of a question by identifying some correct or optimal choice. To make such decisions you need decision rules (think classification or inference rules) that ‘map’ cases to outcomes. Decision rules are one type of definitional rule. The two types of business rules in SBVR are definitional rules and behavioral rules.
Business capabilities do usually involve large numbers of decision rules, but they also always involve large numbers of behavioral rules. Behavioral rules are rules you can violate, like speeding through a school zone. There’s no decision to that … you either are or you aren’t speeding. Well, you may have made a personal decision to speed, but let me tell you, City Hall doesn’t care. Personal decisions – out of scope too, a third important narrowing of the field.
If you want to hear state-of-the-art machines (bots) talk to each other, see: http://goo.gl/LEIMI Funny! Rude and petty … just like humans sometimes. I don’t think we’re quite there on Star-Trek-style communication with machines(!).
If you want to see a suitable set of guidelines for writing unambiguous business rules that machines should be able to understand, see www.RuleSpeak.com (free). RuleSpeak was one of the three reference notations used in creating SBVR, the OMG standard Semantics of Business Vocabularies and Business Rules. (SBVR doesn’t standardize notation.) Don’t try to read the SBVR standard – it’s for logicians, linguists and software engineers. For insight into what SBVR is about, see the SBVR Insider section on www.BRCommunity.com.
SBVR itself is a structured vocabulary – essentially a concept system. Clause 11 provides a structured vocabulary for creating structured vocabularies. Clause 12 provides vocabulary for business rules. ‘Structured’ in this context means it includes both noun concepts (nothing unusual about that) and verb concepts (highly unusual). You need verbs to write sentences (propositions). Try writing a 100 business rules without standard verbs. Well, you can do it, but what you’ll get is spaghetti logic and hopeless, bot-like(?) communication.
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”