Want context-sensitive business rules? It doesn’t necessarily work the way you think it might. Let’s take an example: A client must have a physical address. That’s the rule; it just says what it says.
Separately from the rule itself, several things can be specified:
How strictly the rule is to be enforced. Such specification might be: ‘strictly enforced’, ‘override with prior authorization’, ‘override with explanation’, ‘guideline’, etc.
What response and/or message is appropriate when the rule is violated.
Both things can be specified to be context-dependent. Back to the example:
Suppose the rule is violated in signing up as a member of a website. The enforcement level might be “guideline” and the response might be “We encourage you to provide this information so that we may serve you better in the future.”
Suppose the rule is violated in placing an order. The enforcement level might be “strictly enforced” and the response might be “We’re sorry. But we need your address to send you this order.”
I was reading some discussion about data models the other day and came across the following:
“The relationships between entities define the rules about which entities relate to others, as well as the number of minimum and maximum occurrences on each side of the relationship.”
Rules is definitely the wrong choice of word here. The misconception that relationships per se in data models represent (business) rules goes all the way back to the 1980s. It’s simply wrong. Instead I would say:
The relationships between entities provide structure for the data model, specifically indicating which entities relate to which and how. Specifications for a relationship typically indicate the number of minimum and maximum occurrences allowed on each side of that relationship – i.e., their cardinalities.
Of the three typical cardinality values – zero, one and many – only one removes any degree of freedom, and thus could be said to represent a rule. In any case, cardinality per se is a specification device; the business rule is in the meaning – for example:
A customer may be related to at most only one sales area.
The two fundamental kinds of business rules relevant to business analysis are definitional rule and behavioral rule. These two kinds of rule come from OMG’s SBVR (Semantics of Business Vocabulary and Business Rules) standard. They have very precise meanings based on formal logic. Here’s some background about that – more than business analysts really need to know, but informative nonetheless. At the end of the discussion I give pragmatic definitions. And the answer to the photo quiz.The SBVR definition for rule is deeply embedded in formal logic, which deals with propositions. In modal logic, propositions can claim different modes. For business rules the two relevant modes are alethic and deontic.
Alethic rules are true ‘by definition’. As such they cannot be violated. They are about how concepts, knowledge or information are defined or structured.
Deontic rules are rules that can be violated. They are rules about behavior, not concepts, knowledge or information. Deontic rules are really about people, what they must and must not do, even if their activity (and the rules) are automated.
Both kinds of rules are important, of course, but deontic rules – people rules – are especially so since ultimately, businesses are about the activity of people. This situation is very different than in the semantic web, for example, where it’s all about only knowledge.Under modal logic, every rule must therefore ‘claim’ one of two modes. (In practice, the ‘claim’ arises naturally from the syntax of a rule statement or as a meta-property.)
Alethic implications (rules) are established by ‘claiming’ necessity. Things are necessarily true. A concept is what it is; says what it says. That’s just the way things are.
Deontic implications (rules) are established by ‘claiming’ obligation. Behavior is ‘obliged’ to follow the rule. But of course, people don’t always follow the rules, so there can be violations. Major difference.
So a rule ‘claims’ either necessity or obligation, which establishes what kind of rule it is. Therefore the SBVR definitions for the two kinds of rule are:
Definitional rule: rule that is a claim of necessity
Behavioral rule: business rule that is a claim of obligation
Why doesn’t the definition for definitional rule say “business rule” like the one for behavioral rule? Because some definitional rules are not ‘under business jurisdiction’ (in other words, business has no choice about them). Examples include the ‘law’ of gravity and all the rules of mathematics. Those rules are simply universally true. I recommend the following pragmatic definitions for business analysts.
Definitional rule: a rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge or information
Behavioral rule: a business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity
Synonyms: Early in the development of SBVR I introduced the terms structural rule and operative rule for the two kinds of rules, respectively. That was before the full implications of modal logic became clear. Since then the terms definitional rule and behavioral rule have become preferred, even in all internal SBVR discussion. The synonyms, however, remain valid.
P.S. Did you guess correctly which kind of rule is represented in the photograph? Behavioral, of course. And the photo itself is a violation of the rule.
Amit Mitra, Senior Manager at TCS America, commented:Is there such a thing as a metaprocess? Yes, there is! I am teaching the metaprocess in a master’s course … as a part of an overall model of knowledge that integrates reasoning, measurement, business rules, and process. Indeed, you can infer the business functionality required of the ideal BPM tool from the properties and parameters of the metaprocess (No current tools support them all, but they do support the most obvious properties). The metaprocess also accounts for progressively unstructured processes, and processes that reason about themselves, to infer how they could adapt to different situations. My reply: Interesting indeed. However, what is your definition of process?
I think the key part of what a process is (and isn’t) is that it transforms something (turns raw material into finished goods, inputs into outputs). Business rules never transform anything – that’s a key differentiator from business processes. Reasoning and measurement ‘transform’ something only in a trivial sense.
My point is that the thing you’ve created a meta- for isn’t really a process. It’s more comprehensive. It’s more like core business know-how or core business capability.
The industry desperately needs a better name for the kind of thing you’re creating … because it’s central to moving toward a knowledge economy (and a more rational, sustainable way of doing business).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Eric Ducos, CTO of EmeriCon, commented:Is there such a thing as a metaprocess? I would definitely think so. A methodology for identifying, analyzing and building a BPM solution is a metaprocess (i.e. a process to build a process).My reply: I agree except for the word methodology. A methodology is more than a process. It includes rules and guidelines, for example.
Merriam-Webster Unabridged Dictionary (MWUD) defines methodology as (1a):
a body of methods, procedures, working concepts, rules, and postulates employed by a science, art, or discipline.
But here’s a thought: There could be such a thing as a meta-methodology … a methodology indicating how to create (other) methodologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~John Morris, Director, Solutions Sales at Bosch Software Innovations, commented:
In terms of driving work on metaprocesses, I suspect that tort law, regulation and compliance issues might eventually prove to be motivators, more than competition. One might think that having good software would be guaranteed by competition, especially as the information content of most products and services is increasing. The governance challenge, however, is that the semantic content of software is buried by “what you see” – i.e., the surface of the software. All too often that’s where discussion stops.
My reply: I couldn’t agree more. That gets you into rules and meta-rules – i.e., into something more than processes.
 This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:
