Developers of expert systems have an important point that most business process analysts miss.  But business process analysts have an important point that most developers of expert systems miss.  Consequently, most methodologies for business requirements development fall woefully short in one respect or the other.  Let me explain who's missing which point -- and what's needed to get at the best of both.

Developers of expert systems typically focus on decision points in the work environment where some (usually complex) decision must be made.  Such a decision typically has to do with classification, diagnosis, assessment, monitoring, prediction, assignment, allocation, or other types of complex activities.  Typically, the rules governing such decisions are peculiar to, and characteristic of, the company's product/service offerings -- i.e., its special area(s) of expertise.  Examples of such decisions might include the following:

• Whether or not to approve an application for automobile insurance.
• Whether or not to pay a claim.
• Whether or not to buy a stock.
• Whether or not to declare an emergency situation.
• Whether or not to give an on-the-spot discount to a customer.
• Whether or not an applicant is right for a job.
• Whether or not a patient has a particular disease.

There is no denying that these decision points exist, or that they are of vital importance to the business.  There is also no denying that these examples (and thousands more like them) are rule-intensive, or that capturing the relevant rule sets correctly should be a key component of a good business requirements methodology.

That's the point most business process analysts miss -- or perhaps chose to ignore because of "procedural" bias.  Consequently, there are excellent, workable rule-capture techniques addressing decision-making simply not found in their toolkits.

If that's what the business process analysts miss, then what do developers of expert systems typically miss?  The answer requires digging a bit deeper into two basic assumptions of traditional expert systems.

Assumption 1  . You can define all the relevant rules well enough for automated decision-making to be effective.  Obviously, there are some very difficult problems (e.g., weather forecasting) where this assumption simply does not hold true today.  But let's face it -- many, or perhaps even most, business decision points at the operational level (i.e., where business process analysts usually concentrate) come nowhere near that magnitude of complexity.  So this assumption is not really at issue.  In fact, if you are focused on either knowledge retention or dis-intermediation (i.e., eliminating the middle man ... as in web-based self-service applications), capturing and managing these decision-making rules becomes a "must."

Assumption 2.  The cost and difficulty of gathering the appropriate data is a relatively trivial issue compared to the complexity of the rules.  This is the point -- and it's a huge one -- that developers of expert systems typically miss when the target problem involves an operational business process.  The fact is that in a business context it can be extremely costly and difficult (and inefficient) to "gather all the appropriate data" simply to set things up for all the decision-making rules to fire.

Let me offer a simple example.  An automobile insurance company might have the following business rule:  An application for car insurance may be approved only if the applicant is at least as old as the minimum driving age.  This particular rule, of course, may be only one of hundreds determining whether an application should be approved.  Other rules might involve credit-worthiness (which could involve an extensive credit check), previous driving history (which would require requesting records from the state), etc.  In other words, there is a lot of work involved in gathering all the data required to support all the rules.  And in a business context, "work" means time and money.

Consequently, business process analysts are committed to what I call "work avoidance" (no pun intended) wherever possible.  If the applicant is less than the minimum driving age, why perform the credit check and the acquire the driving records (etc.) at all?!  If you can determine up-front in the business process that the applicant is too young, all that other "data" work can be avoided.

The implication is that simply capturing decision-making rules is not enough for operational business problems.  In fact, it's only half the problem.  First what you need to develop is the workflow for the business process in order to explore opportunities for "work-avoidance."  Rules governing the business process (such as the minimum driving age rule above) must be tested as early in the workflow as possible.  Waiting to test them at some downstream decision point is simply inefficient.  This "early-bird" testing of business process rules is a fundamental feature of the business rule approach.

The bottom line is this. In working with numerous business clients since the mid-90s, we have learned several fundamental lessons about business rules.  These lessons represent key features that you will find in our business rule methodology, BRSolutions.

• To some extent, every company has both business process rules and decision-making rules (or more precisely, product/service rules).
• Each of these two types of rules requires special techniques.
• If both are to be analyzed, the business process (and its rules) should be developed first.  This is because in a business setting, the decision-making tasks (and the associated product/service rules) are always embedded in the business process, and dependent on its basic sequence, specification and vocabulary.

In other words, what we have learned is that both camps were right -- and that both were wrong.  Fortunately, our business rule approach turns both these wrongs into rights.

# # #