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!
As part of the April announcement of the new 4th edition of my book Business Rule Concepts: Getting to the Point of Knowledge, I’m pleased to make available some additional complementary (and complimentary!) downloads: Decision Analysis – A Primer: How to Use DecisionSpeak™ and Question Charts (Q-Charts™) – 49pphttp://www.brsolutions.com/IPSpeakPrimers(free)Decision Tables – A Primer: How to Use TableSpeak™– 121pphttp://www.brsolutions.com/IPSpeakPrimers (free)Tabulation of Lists in Rulespeak®: A Primer – Using “The Following” Clause – 16pp
http://www.brsolutions.com/IPSpeakPrimers(free)We’ve comprehensively written-up state-of-the-art experience and insight in these important areas. I hope you will make the most of them!
P.S. Do have a look at other items of interest: http://goo.gl/WPV7O
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.
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
I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.phpThe Manifesto is celebrating its 10th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …
The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles.The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm
The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.
A Business Analyst recently said, “Business Rules themselves tend to be too unstructured to stand alone “. Au contraire! Well-expressed business rules are discrete, specific, and context-independent. Think about laws, regulations, contracts, agreements, deals, policies, etc. as common sources for business rules. Business rules are interpretations that make those things practicable. Those things can certainly stand alone. So can the interpretations.The test of ‘practicable’ (the term used in relevant standards) is ‘Can a worker who is authorized and capable know what to do or not to do as a result of reading it?’ Business rules must be well-structured to pass that test. More broadly, ‘practicable’ means ready to deploy into the business for workers to follow, or to pass over to IT as part of requirements in building systems – either way with the same results. Practicable business rules are encoded know-how of the business, vital operational IP. They are explicit, not tacit, so they can be retained, managed and re-used. Business rule management is the most practical means around for meaningful knowledge retention.
The relevant standard on the question is OMG’s Business Motivation Model (BMM). I prefer the English (not UML) version: http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf. Business policies and business rules are both ‘elements of guidance’. The difference is that business policies are not practicable, whereas business rules always are. A business rule must be ready to deploy to the business, whether to workers or to IT (i.e., as a ‘requirement’). So business policies must be interpreted and refined to turn them into business rules. An example I often use:
Business Policy: Safety is our first concern.
Business Rule: A hard hat must be worn in a construction site.
It’s very important to retain information about these interpretations for the sake of traceability. That’s at the heart of business rule management.Business policies are an integral part of strategy. In general, we find only 2-3% of business rules trace directly back to strategy. But those *core* business rules are very, very important (to enforce and monitor).One last point: Business rules must be expressed in a form that is understandable to business workers (who are authorized and capable). What IT usually specifies or implements as ‘business rules’ aren’t. They might be rules, but not business rules.And what do I mean by “rule”? Exactly what it means in the real world – ‘guide for conduct or action’ (Merriam-Webster Unabridged).
Consider the following behavioral business rule: A renter must not have possession of more than one rental car.
In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’.
Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about?
When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.
There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.
A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in.
Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules).
Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc.
We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t.
Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.
I’m kicking off 2012 with a couple of things I just don’t get. Here’s the third one: I haven’t been able to find anyone so far talking about agile governance. Why not?!
I recently posted this on an architecture and governance forum:
Is there such a thing as ‘agile’ governance’? What would it entail? Looking for ideas or experience in the matter … Here are a few thoughts. I think answers should touch on business policies and business rules. And put agile IT development into perspective. What am I missing? http://goo.gl/nCpPC
Guess what I got back? Thoughts on software platform governance, agile methods applied to business rule development, and more – everything except what I was looking for. Perhaps I’m partly to blame myself. There’s always going to be problems when you (me in this case) don’t define terms.
By ‘governance’ I meant *business* governance … the running of business operations. The running of the show.
On ‘agile’ I fudged a little. I really meant ‘agile’ simply in its real-world (dictionary) sense of “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations”. But I knew ‘agile’ would probably invoke the IT sense.
So let me try again: Does anybody have any thoughts on *agile governance*? To be more clear this time what I mean by ‘agile governance’ …
Agile governance: the running of business operations in a manner “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations” … where business rules, business policy, and rule management play a key role.
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“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
“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!”