Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘business rules vs system rules’

Do you see these things as business rules? Now I confess.

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

Continue Reading

What is a Business Rule?

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

Continue Reading

Is a Decision-Based Approach Sufficient for Business Rules?

Consider the following example.

Behavioral Rule: A student with a failing grade must not be an active member of a sports team.

This business rule:    
  • Is not about selecting the most appropriate sports team for a student – i.e., not about the decision, Which sport team is best for a student?.
  • Does not apply only at a single point of determination – e.g., when a student joins a team.
Instead, the business rule is meant to be enforced continuously – for example, if a student who is already active on some sports team should let his or her grades fall. What’s the business decision for when a student’s grades fall and they should be taken off a team? Be real, there’s no good answer to that question. This example is no outlier. Businesses have 1,000s of behavioral rules like this. Let’s be clear – I believe a business-decision-based approach is very powerful for decision rules. I have written much about that. And I don’t disagree that many business-rule projects have floundered due to lack of pragmatic organizing principles (e.g., “decisions”). But if you take a decision approach to behavioral business rules, either it will prove woefully incomplete with respect to integrity, or you’ll quickly start to drown in (system-level) decisions. In my opinion, an application that has to be designed and to operate to treat violations of behavioral rules as just more decisions is not a smart enough system. The detection of violation events for behavioral rules can be, and should be, completely under the covers (identified, detected and supported by a platform). Otherwise the solution won’t scale. And there will be so many decision dependencies it will steal from the very real value of a business-decision-based approach. This frankly is a sign of immaturity … or lack of imaginative leadership … or IT bias … or whatever … in some parts of the decision-model community. The detection of a violation of a behavioral rule is an event, not a decision. A business decision is a business decision; a system decision is … well … why even go there?! P.S. There are 3 specific examples and more complete discussion about this topic on http://goo.gl/NCnLi.      

Continue Reading 5 Comments

A Quick 5-Item List of What Are Not Business Rules!

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

Continue Reading