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 expert systems’

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

A Quick Review of What “Rule”, “Business Rule” and “Business Policy” Mean (in the Real World!)

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, October, 2011, 304 pp, http://www.brsolutions.com/bbs You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf

   Reference Sources

[BMM] The Business Motivation Model (BMM) ~ Business Governance in a Volatile World.  [May 2010].  Originally published Nov. 2000.  Now an adopted standard of the Object Management Group (OMG). 
[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.
  rule:    [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

              Note:  When we say rule we always mean real-world rule. business rule:  [SBVR]:  a rule that is under business jurisdiction

Discussion:  A business rule is a criterion used to guide day-to-day business activity, shape operational business judgments, or make operational business decisions. 

Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  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.

Each business rule gives well-formed, practicable guidance.  Each uses terms and wordings about operational business things that should based on a structured business vocabulary (concept model, also called fact model).  Each expression is declarative, rather than procedural.  Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.

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.  Except for eCommerce, 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.”

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. 

SBVR provides the semantics for business rules.  In SBVR a business rule can be either a behavioral rule or a definitional rule.  Incidentally, SBVR does not standardize notation.  We use RuleSpeak to express business rules (including ‘exceptions’) in structured natural language.  

In SBVR, a real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule, but rather an advice.  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. 

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.

business policy:  a means that limits or establishes a degree of freedom for day-to-day business activity

Discussion:  Business managers create business policiesto control, guide, and shape day-to-day business activity.  Business policies are an important element of business strategy (e.g., Policy Charters) and the source of core business rules.

A business policy is not a business rule per se.  To become some business rule(s) first the business policy must be interpreted into a practicable form.  The Business Motivation Model [BMM] contrasts business policies and business rules this way:

“Compared to a business rule, a business policy tends to be less structured, less discrete, less atomic, less compliant with standard business vocabulary, and less formally articulated.” 

In general, business policies can address any of the concerns in Table 1, often in combinations (e.g., how many people are needed to produce a desired yield in the desired cycle time).  Business policies can also address exceptions (rules).

 Table 1.  Concerns that Business Policies Can Address
Question Word General Focus of Concern More Selective Examples
  What what things should (or should not) be available required kinds, quantities, states, or configurations
  How how things should (or should not) be done required outputs or yields
  Where where things that should (or should not) be done required facilities, locations, or transfer rates
  Who who should (or should not) do things required responsibilities, interactions, or work products
  When when things should (or should not) be done required scheduling or cycle times
  Why why certain choices should (or should not) be made required priorities
           

Continue Reading 6 Comments

The Debate Continues: Expert Systems vs. Business Rules … Yet Another Response

guest post by Jan Purchase, Director of Lux Magi Ltd ~~~~~~~~~~~~~~~~~~~~~ I do see value in distinguishing ‘policy’ rules from ‘expert’ rules. It’s also clear that, at their extremes, these rule types are poles apart. Still I fear that this distinction may be a continuum rather than a discrete dichotomy. Policy rules might be exemplified as the constraints of business operational practice – the rules that dictate what a company should and should not do. They might be mined from the boundary conditions of the fact model of the company’s business capability – as you suggest in your excellent book on this subject[1]. An example policy rule might assert, for example, “A company agent may be assigned to a high-value customer only if the agent is assigned to at most five other clients”. Expert rules, on the other hand, are often seen as more complex – for example, using heuristics to determine the best, anti-cancer drug to apply in a given situation, or forecasting regional sales opportunities. Often these expert rule bases use expert experience, genetic algorithms, fuzzy logic and feedback loops to reach a decision. They seek to augment, or even supplant, the wisdom of a small population of subject matter experts. But isn’t there a middle ground too? Consider an insurance policy decision rule that bin-sorts clients into good, bad and medium risk (the latter to be referred to a human underwriting expert). If this were a simple four-row, decision table based on the value of the policy and the risk profile of a client, you would probably consider it a ‘policy rule’. But if I add scorecarding, heuristics and analytics, at what point does it become an ‘expert rule’? Would you consider all decision rules (as opposed to constraint rules) to be ‘expert rules’? Or do they need to be complex or directly represent the experience of SMEs? Don’t all rules, to some extent, represent the wisdom of experts? Don’t many of them constitute and inform policy? In short: Is there a simple question we can ask (concerning a rule) to determine if it is a ‘policy’ or ‘expert’ rule? ~~~~~~~~~~~~~~~~~~~~~~~~ See my reply to Jan: http://www.brsolutions.com/2012/05/29/the-debate-continues-expert-systems-vs-business-rules/ Answer to Jan’s Question: The question to ask of every rule is whether the end-point is enforcement or is it a decision. An enforcement rule never becomes a decision rule, and a decision rule never becomes an enforcement rule. Once an enforcement rule, always an enforcement rule (assuming you don’t retire it). You can adjust thresholds (e.g., the mph of the speed limit), you can change the enforcement level (e.g., from ‘strictly enforced’ to ‘override with explanation’), you can change the sanctions (or eliminate them), etc., etc. And you can and should use analytics to measure and improve the rate of success in achieving underlying business goals. But it’s black and white. Enforcement is enforcement and decisions are decisions.

Continue Reading

The Debate Continues: Expert Systems vs. Business Rules

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).

Continue Reading 4 Comments

Additional Response to: Business Rules vs. Expert Systems – Same or Different?

guest post by Ryan Trollip, Practice Director, Decision Management – www.prolifics.com ‘Expert system’ covers a pretty broad swath. Rules engines in the business world, in practicality, and in the majority of implementations, are simply operationalizing decisions, whether derived by predictive modeling or prescriptive business rules (e.g., regulatory). The conditions that reach a decision are largely pre-determined and operationalized in the rules system. Yes, there is a RETE algorithm involved. But don’t be fooled, this doesn’t give it intelligence, it is simply a style of execution. You can argue that in some implementations, sequential (non-forward chaining) is sufficient. In the real world, the management tools for rules systems, in my opinion, are more important than the algorithm. They have become the focus to externalize rules and allow for rapid change. I wouldn’t call a business rules system an expert system although you could probably create one with the tools out there. It’s simply a specialization much like how DBMS came about to better handle data. Not as sexy as AI, imperfect reasoning, etc., but certainly useful and practical.

Continue Reading

Response to: Business Rules vs. Expert Systems: Same or Different?

guest post by Hafedh Mili, Professor of Computer Science at University of Quebec Montreal and Computer Software Consultant I agree that expert systems and business rules tackle different problems. Expert systems tackle two problems:

(1)   Difficult problems with no exact solutions – requiring heuristic knowledge.

(2)   Scarcity of expertise.

Hence, their first applications tackled complex engineering (and medical problems). Business rules tackle different challenges with respect to common business knowledge:

(1)   Externalization (explicitation).

(2)   Uniformization.

(Yes, I did just make up some new words.) There was no algorithmic/procedural INTERNIST that preceded the expert system INTERNIST. In contrast, plenty of business information systems implement business rules today – just not in the proper, agile way. So why did expert systems fail? Actually, did they fail? Was it a technical/scientific problem, or a business (model) problem? One could argue that expert/knowledge-based systems failed to solve the fairly challenging technological-economic problem of building true expert systems in a cost-effective way. What the science has been able to build is idiot-savants – i.e., systems that manipulated symbols and churned out ‘decisions’ without ‘understanding’ what they were manipulating. When INTERNIST is told about an old Chevy that overheats and has brown/reddish spots on its body, it comes up with MEASLES as a diagnosis. To make such systems less brittle, they need common sense. Doug Lenat (instigator of the CYC project) wittingly characterizes such common sense as “the things you need to know that enable you to disbelieve every word you read in ‘the News of the World’ (i.e., tabloids)”. Building such a common-sense knowledge base is not only costly, but epistemologically (and from an engineering point of view) a far more difficult problem than, say, codifying the debt-over-income requirements for applicants seeking multi-borrower mortgage loans. So, business rules vs. expert systems? Same mechanics (rules and rule engines), but significantly different problems. ~~~~~~~~~~~~~~~~~~ My reply: Hafedh, Great response. Not sure about the ‘same mechanics’ though. But that’s a post for another time.

Continue Reading

Follow-Up on ‘Harvesting Business Rules’: Business Rules vs. Expert Systems

The guest post by Cecilia Pearce earlier this week (http://goo.gl/QL9zL) stirred up an unexpected controversy, one that deserves clarification – are business rules and expert systems the same? No!  Business Rules  Business rules are organizational rules created for the purpose of running day-to-day business operations. Business rules always have an original source in the form of some law, act, statute, regulation, contract, agreement, business deal, business policy, license, certification, service level agreement, etc. I often like to say that business rules are really about keeping commitments. Expert Rules  In response to Cecilia’s post, Rolando Hernandez explains:

 “If you need to go beyond gathering [i.e., harvesting or mining] business rules to trying to understand “The Knowledge” [sic] that experts know, how experts think and decide, what the expert rules are, or what the higher-level heuristic rules are, then knowledge engineers … will keep using “knowledge acquisition” (KA), “knowledge representation” (KR), and “knowledge engineering” (KE). AI guys know that means.”

In other words, expert rules arise from an individual who is outstanding at his particular knowledge task. That’s very different. Expert Systems  Wikipedia describes expert systems as follows: 

 software that uses a knowledge base of human expertise for problem solving, or to clarify uncertainties where normally one or more human experts would need to be consulted … a traditional application and/or subfield of artificial intelligence (AI)”

Bob Whyte, a practitioner for a major insurance company, makes the following observation about the difference between business rules and expert systems[1]:

“What makes the real-world challenge of managing business rules so much more tractable than it appeared to academics and researchers in the1980s, the heyday of knowledge engineering and expert systems, is that in the day-to-day business world the institution plays role of ‘god’. 

… for business rules the problem is not one of having to discover and define hidden, unknown or unexpressed rules, which takes you into byzantine solution spaces, but rather one of documenting known rules invented overtly and explicitly by actual historical person(s). 

With business rules you are generally not discovering rules no one has ever consciously considered, but rather uncovering rules that some manager, lawyer or other expert decided on one day, but probably did not record simply for lack of an appropriate infrastructure for rulebook management.”

Excellent clarification!
[1] from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, 2011, pp. 257-258http://www.brsolutions.com/bbs 

Continue Reading

Business Rules and Expert Systems/AI … Friends or Foes?

There are very important differences in the traditions of business rules vs. expert systems. Perhaps that’s why business rules had a completely different origin. In any case, they didn’t start finding each other until the late 1990s. (The first Business Rules Forum Conference was in 1997 … and every year since except in 2000.) The general goal of expert systems was broadly to mimic intelligent behavior – any kind of intelligent behavior. As a colleague put it, that’s like trying to read the mind of God. Human behavior (even the not-so-intelligent kind) is exceeding complex. The goal of business rules was always to capture the rules of organizations, not individuals. That’s one or two or more orders of magnitude easier – those rules have to come from somewhere … and that ‘somewhere’ was originally knowable (even if an arbitrary design decision by some programmer). So the issue with business rules is as much about business traceability (rule management) as it is expression. This problem goes right to the very heart of business governance and business agility. Continuing to embed business rules in procedural code (a) makes the business rules very difficult to trace, and (b) very difficult and expensive to change. It’s like setting the rules in concrete. It also precludes the possibility in the future of supporting specification-time detection of anomalies and intelligent dialogs to help Business Analysts remove ambiguity. For business rules, it ultimately comes down to the words you use and ‘remembering’ the interpretations made of them. There’s no way to demonstrate compliance without words, and no way to support transparency and accountability without traceability. The solution to all these problems, which are problems of business governance and therefore business engineering, leads inevitably in one direction. That’s why I’ve put so much time into researching business rules since the early 1990s and before. (Originally we thought in terms of databases and integrity constraints, another difference in origin from expert systems.) It’s also why I’ve spent so much time on the SBVR standard over the past 6 years or more. (At the risk of oversimplifying hugely, SBVR is about words and sentences.) The bottom-line: The way we do things today simply has to change. Change does take time. It also takes false starts and trial-and-error. But we’ll get there. Hey, business automation is barely one human generation old. That’s incredibly fast in the big scheme of things. ~~~~~~~~~~~~~~~  Read more about the history of business rules: http://www.brcommunity.com/history.php    

Continue Reading