To speak plainly, most companies have no coherent strategy for integrated compliance. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent business obligations, the very essence of business rules.

What form of traceability is needed for business obligations? Traceability from governing rules to automated rules, where:

• Governing Rules include acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, citations, certifications, notices, and business policies
• Automated Rules include code tables, parameter settings, procedural code, implementation rule statements, help messages, etc.

Governing rules provide the baseline for running the business. These governing rules must be interpreted and supplemented, ultimately getting implemented in a wide array of platforms and tools.

In most companies today there is virtually no traceability for obligations between governing rules and automated rules. There’s an abyss, a big black hole, where there should be ready knowledge. Where does that leave the company?

• Companies’ corporate memory is riddled with disconnects and gaps. Going back in time, it is difficult or impossible to determine who interpreted what governing rules into what implementation components, or why they did it the way they did.
• Companies consequently are deeply dependent on hero-professionals to retain tacit knowledge. You hope they remember things correctly and thoroughly – and that they don’t leave the company.

A solution to the compliance challenge requires rethinking and reworking the traceability landscape for obligations to feature three layers of rules, not just two. The middle layer, practicable rules, is key.

practicable rule: an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies

Practicable rules are ones you can run the business by, whether or not ultimately automated. They should be expressed in structured natural language (e.g., RuleSpeak^®) based on business (not IT or data) vocabulary. Here is an example:

An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.

The acid test for whether a business rule is practicable is this:

You can give the statement either to a knowledgeable worker for use in day-to-day business operations to apply manually, or give to IT for implementation in an automated system, and get the same results either way.

Is that possible?! Absolutely!

The re-engineered landscape for compliance and traceability reveals the two distinct interpretations that need to be tracked:

1. First, governing rules are interpreted into practicable rules.
2. Second, those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute.

The key to operational excellence for compliance is committing both kinds of interpretations explicitly to automated corporate memory right as they happen.

By the way, business-side rule management does not have to be pursued at an enterprise scale. You can start out at any scale, including the project level. 

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

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. Rule Rule 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 Jurisdiction    Business 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. SBVR explains:

“… 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.”

3. Practicable Practicable means a rule is sufficiently detailed and precise that a person who knows about it can apply it effectively and consistently in relevant circumstances. In other words, the person will know what behavior is acceptable or not, or how some concept is to be understood. A practicable business rule is one ready to become a deployed business rule – i.e., applied in day-to-day business activity. Whether the guidance is to be deployed to staff or ultimately to machines is immaterial. You should get the same results either way. Business policies are generally not practicable in this sense. Business rules always are. ~~~~~~~~~~~~~~~~~~~~ Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015 Get the book:http://www.brsolutions.com/b_building_business_solutions.php Get the training: Instructor-led, online, interactive training: October 4-6, 2016 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php ©Business Rule Solutions, LLC 2016. wwwBRSolutions.com 

The standard Semantics of Business Vocabulary and Business Rules (SBVR)[1] 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.[2]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. ~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

The standard Semantics of Business Vocabulary and Business Rules (SBVR)[1] 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.[2]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.

 ~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

It’s time to come to grips with what is meant by “rule” in the context of big data. There’s much confusion out there. In a recent keynote, Rick van der Lans stated, “… big data leads to more and more interesting insights, and from there to more and more rules.” What does he mean? The funny thing is you can also call ‘insights’ rules … and some people do(!). Not me! Read on. An Example One of Rick’s examples of rules born from big data:

If 2 calls disconnect within 10 minutes, then offer a product discount.

What’s the insight and what’s the rule? Does the statement represent both? Does it express a business rule? The syntax of the statement is in if-then form. Doesn’t that imply a business rule?! No! According to the standards SBVR and the Business Motivation Model (BMM), business rules must be:

• Declarative. The statement above is not declarative because it includes the command “offer”.
• Practicable. The statement above is not practicable – not ready to roll out into prime-time business operations – because it’s ambiguous. More on that momentarily.

My analysis …

• “2 calls disconnect within 10 minutes” … That part of the statement suggests an insight: Calls on hold for 10 minutes or more are likely to disconnect.
• “offer a product discount” … That part of the statement suggests a remedy, a way to recover from a bad situation.

The motivation behind the statement might be:

We can assume people are getting frustrated at the 10 minute mark or before. If we offer a product discount, they’ll be mollified and more likely to hold on or to purchase.

What should we call the statement? It does give guidance and it does clearly have a role in strategy. However, neither the insight nor the remedy is practicable. Here are some unanswered questions that could produce ambiguity.

The insight part: Does the 10 minutes refer the wait period on each individual call? Or to any time interval during which calls are waiting?

The remedy part: How much discount? On which product(s)?

So according to the standards the statement represents a business policy, not a business rule. A corresponding business rule might be:

A caller must be offered a 15% discount off list price on any product in stock if the caller has been on hold for more than 10 minutes.

This version removes the ambiguities. It clarifies that we’re referring to:

• The wait period on an individual call.
• A 15% discount off list price.
• Any product in stock.

