* 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).(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.“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!