- Databasing Your Rules
- What Is a Business Rule?
- Business Rules and the "Flow"
- Business Rules and the "Know"
- Why Business Rule Methodology Is Different
- Analysis Paralysis
This chapter is from the book
This chapter is from the book
This chapter is from the book
Business Rules and the "Know"
Rules for Processes and Rules for Products/Services
Over the years, developers of expert-system applications have consistently focused on a fundamental aspect of business problems that most IT professionals fail to perceive. The reverse, however, is also true. Most developers of applications using traditional expert systems fail to perceive what IT professionals know almost intuitively. Consequently, almost all approaches to developing business systems fall woefully short in one respect or the other. Let me explain who is missing what and how the problem can be corrected.
Decision Points
Developers of expert-system applications have traditionally focused on decision points in the work environment. A decision point is where some critical decision (usually a complex one) must be made. Such a decision typically might have to do with one of the following kinds of tasks: classification, diagnosis, assessment, monitoring, prediction, assignment, allocation, and so on.
The rules governing such decisions are usually viewed as peculiar to and characteristic of the company's product/service offerings. These offerings invariably involve the company's special area(s) of expertise. Examples of such decisions include whether or not to:
Approve an application for automobile insurance
Pay a claim
Buy a stock
Declare an emergency
Give an on-the-spot discount to a customer
Assign a particular resource to a given request
Diagnose a patient as having a particular disease
Accept a reservation
Indicate possible fraud
Such decision points, all rule-intensive, are of vital importance to the business. Capturing the relevant rule sets should therefore be a key component of a company's approach to developing its business systems.
Unfortunately, most approaches for system development used by IT professionals have never done this outright. Most such approaches are highly procedural and offer no direct support for capturing large numbers of rules in declarative form. By and large, IT professionals have not even grasped how significant this omission really is.
Work Avoidance
Turning now to developers of expert-system applications, what is typically missed in their approaches? The answer requires digging a bit deeper into two basic assumptions of traditional expert systems.
Expert-System Assumption 1. It is possible to define all relevant rules well enough for automated decision making to be effective.
There are, of course, some very difficult problems (for example, weather forecasting) where this assumption does not hold true today. In the typical business, on the other hand, a large number of important decision points in day-to-day operations come nowhere near that magnitude of complexity.
So this first assumption is basically correct for business systems. Indeed, if the business goals for a project include disintermediation (that is, eliminating the middleman, as in Web-based self-service applications), capturing and managing these decision-making rules is a must.
Expert-System Assumption 2. The cost and difficulty of gathering the appropriate data is a relatively trivial issue compared with the complexity of the rules.
This is a point about business systems—a huge one—that developers of expert-system applications historically got wrong. 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 rule, of course, might be only one of hundreds determining whether an application should be approved. Other rules might involve creditworthiness (which could involve an extensive credit check), previous driving history (which could require requesting records from the state), and so on. In other words, there is a lot of work (time and money) involved in gathering all the data required to support all the rules.
Consequently, one of the basic goals in designing business processes is what I call work avoidance (no pun intended). For example, if the applicant for automobile insurance is less than the minimum driving age, why perform the credit check and acquire the driving records (and so on)? If you can determine up front in the business process that the applicant is too young, all that other data-related work can be avoided.
Simply capturing all the decision-making rules is clearly not enough for effective support of business systems. In fact, capturing the rules is only half the problem. First you need to develop the workflow for the business process in order to fully explore all 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 basic principle of the business rule approach.
The Workflow Imperative: Early-Bird Testing of Rules
To avoid unnecessary work, rules should be tested as early as possible.
Business Process Rules versus Product/Service Rules
This insight sheds new light on the knowledge principle (what the company knows should be balanced with what it does). It comes down to these final points.
Two Kinds of Rules.
To some extent, every company has both business process rules and decision-making rules (usually product/service rules). The "know" part really has two dimensions, both crucial. Examples of business process rules and product/service rules for three different organizations are given in the following boxed item.
Examples of Business Process Rules versus Product/Service Rules
Internal Revenue Service (IRS)
Business Process Rule
Rule: A processed tax return must indicate the IRS Center that reviewed it.
Product/Service Rule
Rule: Calculated total income must be computed as tax return wages (line 1) plus tax return taxable-interest (line 2) plus tax return unemployment compensation (line 3).
Ministry of Health
Business Process Rules
Rule: A claim must be assigned to an examiner if fraud is suspected.
Rule: An on-site audit must be conducted for a service provider at least every five years.
Product/Service Rules
Rule: A claim involving comprehensive visits or consultations by the same physician for the same patient must not be paid more than once within 180 days.
Rule: A claim that requests payment for a service event that is a provision of health service type 'consultation' may be paid only if the service event results from a referral received from another service provider.
Ship Inspection Agency
Business Process Rules
Rule: A ship inspection work order must include at least one attendance date.
Rule: A ship must indicate a client who is financially responsible for inspections.
Rule: An inspection due for a ship must be considered suspended if the ship is laid up.
Product/Service Rules
Rule: A ship area subject to corrosion must be inspected annually.
Rule: A salt water ballast tank must be inspected empty if the ship is more than five years old.
Rule: A barge must have an approved bilge system to pump from and drain all belowdeck machinery spaces.
Do the Business Process "Know" First. If a project will address both kinds of rules, workflow model(s) for the business process (and the associated business process rules) should generally be developed first. The reason is that decision-making tasks (and the associated product/service rules) are always embedded within a business process and therefore dependent on its basic sequence, specification, and vocabulary.
Do the Product/Service "Know" Too. Capturing the workflow models (the "flow") and the business process rules is by no means sufficient. To fully support the "know" part, the product/service rules must be captured in an appropriate manner too.
Business-Driven Solutions
The business solution should be worked out completely before any system is designed—and for sure before any coding begins.