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.
Here are some practical do’s and don’ts we’ve learned on the years for validating business rules with business people in facilitated sessions. I should warn you, some of these points are counterintuitive.
Determine whether there is already a trusted source or implementation for a rule. Always re-use, don’t rewrite.
Of course there are exceptions. There are always exceptions. Document them and move on.
Limit discussion about organizational responsibilities for applying the rules. That’s a different discussion.
A rule only addresses exactly what it says explicitly. For example, “high credit usage” doesn’t necessarily mean “high risk”.
How strictly a rule is to be enforced is a separate issue from just what it says. Focus on practicality and precision, not on whether a rule is strictly enforced or just a guideline.
Don’t jump into whether or not current data elements support some aspect of the rule. That’s system design.
Take it as a given that analytics might be used to sharpen some rules. That’s homework.
The goal is consistency and precision for people too, not just for automation.
Avoid brain churn. Eliminate all matters from further discussion except what remains uncertain. If a rule in isolation is not that important, just move on.
Rules are living, breathing things. Don’t be afraid to put a stake in the ground, e.g., a specific number for a threshold, because with well-managed rules, it can be changed at any time.
The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired. In other words, POK is where business rules happen.
When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place. You arrive at smart architectures, which gives you smart knowledge management and smart processes.
In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training. Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance.
A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge. Effective engineering of the POK is the new litmus test for agility.
The question you should be asking: How do you get your company tothe point of knowledge?
Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp,http://www.brsolutions.com/b_concepts.phpwww.BRSolutions.com
Re-engineering knowledge work is the central problem of the knowledge economy. In recent work at Centers for Disease Control (CDC) and current work a major bank in Canada we used RuleSpeak® to create what I call a “single source of truth for operational business IP (intellectual property)”. This is far more than a conceptual data model. Beyond structured business vocabulary its central feature is comprehensive rules. It may be like what some professionals call a “conceptual ontology” (as opposed to an operational ontology to be embedded in IT systems). But we would never use the term “ontology” in our work. Most business people and SMEs simply wouldn’t ‘get’ that.The idea is that all audiences (or subcommunities) in an organization should work off a single trusted source of explicit know-how (business vocabulary and business rules), no matter what their specific responsibilities:
producing training materials for line workers.
making changes in operational policies.
providing proof of compliance for auditors.
creating new products.
communicating with IT.
Here are some key observations about our work to create a single source of business truth:
Our primary audience is not IT. Yet our work is of sufficient precision that straightforward translation into an implementation form can basically be taken as a ‘given’.
Our approach recognizes that people are the essential ingredient in business (as opposed to other kinds of knowledge problems). People can violate rules. For coordinating the work of people, direct support for behavioral rules, not just definitional or decision rules, is a must.
Our work could not be undertaken without a structured natural language for business rules like RuleSpeak. The non-IT audiences do need rich business semantics, but they have no desire whatsoever to become semantic programmers. They simply would not commit if the work were conducted on that basis.
No one today knows what the optimal syntax is for expressing all forms of business know-how in all circumstances. I suspect there isn’t one. That fact, plus the exponential increase in computer capability for processing natural language, indicates clearly that focusing on syntax is simply the wrong direction. RuleSpeak is based on, and was one of the reference languages for SBVR (Semantics of Business Vocabulary and Business Rules, on OMG standard), which supports a non-syntax approach. A language for ‘speaking’ with computers that is not a computer language – now that’s an idea whose time has definitely come!
I have said many times programmers, even semantic programmers, are not the wave of the future for business rules. The future lies with enabling business people and business analysts to have dialogs with machines coming as close to unambiguous statements as they can (e.g., in RuleSpeak). The machine should ask questions to reduce ambiguity to an acceptable minimum. To protect against liability, the machine should log all assumptions, major and minor, in translating to an internal (formal and unambiguous) form so that results are traceable and improvable.Consider IBM Watson. If machines can win at Jeopardy against the best players in the world, that’s a pretty impressive feat for natural language capability.Let’s compare apples to apples. There will always be translation of business ”requirements” from human form to machine form. Even some perfect (a.k.a. formal semantic) implementation language would not reduce translation errors to an absolute minimum. Coders would still have to translate, and errors compound with every translation. So I say disintermediate; eliminate the middlemen – i.e. the coders. If you look across a great many industries, that’s the trend. Why should development of business applications be any different?I also suspect that any “formal semantic” language for business rules would inevitably be English-biased. That’s simply not acceptable in a global economy.RuleSpeak has gathered increasing attention around the world. There are now versions in the works for Norwegian, Polish and Japanese, in addition to the original English and the existing Dutch, German and Spanish translations. A growing number of people find that RuleSpeak strikes just about the right balance between structured and unstructured expression. I’m not saying, however, that other useful approaches couldn’t be more formal – or less formal – than RuleSpeak. Perhaps they could. And that’s been my point for all these years working on SBVR as a business rule standard. We simply don’t yet know the absolute best approach for expressing all business rules in all circumstances. No one knows enough. Perhaps there isn’t one.SBVR is brilliant precisely because it captures semantics without dictating expression form. Long term, that’s exactly what the industry needs. No, there hasn’t been rapid vendor implementation of SBVR since release of 1.0. I wouldn’t expect there to be. It threatens virtually every interface and mindset on the planet. Most people in the IT field still just don’t get it.In retrospect, OMG may have been the wrong forum for SBVR for at least two reasons:
1. OMG is the bastion of best-of-breed programming standards. Obviously there is an important role for that, but as above SBVR isn’t about programming.
2. The SBVR vocabulary is extremely useful for organizing business conversations about business vocabulary and business rules. OMG doesn’t ‘do’ business-facing standards of that kind (i.e., ones that don’t “compute”). IMO, that’s a major shortcoming. There is ultimately nothing more important than improving communication at the level of people. Get it wrong there and I promise it will be wrong in business automation, no matter how elegant the implementation language.
The bottom line is that machines for business (rule) automation now must learn to ‘speak’ human languages. The other way around is simply no longer acceptable – or even necessary.www.BRSolutions.com
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 put that question and the following list on several LinkedIn groups. It was a lot of fun. I feel a little guilty – and dismayed – so many people struggled so hard with it.
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.
So now I should confess it was a trick question. I don’t see any of those things as business rules. They only represent how business rules might be applied or implemented. True business rules:
Are about human communication. So they must be expressed in a manner that business people can understand (if they know the business vocabulary) – e.g., via RuleSpeak.
Would be needed even if you did the business ‘by hand’. So they must be about business issues, not system design or system orchestration issues.
I get this question all the time, and it’s a painful one, so let me answer on the record.Question:In our enterprise architecture tooling, there’s a business dimension in which we define Business Concepts (the real business language), and an IT dimension containing Information Objects (data organization model). How can we solve the problem that business expresses rules as they relate to Business Concepts, while IT needs to translate these into rules related to Information Objects? We don’t want to bother business with IT model concerns, nor duplicate the rules in two places. Can you please shed light on an elegant approach to this dilemma?My answer: The standard SBVR provides the ‘elegant’ approach, which is technology that can “read” language based on the business vocabulary (e.g., RuleSpeak) and/or dialog with people to disambiguate those statements. Until such technology is commercially available – and why not, look what IBM Watson can do! – two forms of each statement are unfortunately necessary. The key for your rule management regime is to maintain traceability between them. By the way, the mapping is almost certainly 1:m, not 1:1.I wish I had a better answer, but there just is none today. All I can say is that current implementation technologies for business rules are very, very primitive. ~~~~~~~~~~~Acks: Tom Andrieswww.BRSolutions.com
 The OMG standard Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section on www.BRCommunity.com for insights about SBVR.