Only WonkNerds Beyond This point “Rule” has several meanings – one reason I try to avoid the word as much as possible. Compare the following definitions for “rule”. (All definitions from Merriam-Webster Unabridged Dictionary.)

2a(1): a statement of a fact or relationship generally found to hold good : a usually valid generalization

Let’s call this meaning rule₁. It roughly corresponds to insight … i.e., “as a rule we find that …”. It’s experiential – based on evidence.

1f: one of a set of usually official regulations by which an activity is governed

Let’s call this meaning rule₂. It roughly corresponds to the underlying sense of business rule … i.e., “It’s necessary or obligated that you must …”. It’s deliberate, based on policy. Job one in analysis of big data is to identify interesting relationships (rule₁) and then deliberately formulate business rules (rule₂) to produce outcomes desirable for your company. In other words, starting from rule₁ you want to move expeditiously to rule₂. Logicians have been on top of this distinction for a long, long. Only they speak in terms of implications, not rules. There are two kinds of implications – material and logical. Let’s repeat the discussion above using these terms. Don’t overlook the word strictly in the second definition. material implication (rule₁)

2b(1) : a logical relationship of the form symbolically rendered *if p then q* in which p and q are propositions and in which p is false or q is true or both

logical implication (rule₂)

2b(2) : a logical relationship of the form symbolically rendered *if p then strictly q* in which q is deducible from p

Let me repeat myself on job one in analysis of big data using implication:

Job one in analysis of big data is to identify material implications (rule₁) and then deliberately formulate logical implications (rule₂) to produce outcomes desirable for the company. In other words, starting from material implications (rule₁) you want to move expeditiously to logical implications (rule₂).

I use “business rule” only for a statement of the rule₂ variety, and only if that statement is both declarative and practicable. A statement has to prove itself to be a business rule – it’s only a pretender if it fails to meet the standards.

      In classifying ‘rules’ I go by the standards … Business Motivation Model (BMM): business policies vs. business rules

• Business rules are always practicable – workers can apply them directly.
• Business policies are not – they must be interpreted first.

SBVR: definitional rules (necessities) vs. behavioral rules (obligations) vs. advices (possibilities or permissions).

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).
• Advices are non-rules; they provide practicable guidance but do not remove any degree of freedom.

I would add only these observations: 

• The kinds of rules you see in decision tables are generally definitional. Since they represent only a subset of all definitional rules I call them ‘decision rules’ for convenience.
• Condition-Action or Event-Condition-Action (ECA) rules are not business rules at all. They are representations of business rules (for a class of implementation platforms).
• My smart phone can tell me in spoken English where the nearest gas station is. It’s only a matter of time before machines start ‘reading’ regulations, contracts, agreements, business policies, etc. to help people formulate (through dialog) practicable (and implementable) business rules. Can you imagine the productivity benefits?!
• Decision tables are great. Everybody should use them. But they are a lot harder to design well than you might think.
• The DMN standard can move things along significantly … if it is good, and it isn’t overhyped (which it already has been in certain quarters). I’m looking forward to it impatiently. But standardization (in equal parts a political process and a technical process) do take some time!

A Business Analyst recently said, “Business Rules themselves tend to be too unstructured to stand alone “. Au contraire! Well-expressed business rules are discrete, specific, and context-independent. Think about laws, regulations, contracts, agreements, deals, policies, etc. as common sources for business rules. Business rules are interpretations that make those things practicable. Those things can certainly stand alone. So can the interpretations. The test of ‘practicable’ (the term used in relevant standards) is ‘Can a worker who is authorized and capable know what to do or not to do as a result of reading it?’ Business rules must be well-structured to pass that test. More broadly, ‘practicable’ means ready to deploy into the business for workers to follow, or to pass over to IT as part of requirements in building systems – either way with the same results. Practicable business rules are encoded know-how of the business, vital operational IP. They are explicit, not tacit, so they can be retained, managed and re-used. Business rule management is the most practical means around for meaningful knowledge retention.

The relevant standard on the question is OMG’s Business Motivation Model (BMM). I prefer the English (not UML) version: http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf. Business policies and business rules are both ‘elements of guidance’. The difference is that business policies are not practicable, whereas business rules always are.  A business rule must be ready to deploy to the business, whether to workers or to IT (i.e., as a ‘requirement’). So business policies must be interpreted and refined to turn them into business rules. An example I often use:

Business Policy: Safety is our first concern.

Business Rule: A hard hat must be worn in a construction site.

It’s very important to retain information about these interpretations for the sake of traceability. That’s at the heart of business rule management. Business policies are an integral part of strategy. In general, we find only 2-3% of business rules trace directly back to strategy. But those *core* business rules are very, very important (to enforce and monitor). One last point: Business rules must be expressed in a form that is understandable to business workers (who are authorized and capable). What IT usually specifies or implements as ‘business rules’ aren’t. They might be rules, but not business rules. And what do I mean by “rule”? Exactly what it means in the real world – ‘guide for conduct or action’ (Merriam-Webster Unabridged).