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.
“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.
Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015
Software vendors and others mislead people (badly) about the true meaning of business rule. Let’s set the record straight.
The OMG standard SBVR (Semantics of Business Vocabulary and Business Rules, 1.4) defines business rule as a rule that is practicable and is under business jurisdiction. The definition has these three parts: (1) rule, (2) practicable, and (3) under business jurisdiction. Let’s look at each part in turn.
1. RuleRule in business rule means real-world rule – in other words exactly what the dictionary says rule means. Here are the relevant meanings of rule from Merriam-Webster Unabridged Dictionary [MWUD].
guide for conduct or action [MWUD ‘rule’ 1a]
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 ‘rule’ 1f]
A real-world rule always tends to remove a degree of freedom. If it does not, it’s not a rule.
Also, a real-world rule is declarative. It never does anything. It merely shapes behavior or decisions.
If you’re using an approach where rules can actually do things (e.g., execute an action, set a flag or variable, call a function, etc.), they’re not business rules. You’re in TechnologyLand, and a procedural one at that.
2. Under Business JurisdictionBusiness rule includes only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization.
The important 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.
“… legislation and regulations may be imposed on [the company]; 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.”
I want to share with you the most intelligent thing I’ve ever heard a manager say on the fly. I’ll give some background first. In one way or another, the situation that evoked what she said may seem quite familiar to you.A few years ago Gladys and I were invited to conduct a one-week facilitated session for a national taxation authority. The objective was to reverse-engineer business rules from a very complex spreadsheet. The manager told us everyone was deathly afraid to touch it because no one understood how it worked. You could never tell what impact making a change would have. Used by many of their systems and embedded in various websites, the spreadsheet was mission-critical. She was finally biting the bullet and assembling some of her best staff to re-engineer it.Everyone knew the spreadsheet by its nickname, Al’s Spreadsheet. It dated to the 1970s when it was implemented under the first generation of automated spreadsheets. Notorious in the organization for more than a generation, it was devilishly convoluted. One of these days I might hold a contest for the world’s most complex spreadsheet. I’ve actually told this story many times around the world, and the audiences’ reaction is inevitably the same – perhaps the same as yours reading this. “No, Al’s Spreadsheet couldn’t possibly be the world’s most complex spreadsheet because my company has the world’s worst!” Around the globe there is extensive core operational business knowledge running businesses day-to-day that is highly inaccessible. Just putting your fingers on it, much less revising it, consumes vast amounts of vital resources. We live in a service provider’s dreamscape. It makes you wonder how brittle (read not agile) many companies’ operations really are today. To return to the story, by mid-week we’d achieved only limited success in deciphering the spreadsheet. Progress was painfully slow. Lapsing momentarily into frustration, an idea popped into my head. I blurted out, “Hey, why don’t we just go ask Al what this thing really does?!”I assure you my intention was not to provide comic relief. To my chagrin that’s exactly what happened. The whole room erupted into laughter. When the hysteria finally subsided, someone patiently explained to me (barely keeping a straight face) that nobody actually knew who Al was – or indeed, whether Al had actually ever even existed. If so he had long since parted ways with the organization, fading away as all workers sooner or later do into the mists of time.That’s when the manager said the thing that I found so memorable. Looking at no one in particular and staring vaguely into the far distance she said, “No organization should ever depend on absent brains.”.Exactly! To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand.Operational business knowledge can be either tacit or explicit (read ‘accessible’). The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’. You make operational business knowledge explicit by expressing it as business rules. So make sure when you lose your Al, he doesn’t walk out the door with the day-to-day knowledge you need to run your business. Encode it as business rules!
Consolidation is not the same thing as integration. What does it really take to integrate business practices? Let me illustrate with a thought experiment.
Imagine that the U.S., Canada, Cuba, Jamaica, and Japan were completely closed societies. However, to invigorate their sports, each allows one visitor for one day each century to bring a new game idea.
For the 1800s, baseball is chosen. Abner Doubleday arrives in each country, and talks about bases, runs, strikes, balls, innings, and all the other things of baseball. At the end of the day he leaves. Nobody knows what happens until the next visit, a hundred years later.
As it turns out, each country has embraced the game enthusiastically, and each now has a century of competitive results.
So taken are the countries with the game, they express a desire to merge their results, and to begin an international league. A commission is chartered for that purpose and hires business architects.
The initial results are promising. Each country uses the same nouns (i.e., bases, runs, strikes, batters, etc.), and many of the same verbs (e.g., “run is scored in inning”). A data model emerges that meets general approval.
Then the trouble begins. Not surprisingly, substantial differences have arisen over a hundred years in how each country plays the game.
In Japan, a batter loses so much face after one strike (not a foul ball) he is immediately retired.
In Canada (being a tolerant country), an unlimited number of strikes per at-bat is permitted but, to compensate, only two outs per inning.
In Cuba (being a socialist country), strikes are charged to the pitcher, rather than to the batter.
In Jamaica (suffering from earlier British influence), only two bases are used, the ball is bowled, ‘pitch’ refers to the playing field, and games may continue for two days.
Can the results be merged? Yes and no. Because they are based on the same words, they can be consolidated (lumped together). However, because each country plays the game differently, they cannot be integrated (compiled meaningfully).
What does it take to achieve true integration of business practices? Without common standards for how the game is played, integration is impossible. To play ball you need business rules and a shared rulebook.
Make no mistake, the future lies with automation of white-collar work. Fewer and fewer business problems these days focus on manufacturing and production processes, i.e., the nothing-but-widgets category. For all the non-widget-centric business activity in the world – which includes just about all every conceivable form of white-collar work – the following needs become paramount.
Ensuring the quality of meta-data.
Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
Retaining, teaching and repurposing intellectual capital.
What would I do to correct the shortcomings of BPM for non-widget-centric business activity? Our answer is to become more why-centric, as opposed to narrowly how-centric. You should focus on business capabilities, not just business processes. That shift has several essential features:
Understanding business strategy as something distinct from business processes (and BPM). Business goals and business risks should be drivers of business process design – not the other way around. You need to be strategy-driven, not simply process-driven.
Designing core metrics around business goals and business risks – the things that concern C-suite executives the most.
Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.
Treating business rules as a first-class citizen, externalized from process models.
Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.
Including a Why Button as part of every business solution. Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.
People are asking why current processes are so dumb. For example, why can’t they:
learn from experience?
be more goal-driven?
dynamically balance between conflicting goals?
Some people suggest use of cognitive computing to help make processes smarter. I doubt anybody today really knows how far this idea can be taken. I can, however, say two things with certainty:
If you don’t know what your business rules are (i.e., what rules guided previous executions), can you really expect a machine to figure them out? A machine can undoubtedly identify patterns, but that’s a far cry from demonstrating compliance, guaranteeing consistent results, or customizing appropriately case-by-case.
Suppose self-adapting processes do become reality. The question I have is what will keep such processes from going out of bounds? How do you avoid them doing things that are undesirable, self-defeating or even illegal? These are critical questions that will always bring you right back to business rules.
Quality must be viewed very differently in the white-collar world. The traditional view simply doesn’t fit.
In Henry Ford’s day, for example, central to the concept of mass production was standardization of parts. That idea leads directly to the notion of manufacturing tolerances – i.e., upper and lower limits for parts in 3-dimensional space. The goal is to ensure physical interchangeability of physical parts. That idea is now standard practice, of course, across manufacturing and production sectors.
But what are the ‘parts’ in white-collar work? White-collar processes simply don’t deal with physical things. How can you identify tolerances for them in 3-dimensional space? You can’t! In a very real sense, the ‘parts’ in white-collar work are literally just bits and bytes.
If not tolerances as a basis for quality, then what’s the proper focus? My answer: consistency and reliability of results.
For example, if I visit ten different branches of the same bank about getting a mortgage for my dream home, shouldn’t I get the same answer on my application from all 10 branches?! As you perhaps have experienced yourself, that’s not the way it works in many banks today. So one aspect of quality in white-collar work is the consistency and reliability of operational business decisions.
Another aspect of quality concerns compliance. Every business is subject to ever growing numbers of (take a deep breath here) … acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, prospectuses, citations, certifications, receipts, legal notices … and the list goes on.
Shouldn’t I expect consistency and reliability of results with respect to all those obligations and commitments? I believe we should. If it’s not about quality, then what?!My conclusion:When there isn’t any physical product from a business process, quality and defects must be measured by consistency and reliability of results, which are in turn always purely a matter of business rules.
For background on this post, see: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/
Everyone wants high quality from their business processes. But what exactly does quality mean these days? Let me tell you a quick story that recently got me thinking.
I like to eat toasted raisin bread in the morning. I even have a favorite brand. Every morning when I’m at home I eat several pieces. Over the years I’ve become so experienced with the brand’s quality that I can spot defects. I know when they’ve laid on the cinnamon a little too heavily, or when the dough didn’t rise quite enough. Every morning I look forward to doing my little AM taste test.
But one morning recently I suddenly realized the large majority of client processes we’ve worked with over the last decade are not ones I can perform any taste test for. There’s nothing physical from the process I can taste or hear or touch. There’s nothing whatsoever to directly assess quality by.
That’s because some clients simply have no physical products at all – e.g., insurance, finance, taxation, etc. But a good number do – e.g., electrical equipment, trucking, railroads, and so on. For these latter clients the processes of immediate concern didn’t directly involve those physical things however – only just white-collar stuff.
So the question becomes how do you assess quality from a business process when there’s no physical product? How do you identify defects when there isn’t any physical result?
My conclusion:When there isn’t any physical product from a business process,quality and defects are purely a matter of business rules.
If you’re not documenting and managing business rules as part of your BPM or quality management approach (or elsewhere) you’re missing a crucial part of the picture.
I wouldn’t go so far as to say that process and BPM are meaningless across the board in the digital economy. If you’re manufacturing or producing a physical product, you still do need to think in terms of a modeled and managed business process.
Other the other hand, if your products are non-physical – for example, money, time, skills, information, meta-data, etc. – you’d better have a major re-think. The old rules of the game simply don’t apply to white-collar work. Nor do they apply if your business model is about digitally leveraging other people’s idle assets – think Uber.
You must still consistently satisfy contractual obligations and regulatory constraints in this new digital world of course. But that’s a business rules problem, not a process problem.
A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:
Continuously make informed operational decisions in the blink of an eye (actually often faster than that).
Selectively respond to changing circumstances with subtle adjustments.
Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.
These too are business rule problems, not process problems.
“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
“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!”