Location: Online Seminar
Do your business processes always produce correct and consistent results? If not the problem probably lies with your business rules and decision logic. Business Analysts need the right techniques to fix these problems – process models, use cases, data models and other requirement techniques just aren’t right for the job. This hands-on series will equip you with proven techniques for success.
More info: http://www.attainingedge.com/online-training-business-rule-analysis-masterclass.phpRegister for full series!
Session 1. The why, what and who of business rules
Next Session: October 1, 2013 @ 10:30am – 12:00noon (ET)
Why business rules
What benefits you can achieve
What business rules are, and are not
Business rules vs. business processes
Kinds of business rules: definitional vs. behavioral
How the business should react to violations
Business rules and decisions
What skills you need to capture business rules effectively
In a recent discussion on social media I was explaining what I thought would make a business architecture smart. Tom Graves replied that he wasn’t sure what made one smart, but that he did know what makes one dumb. His criteria …
rigid rule-based boundaries.
over-reliance on rigid true/false rules.
attempts to implement most or all of that architecture through automated ‘business-rules engines’ that can only work with rigid true/false rules.
He went on to say that these criteria suggest that “a first requirement for a smart business-architecture is that it go beyond all these mistakes.”Tom’s emphasis on ‘true/false’ rules needs to be carefully qualified. After all, you do want the internal workings of a rule engine to be based on formal logic. I believe what he really means is an approach that allows no shades of gray with respect to nuanced enforcement of business rules. On that point I hardily agree.In addition, Tom got me to agree with him on two major points about the current state of the industry. In his words …
1. The quest for ‘certainty’ in an inherently-uncertain world is futile. Rules of all kinds exist to help human thinking and human judgment, not to act as a substitute for it.
2. The software vendors … are frankly not far short of committing fraud with many of the claims they make as to the efficacy and validity of their ‘business-rules engines’.
The term business rule unfortunately has been hijacked by software vendors to mean something very different from the original concept. For example, production rules (the basis for the majority of current product offerings) are not business rules. Full stop.This distorted view of business rule needs to be rectified. Don’t let yourself be sucked into it! For real business rules there are three (optional) supplemental specifications for each business rule statement:
(1) level of enforcement
(2) violation (breach) response
(3) violation (breach) message.
It is through these specifications that the richness of behavioral coordination can arise.
Production rules (also called productions) can be used to implement business rules, but are not business rules per se. Production rules typically provide support for action selection, which results in non-declarative statements. According to Wikipedia, a production rule system (essentially, an expert system) is …
a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules about behavior
Production rule systems are a class of platform whose rule format and operation are aimed toward developers. According to Wikipedia:
“A production system provides the mechanism necessary to execute productions in order to achieve some goal for the system. Productions consist of two parts: a sensory precondition (or ‘IF’ statement) and an action (or ‘THEN’). If a production’s precondition matches the current state of the world, then the production is said to be triggered. If a production’s action is executed, it is said to have fired.”
“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
“You did a wonderful job!! The material was organized and valuable.”