When my older son graduated from college, he worked as an intern for a professional sports team. At the end of his very first day of work he called me, puzzled.“I asked them what my responsibilities were,” he related, “and they said, ‘We need you to know what we are supposed to be doing’.”After a long pause he went on, “I wanted to ask them why they didn’t already know what they were supposed to be doing, but I didn’t think that would be such a great idea my very first day there.”Let’s see whether at some level that situation sounds familiar to you. It turns out his area of responsibility had to do with ensuring operational compliance with corporate sponsorship agreements.The sponsorships are quite expensive.You might think these agreements would be relatively simple, but of course, there’s no such thing as a truly simple business.A sponsorship contract:
Outlines a complex configuration of promotional and other benefits, some automatable and some not, all usually tailored specifically for the individual sponsor.
Is loaded with obligations, decision criteria, and computation formula (read ‘business rules’) to govern the sponsorship relationship.
Is amended frequently, both formally and informally (via hand-shake), owing to the dynamic nature of the sponsors’ marketing needs.
To continue the story of my son’s first day, they gave him a stack of contracts and amendments, operational schedules, and invoices and told him to see if they all matched. Of course they didn’t.Not by a mile.By the end of the first week, my son had become fairly fluent in the organization’s governance problems. (Ah, young minds!)The contracts and schedules were all produced by different people at different times.Some of the schedules were hand-done and some automated.But even the ones that were automated often didn’t match the contracts.The invoices were automated, but in many cases they too bore little resemblance to the contracts.The IT people were not much help either. “They seem to speak a different language,” my son reported naively.Bottom line:A number of the sponsors were becoming quite annoyed — not a good thing for a mediocre team in a mid-sized market.But there was still more. The sales reps were, shall we say, quite creative in what they offered the sponsors.Their terminology, which often found its way into the contracts, was highly idiosyncratic.Yet they were talking about the same shared resources (e.g., banner boards in the stadium) that had to be coordinated real-time across many sponsors.They seemed oblivious to some of the company’s rules — even though some, quite literally, were dictated by physics (e.g., a banner board can only say one thing at a time; there is only so much time during a game, etc.). By the way, my son went to one of the team’s games his first week at work. The team lost.Attendance was poor.Sponsors were unhappy.“I think it’s going to be a season,” he said.After a moment of reflection he added, “You know what really worries me is that I am going to figure all this out, then walk right out the door with all that knowledge. They’ll be right back where they started.Doesn’t seem to me like a very good way to run a business.”Welcome, my son, to the reality of business rule mismanagement in the 21st century!
What business problems do business rules address? My take: 1. Ad hoc rules: Most businesses have no organized approach for specifying their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike.
Business rule solution: Business rules ensure consistency in customer experience and provably on-target results for demonstrating compliance.
2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?
Business rule solution: A structured business vocabulary provides a foundation on which rules can be directly based.
3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.
Business rule solution: An organized approach for managing business rules yields order-of-magnitude improvements in productivity and business agility.
4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners across multiple jurisdictions for ever more complex products or services. How can businesses massively differentiate and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?
Business rule solution: Business rules support highly scalable customization and personalization and provide a structural solution for managing complexity.
5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the digital age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?
Business rule solution: Real-time delivery of business rules to knowledge workers creates a seamless, never-ending, self-training environment.
6. Knowledge walking out the door: By and large, baby boomers created much of the basic operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads – and nowhere else. Now they are retiring. On a smaller scale, people with vital operational knowledge walk out the door almost every day.
Business rule solution: A systematic way of capturing, documenting and managing business rules enables pragmatic knowledge retention.
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.
A Practitioner Wrote:The distinction between activities and business rules becomes very fuzzy when models grow very granular/detailed. Suppose I have a process called “Handle customer inquiries”, and an activity called “Close inquiry”, which has several small sub-steps, one of which is a “Send customer confirmation of solution by email”. Is that sub-step a rule or an activity?My Answer: No fuzziness whatsoever. Processes – including activities to any level of granularity – always involve a transform. True business rules never do. So ‘Send customer confirmation of solution by email’ is a process (activity step). I can tell because its name starts with the verb ‘send’ in the command form.Suppose the following had been written instead: “A customer must be sent a confirmation by email when a solution is found.” That’s a business rule. It would apply to any process (activity) anywhere, anytime, even if such process(es) are not modeled. The business rule could be violated, of course, but it would not do (transform) anything. It would exist to ensure consistency (of behavior) everywhere – and not incidentally, a good customer experience.Note I said true business rule. Rule technologies confuse the matter because sometimes their rules do do (i.e., do transform) things. That’s simply a highly unproductive mis-positioning of business rules.
Sample behavioral business rule:A customer that has placed an order must have an assigned agent. A practitioner wrote: In process design this means that an activity ‘Assign agent’ must happen before an activity ‘Take order’.My analysis: Here’s how behavioral business rules like this one should work according to standards:
If the business rule is violated in performance of the process ‘Take order’, then the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
In performance of the process ‘Retire agent’ (which hasn’t been mentioned!), if the business rule is violated – i.e., the retiring agent is assigned to some customer who would thereby be left agent-less – the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
There’s one business rule, but two kinds of events (in separate processes) where the rule can be violated. I’ve literally looked at 10,000s of business rules. Probably 95% or more are multi-event like this, and therefore often multi-process. You can see from this example how easy it is for business analysts to completely miss the second event. My contention is that’s one big reason why systems today often give such inconsistent results – the other event(s) are overlooked or in another process altogether. Conclusions
It’s highly misleading to say ‘business rules are part of processes’. No, not really. (I run into that statement all the time.)
We’re not designing processes today in a very intelligent way. Designers shouldn’t have to think, ‘O.K., which process (activity) has to come first because of the business rules?’. That approach forces us into sequences where no natural sequence is meaningful. In any case there are far too many behavioral business rules for it to be practical.
P.S. If you think ‘decisions’ will fix this fundamental problem, sorry, but I’m afraid you’re in for a rude awakening!~~~~~~~~~~~~~~~~~~~~www.BRSolutions.com
Semantics of Business Vocabulary and Business Rules (SBVR).
How does legality work with business rules?To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved?Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal.SBVR does not have an innate concept/approach for “legality” in the sense of MWUD 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.)1. Specify a behavioral ruleA behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:
The people united in a marriage must not be of the same gender.
Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline.The rule would be active when a relevant state of affairs arose (i.e., specific people get married).2. Define several definitional rulesA definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:
The people united in a marriage are not to be of the same gender.
The people united in a same-sex marriage are to be of the same gender.
See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand.
3. Define the relevant definitions
Marriage: the uniting of people of different genders in wedlock
Same-Sex Marriage: the uniting of people of the same gender in wedlock
Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand.Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both.~~~~~~~~~www.BRSolutions.com
Semantics of Business Vocabulary and Business Rules
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.
BPM often overreaches. Understanding, modeling and managing a business capability effectively requires a balanced view of six basic questions, not just one, as given in the table below. I follow Zachman in these matters, so yes, the table is Zachmanesque.
Basic Business Question
Kind of Model
What inventory of things needs to be managed to support business activity?
structural model (e.g., concept model, data model)
How do transforms of things in business activity need to take place to add value?
Where does business activity occur?
Who collaborates with whom to undertake business activity?
interaction model (e.g., organizational chart, use case)
When does business activity take place?
temporal model (e.g., schedule, event model, milestone model)
Why are results of business activity deemed appropriate or not?
strategy model (e.g., Policy Charter, constraint model)
If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM.
That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:
Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.
Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:
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.
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.
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“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
“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.”