Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Many or most IT methodologies remain essentially in the Dark Ages with respect to knowledge management. They seem to focus blindly on pumping out code faster and faster. We may be living in a knowledge economy, but we’re sure not acting like it. When I say knowledge management I don’t mean what probably comes to mind. I’m not talking about fuzzy text in vast e-mail archives or tacit knowledge in people’s heads. I’m talking about explicit business rules. Business rules (done correctly) represent knowledge – core operational knowledge. Many companies today are in peril of losing or outsourcing that knowledge. Who’s to blame? Business managers for not ‘getting it’ of course. But that’s just where the buck stops. Ultimately practitioners are to blame. They’re not making core operational knowledge tangible to their managers. How you make that kind of knowledge ‘real’? True business-side rulebook management[1] (which is not the kind BRMS offer).[2] That’s no longer optional either. In a knowledge economy your company simply can’t afford to lose its business rules! ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

If you examine process thinking, you find it is deeply rooted in 20^th century blue-collar manufacturing/production processes, starting with Federick W. Taylor (pig iron), Henry Ford (autos), Toyota Production System (autos), Six Sigma (Motorola and General Electric), Lean, and offshoots. In every case, the focus is on tangible products. But what if your products are intangible? You’d be excused for thinking that the carry-over from the manufacturing/production world is not all that it should be. To those who dissent, I say prove me wrong. In the 21^st century, processes of interest are increasingly white-collar and knowledge-intensive. There’s a product, of course, but it generally has more to do with some transition in the state of a significant resource (not infrequently money) than the assembly of something new from physical parts. Rather than efficiency, machines and inventory, their operational focus is consistency, compliance and decisions.  Typical examples include …

• Finance: Accepting and funding a mortgage.
• Insurance: Extending coverages and adjudicating resulting claims.
• Taxation:  Evaluating financial records and assessing taxes.

I call such processes commitment/dispersal processes. (See basis definitions below.) Commitment/dispersal processes are always about:

• Making commitments and managing dispersals of resources (money, time, people, etc.).
• Satisfying obligations (often contractual or regulatory), making informed decisions, and responding continuously to changed circumstances.

For such processes you must know what the rules are; otherwise, you cannot identify appropriate inputs. In short, such processes take you directly to best practices for business rules and decision engineering as a basis for process renewal and innovation. What’s in between manufacturing/production processes and commitment/dispersal processes? I suspect there’s a wide spectrum of processes – and that many of them are often not much like manufacturing/production processes either. ~~~~~~~ Basis definitions from Merriam-Webster Unabridged Dictionary … [commitment]  3a(2): an engagement by contract or purchase order to assume a financial obligation (as to accept goods at an agreed price, to pay for subscribed stock, or to make a mortgage loan upon the completion of a building) [disperse]  2a: to spread abroad from a center of supply or control : DISSEMINATE ~~~~~~~ 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. http://www.brsolutions.com/

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.

We’ve got a long way to go to become true business engineers – what we call Why Engineers. What’s a ‘Why Engineer’? Have a quick read of http://www.brcommunity.com/b727.php www.BRSolutions.com

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!

Reference Sources
[MWUD]	Merriam-Webster Unabridged Dictionary (Version 2.5).  [2000].  Merriam-Webster Inc.
[SBVR]	Semantics of Business Vocabulary and Business Rules (SBVR) (Version 1.0).  [January 2008].  Object Management Group.

  1. Rule When 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 Jurisdiction    When 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

A colleague and I were recently discussing business rules. In the course of conversation he used this example: A customer may have only one address. Hold on! That’s not a business rule. Rather, it’s a design decision (probably a poor one) some IT person made in creating a system model. The business wouldn’t (and couldn’t!) make a real-world business rule about customers having only one address. But a design decision might be made to record only one (in a system). Eventually we agreed the desired business rule probably was: A customer may have only one preferred address.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from Building Business Solutions: Business Analysis with Business Rules (2011). See:  http://www.brsolutions.com/b_building_business_solutions.php

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

We are already living in a knowledge economy – let’s start acting like it! It’s know-how (business rules) that makes your company smart. Let’s get to the point of that knowledge.  

1. All know-how expressed in business terms – no ITSpeak.
2. All know-how presented/applied selectively in exactly-as-needed fashion.
3. All know-how presented/applied in ‘just-in-time’ fashion.
4. All interactions gauged to the knowledge level of the role and the person.
5. All workers enabled to ‘play up’ to level of ablest workers.
6. All decisions made 100% consistently – no exceptions (except intentionally).
7. All applications of business rules traceable and transparent.
8. All know-how managed directly – by business people and business analysts.

~~~~~~~~ Adapted from: Business Rule Concepts: Getting to the Point of Knowledge (4th ed.), 2013.  http://www.brsolutions.com/b_concepts.php

Rhetorical question? Well maybe, but I’ll answer it anyway. A data model is a tool to organize what a company knows about the world so it can remember it in a systematic way. So yes, that’s like DNA. (I think ‘concept model’ is more accurate than ‘data model’, but let’s leave that discussion for another day.) But DNA does more. It encodes the rules to guide the processes to sustain and reproduce life. For a business, those would be its business rules. That’s the part many people miss. By the way, DNA encodes the building-block concepts and rules in a declarative, not procedural, way … just as data models and business rules should be represented.