Harvesting Business Rules??guest post by Cecilia Pearce Are we actually harvesting the business rules? To harvest something you are required to go to a designated area to gather the crop or fruit. ‘Harvesting’ implies you ‘grew’ the business rules with deliberate purpose – cultivated special ground, keep it watered and weeded, watched over it as it matured. This is not what we are doing when ‘gathering’ business rules. We are required to go seek these business rules in documents, people’s heads, and programming code. We are required to sift through loads of information to find the business rules. Similar to what the prospectors did during the gold rush era in the past. I believe that ‘mining’ or ‘panning’ for business rules may be a more appropriate term to use when gathering business rules.
Tags: capturing business rules, guest post, harvesting business rules, methodology, mining business rules, panning for business rules
I try not to treat business rule discovery as a process by itself as from past experiences I have found that almost impossible to do as most clients need a familiar context in order to help facilitate them to accurately identify their business rules.
I think it is far better to harvest/mine/pan for the decisions that are to be made then backtrack to identify (or possibly still harvest/mine/pan) the business rules that are behind the decisions.
How we harvest the decisions falls more into the categories of standard requirements analysis where for example we may utilise Use Cases or Scenarios to identify functionality, identify the key decisions required to enact them and then identify the business rules required to reach these decisions.
So yes, I think I agree with your analogy that we don’t really harvest the rules but have to dig deeper (mine) or sift (pan) for them.
An interesting post. When Business Rules are involved using the correct words is rarely anecdotal …
We are actually considering now the best Hebrew word for “rule harvesting”. There are many “harvesting” words in Hebrew, each for a different kind of fruit/vegetable/resource. our top candidates are “Lichrot” (to mine) and “Lidlot” (to retrieve – used mainly for pearls). Mining has a slight disadvantage because it has a connotation of using tools as in data mining.
And on a more philosophical note (can’t help that since we are discussing the field of my philosophical research), I belive that we rarely do gather Business Rules. Usually when we research, verbalize, validate and discuss a rule with SME’s and stakeholders, we actually create a new entity, different (probably better) than the actual original “rule”. However, expanding on that is a bit too much for a comment 🙂
Cecilia is correct that “harvesting ” is bad terminology since it implies (as she points out) that rules are just somehow lying around the domain just waiting to be popped in a basket all fully grown and ready to be consumed.
Actually there is a more fitting terminology for the processes (yes I see not as one but two processes) that was coined by the father of commercial rule-based systems, Edward Feigenbaum … ” Knowledge Acquisition” and “Knowledge Modeling”.
In the first case the KE identifies the sources of the domain knowledge (not the data the “knowledge”) and then goes about using techniques appropriate the the specific knowledge type to assemble and organize it so that in the second phase it can be analyzed to determine the correct representation for it. Because as Amir points out at this stage we are creating “entities” that may be rules (crisp/fuzzy/constraint-based/Bayesian..whatever), cases from CBR, neural nets, GA’s or some hybrid.
Ronald G. Ross
Fred, As I have pointed out many times, the target of expert systems and of business rules methods are simply different. Expert systems aim to mimic intelligent behavior of any type. That’s a very difficult problem … like reading the mind of God, as one practitioner put it.
Business rule methods take on a much more modest challenge (but by no means trivial) — rediscovering the rules written *by humans* to coordinate the activity of *businesses* (enterprises). Such rules come from generally arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, business policy, license, certification, service level agreement, etc.
Sorry but I profoundly disagree. From my first rule based application application in 1984 to today whether we called them expert systems or BR applications (which is more of a marketing “thang” than real) the rules (and/or any other knowledge constructs) have been derived from the policies practices and procedures of the institutional domain being addressed and the “policies” can be (in fact generally are) composed of “… interpretations of some law, act, statute, regulation, contract, agreement, business deal, business policy, license, certification, service level agreement, etc.”.
I know of no one then or now, on the commercial side that ever considered what we do as addressing creating systems to address the problem of generalized intelligence, that was the lab guys and they were fun to watch at AAAI and then the rest of us would go back to the clients and build applications based on parts of their work but do it in the “real world”. That’s why Ed founded IntelliCorp and Teknowledge
Any hoo like I said good point on “harvest” 🙂
Ronald G. Ross
Fred, We agree to disagree profoundly. If what you say were true, then expert system languages would have looked more like constraints. Did you ever see an actual business rule originally written in condition-action syntax?! (Have a look at contracts and laws and policies.) Have you ever heard of expert systems speaking of rule violations and responses to them? Foreign notion. Instead you hear about priority schemes to resolve conflicts between rules … or no attention to conflicts at all. (First rule to the ‘agenda’ wins.) That’s fine if you’re trying to emulate the (intellegent) decision-making of your best subject-matter expert; it’s not fine if you’re trying to run business operations. I never read that expert systems and approaches were actually about business governance — that’s exactly what business rules are about.
P.S. I read Feigenbaum’s popular book when it first came out. Yes, groundbreaking. (Overstated, but that can be forgiven.) But it didn’t address the basic business problem.
“Did you ever see an actual business rule originally written in condition-action syntax?! (Have a look at contracts and laws and policies.) ” Sometimes yes sometimes no (the USDA regs for the amount of fecal and insect contamination is permited in canned soup is particularly lovely example bureaucratese), if they are not (layed out C-A style) and rules are the right representaion schema, then that what KEs are for.
“Have you ever heard of expert systems speaking of rule violations and responses to them? Foreign notion. Instead you hear about priority schemes to resolve conflicts between rules … or no attention to conflicts at all. (First rule to the ‘agenda’ wins.) ” I don’t know where you learned to write rule based apps but dealing with rule conflicts and writing ways to handle it if you miss the conflicts in anlaysis and design is sort of Knowledge Engineering 101. Priority is kind of the last resort. BTW expert systems don’t speak 🙂 Well actually there was one I built for a certain cookie baker for the Oreo line. it had voice in and voice out (in 1990 no less) but the ambient noise on the bakery floor was a killer. It had an elaborate module for resolving rule conflicts.
“I never read that expert systems and approaches were actually about business governance” . Hmm lemme see -MITA the Met Life Intelligent Text Analyzer that used multiple rule bases to determine which medical insurance applications could be passed without requiring attention by a human underwriter and which needed to be seen. All by performing a shallow parse of four key questions and then taking the extracted data elements and then using a rulebase created from corporate policies govenmental regulation. Closeau-Lehman Brothers’ application that insured that clients had the appropriate documentaion reequired by local, state, national and international entites to conduct the type of trade they wanted and if they didn’t stopped the trade. They were both labled “Expert Systems” because that was the term de jour. To quote Mel Brooks “Merchandising, merchandising, merchandising
Ronald G. Ross
Fred, We will simply have to agree to disagree. Conflict resolution is not common to most products on the market. The example you cite of business governance is not one. Expert decision-making, yes. Business governance, no.
Being a Business Analyst who used to be a front end user of the business, systems are now being modified to incorporate the business rules. It is much easier to code the system with the business rules than try to educate the user and it feels that it makes life easier, but in fact overtime it actually makes it worst. We as humans no longer need to think. Systems contain the fuzzy logic, as it is not always possible to code exactly what is required, compromises are made. With the business knowledge the fuzziness becomes very clear. There is nothing as wonderful as the human brain, a working one, and grouping of words, much more powerful.
ah yes… but ‘mining’ gives the impression that the rules were there all the time, and that isn’t true either. Remember.. “there is no rule unless you say there is.”
I’m happy to go with ‘harvesting’, as I know some human somewhere ‘grew’ the rules.
Some of my BA buddies tell me they go out ‘eliciting’ rules. Sounds like fun.
In the old days (80s-90s) we used to “extract rules” from experts. But that sounded like we were taking them to the dentist and it was going to hurt. So today we tell the experts that we need to “elicit rules” from them instead. They like the sound of that much better. It still hurts though!
“Extracting rules” from documents such as laws, regulations, contracts, policies and procedures, etc. sounds right so we use that along with “rule harvesting.”
I know a few companies that claim to “mine rules” from source code. They call it “knowledge mining.” Go figure. I think it’s a bit misleading because they really aren’t concerned with knowledge at all. They’re really mining “program rules” instead of “business rules” anyway.
If you need to go beyond gathering business rules to trying to understand “The Knowledge” about what experts know, how experts think and decide, what the expert rules are, or what the higher-level heuristic rules are, then Knowledge Engineers like Fred and I will keep using “knowledge acquisition” (KA), “knowledge representation” (KR), and “knowledge engineering” (KE). AI guys know that means.
Ronald G. Ross
Agree re: “mining from source code”. GIGO.
And agree re: “knowledge acquisition” and “knowledge engineering”. Very well said. My point to Fred was simply that’s not what business rules are primarily about.
Great logic everyone.
Since all the other good words have now been reserved, I have decided that henceforth I will only ‘distill’ rules.
The distillation process unfailingly emancipates the rules from whatever medium they are infused within, disolved within, or are otherwise cowering within.
Distillation gives unusually high quality results, and it is exciting observe rules crystallise as logical morass engulfing them boils off. I might try double-distillation next. Seems to work for whiskey.
If I get no love on ‘distilling rules’ then I shall move on to ‘winnowing for rules’ which was always a good way to separate the wheat from the chaff.
Ronald G. Ross
Malcolm, Funny! I wish you the best finding love.
Business Rules and Tacit Knowledge | OpenRules Blog
[…] the same time, all practitioners who ever did rules harvesting are well aware of the fact that the most critical business rules are frequently assumed and not […]