Can you understand that all three of the following business rule statements mean the same thing? Here’s what must be true: If you mow the lawn on Sunday your lawn mower is to be electric; otherwise the lawn is not to be mowed on Sunday.
1. It is permitted that the lawn be mowed on Sunday only if the lawn mower is electric.
2. It is prohibited that the lawn is mowed on Sunday if the lawn mower is not electric.
3. It is obligatory that the lawn not be mowed on Sunday if the lawn mower is not electric.
I’m fairly certain you can. And if you can determine they all mean the same thing, I contend a machine ought to be able to do so too. I mean as stated in this exact same human-friendly, structured natural language form. And tell you that the statements mean the same thing (in effect, that they are redundant). That’s the kind of language-smart (cognitive) capability that business innovators should be expecting – no, demanding – from software vendors.
The standard Semantics of Business Vocabulary and Business Rules (SBVR) offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable, which I discussed in my previous post. See: http://www.brsolutions.com/2015/06/29/practicable-insight-for-expressing-business-rules-well/The second of these insights is the principle of wholeness. The descriptive text below is taken directly from SBVR itself.Wholeness essentially means each business rule statement can be taken as fully trustworthy even in isolation from all other rules. The principle precludes priority schemes and rules that disable other rules, both of which can act to make any given rule less than fully trustworthy.~~~~~~~~~~~~~~~~~~~Principle: An element of guidance means only exactly what it says, so it must say everything it means.
Explanation: Each element of guidance must be self-contained; that is, no need to appeal to any other element(s) of guidance should ever arise in understanding the full meaning of a given element of guidance.
The full impact of an element of guidance for a body of shared guidance, of course, cannot be understood in isolation. For example, an element of guidance might be in conflict with another element of guidance, or act as an authorization in the body of shared guidance. The Wholeness Principle simply means that if a body of shared guidance is deemed free of conflicts, then with respect to guidance, the full meaning of each element of guidance does not require examination of any other element of guidance. In other words, each element of guidance can be taken at face value for whatever it says.
The standard Semantics of Business Vocabulary and Business Rules (SBVR) offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable. The descriptive text below is taken directly from SBVR itself.Practicable essentially means all ambiguity has been resolved. As a result, a practicable business rule can be given either to workers to apply ‘manually’, or to IT to implement under some platform, and the results will be exactly the same either way (barring human error or malfeasance).~~~~~~~~~~~~~~~~~~~~~~~~~~Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is understood
Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [Oxford Dictionary of English] Notes:
The sense intended is: “It’s actually something you can put to use or apply.”
The behavior, decision, or calculation can be that person’s own.
Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it.
For a behavioral rule, this understanding is about the behavior of people and what form compliant behavior takes.
For a definitional rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others.
A practicable business rule is also always free of any indefinite reference to people (e.g., “you,” “me”), places (e.g., “here”), and time (e.g., “now”). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to “tell” time), and (b) external clarification.
As a young database professional in the mid-1970s I grew up on metadata – data that describes and defines other data. In fact, I wrote one of the first books explaining it from a data-as-corporate-resource point of view in 1980.
Who knew that in the 21st century there would ever be such a thing as big data, more dependent on metadata (if that’s possible) than even ‘regular’ (transaction) data?! Or that the metadata of phone conversations would become a central artifact in the struggle over civil liberties?!
Back then it never much occurred to me that there could be other kinds of “meta”. Well, except maybe metaphysics. But you don’t want to go there. That’s some realm beyond physics where physics isn’t physics any more.
Anyway, I was wrong about there not being other important kinds of “meta”.
In the 1990s I learned there was such a thing as meta-rules – rules that govern rules. That led to RuleSpeak® – rules for expressing rules in structured natural language. It also more recently ledto new thinking about the engineering of governance – rules guiding the creation, approval and dissemination of business policies in an organization. (Think rulebook management as governance infrastructure.)
I’m also pretty sure there could be metaprocesses – processes that orchestrate or transform other processes. It seems to me that one goal of intelligent agents is exactly that. What else? I’m no expert on that.
What other meaningful kinds of “meta” are there? It’s fun to play with the question words where, who, and when, but I don’t think there are any real “meta’s” to those. I could be be wrong. Thoughts?
I do have one strict rule for judging when you have something truly “meta”. Here’s my rule:
Some meaningful verb(s), not a preposition, must be used in defining a “meta” thing.
Examples we’ve already discussed:
Metadata – data that describes anddefines data. (You should not say just “data about data”.)
Meta-rule – rule that governs rules. (You should not say just “rules about rules”.)
Metaprocess – process that orchestrates or transforms other processes. (You should not say just “processes about processes”.)
Where else could you look for “meta’s”? Merriam-Webster UnabridgedDictionary (MWUD) defines the kind of “meta” we’re discussing here as follows:
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
MWUD gives these examples (the verbs are mine):
metalanguage – language for discussing languages.
metatheory– theory for structuring theories.
metasystem – system for organizing systems.
In science & research literature these days you commonly read about meta-analysis. An article in The Economist recently defined meta-analysis as “a technique which uses entire studies as single data points in an overarching statistical analysis”. In other words, an analysis that analyzes other analyses.
I wonder if there is such a thing as meta-architecture – architecture for designing architectures? That’s certainly an interesting question, and I’m not certain I know the answer. Thoughts?
I do know there’s meta-vocabulary – vocabulary that enables communication about vocabularies. That’s a central feature of the OMG standard SBVR (Semantics of Business Vocabulary and Business Rules). I can tell you with great certainty that a meta-vocabulary is not the same thing as metadata – not by a long shot! I can also tell you that in a knowledge economy, meta-vocabulary will ultimately prove more important than metadata.
The Ultimate Metas
I believe there’s also such a thing as meta-knowhow – knowhow that enables the organizing of other knowhow. Unfortunately, as few business practitioners today know how important meta-knowhow is as knew how important metadata was in the mid-1970s.
That will change. And it won’t take long.
Meta-knowhow for organizing core operational business knowhow is essential not only to play in the knowledge economy, but simply to contain the costs of operating as we do today. Best practices already exist for the area. Companies are paying a huge (and unsustainable) price for not engaging with them. I will have much more to say about meta-knowhow in the near future.
The most interesting and powerful “meta” of all, however, has to be meta-idea – an idea that enables the birthing (ideation) of (other) ideas. These are the things that bootstrap whole cultures to a new level of intellectual empowerment. Examples: (the ideas of) libraries, encyclopedias and universal education.
In The Second Machine Age the authors argue convincingly that with the internet’s true coming of age we’re living the next big meta-idea right now. It’s hard to argue the point. You (the reader) are experiencing it at this very moment. After all, how likely is it that we would be conceptualizing “meta” together here if it weren’t for the internet?!
P.S. The concept “meta” is itself actually a meta-idea. Now there’s a good brain teaser if you want to play with it!
Data Dictionaries and Data Administration: Concepts and Practices for Data Resources Management, by Ronald G. Ross, AMACOM (American Management Association), New York, 1981, 454pp. The definition of metadata in the preceding sentence is straight from the glossary, pp. 432.
 I mean the Merriam-Webster’s Unabridged Dictionary definition 1b(1): something that deals with what is beyond the physical or the experiential.
 MWUD’s meaning for metaphysics is different: 3a: beyond : transcending. It lists examples as metapsychosis, metageometry, metabiological, and metempirics(meta-empirics). Let’s not go there(!). The “meta” I mean (definition 3b) is far more specific and useful, even if highly abstract.
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
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.
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
One way of looking at the Zachman Architecture Framework is that it is about asking the right questions in the right ways at the right times of the right people. The number of transformations (between the rows) is fixed … either they happen in your head or they happen via specifications to tools. Some developers have great heads, but personally I prefer the answers to be traceable, auditable, and reversible over time. BTW, the lower-level transformations could be automatable and simple … if only the higher-level specification support were powerful enough. And with machines more powerful every day, they should be.
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
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“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
“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
“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!”