3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*
The following statement came up recently in discussing business rules at Global Holdings. (Not the real name of the company.) The statement has significant problems. Sometimes simple is too simple.
Global Holdings must review the corporate account of ABC Company.
Problem 1. In general, it is not a best practice to mention “us” in specifying business rules. Do that once, then every other business rule statement should mention “us” too. That’s clearly not practical or useful, and in most cases, not even intuitive. So the current specification should be revised simply to:
The corporate account of ABC Company must be reviewed.
Problem 2. The ‘rule’ doesn’t pass basic tests of practicality or usefulness. What point would it serve to have a business rule saying that something must be reviewed without indicating one or more of the following?
some method (how?)
some location (where?)
some role (by whom?)
some timing (how often?)
some potential goal or constraint (is there potential fraud?)
In other words, the statement mandates a review based on criteria not encoded. Those absent review criteria probably represent the true business rules. To say it differently, a ‘rule’ that simply kicks out work for a human to do is probably not a business rule at all!Problem 3. As it stands, the practical effect of the statement would be to require ABC account to be reviewed as soon as it comes into being (and indicate a violation if it is not). Very few things must be reviewed for unspecified criteria at the very time they are created. Real business just doesn’t work that way.
Bottom Line: Unless additional specification is provided, this simpleton ‘rule’ should be discarded. It’s basically just toothless.
I am gearing up for a week of seminars (through FTI http://goo.gl/jtu2K1) and a keynote (at BASSA http://www.sbs.co.za/bassa2013/) in South Africa the next several weeks.
To prepare me for my visit, Cecilia Pearce has kindly explained some of the rules of the road, and the related vocabulary, that apply in Johannesburg and Cape Town. I’ll report back on any discrepancies I run into. I hope not to run into anything else(!).
Steve Erlank of FTI and Cecilia both write they are ‘holding thumbs’ for me. Turns out that’s a good thing. ‘Holding thumbs’ is an idiom used to wish good luck, like crossing your fingers. Who knew?
Rules and VocabularyAcks: Cecilia Pearce Behavioral Rule: The show of a hand, similar to the royal wave, solves all indiscretions that may have occurred.
Behavioral Rule (with low enforcement level): A red light, on a robot, does not necessarily mean a vehicle will stop.
Definition: A ‘robot’ is referred to as a traffic light in America.
Behavioral Rules: ‘Taxis’ seem to believe they own the road. They have the right of way and may stop at any time. They may decide to switch their hazards on as they stop … if they work. Take care not to tailgate.
Definition: A ‘taxi’ is a cross between a cab and a bus, but a mini version. It transports about 18 passengers.
Definitional Rules for Taxis: A ‘taxi’ is not easily identified by color or signage. A ‘taxi’ may be recognized by:
being in very bad condition.
usually being overloaded.
using its hooter almost all the time.
Definition: A ‘hooter’ is known as a horn in America.
Motivation for Constant Use of Hooters: To attract possible passengers.
Definition: A ‘hooter symphony’ occurs when there is a traffic jam. Note: Do not expect any resolution of the traffic problem from a ‘hooter symphony’. You’ll be disappointed.
Behavioral Rules for the ‘Taxi’ System: Should you see somebody standing on the side of the road making weird hand signals, chances are that the signals are not intended for you. This is the mechanism used by prospective passengers to inform an approaching taxi of their destination.
Facts: In South Africa the taxi driver is not provided with your destination; instead a taxi driver goes to specific destinations. Taxis have designated routes but not designated dropping-off areas.
Major Behavioral Rule: And do remember, we drive on the left hand side of the road(!).
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!
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.
1. RuleWhen 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 JurisdictionWhen 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 ExampleOne 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 rule1. 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 rule2. 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 (rule1) and then deliberately formulate business rules (rule2) to produce outcomes desirable for your company. In other words, starting from rule1 you want to move expeditiously to rule2.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 (rule1)
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 (rule2)
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 (rule1) and then deliberately formulate logical implications (rule2) to produce outcomes desirable for the company. In other words, starting from material implications (rule1) you want to move expeditiously to logical implications (rule2).
I use “business rule” only for a statement of the rule2 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.Assigning values to variables.2.Asserting mandatory GUI fields.3.Specifying which data can be viewed by which users. 4.Expressing which documents are to be routed to which queues. 5.Orchestrating tasks assignments in an execution environment. Depending on your implementation preferences, specifications for such things might (or might not) appear rule-ish. But … business rules are what you need to run the business, not what you use to set-up systems (even if rule-ish). Such specifications might be representations of business rules, their surrogates, but they are not business rules per se. Business rules are communicated of, by and for people. Big difference!P.S. For examples see RuleSpeak 3.0 (free download): http://www.brsolutions.com/b_ipspeakprimers.php
“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
“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
“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
“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
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“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!”