Most rules approaches tend to group business rules into rulesets. These rulesets are typically the unit of execution and often the unit of reuse and management. There are many ways to classify rulesets but it seems to me that three key characteristics can be identified – the visual representation of the ruleset, the editing approach used for the ruleset and execution approach used for the ruleset.

Visual representation
Many rulesets are simply represented by a list of rules – essentially the default visual representation of a ruleset. Others however lend themselves to display in various visual representations.

Some rulesets can and should be represented as decision tables. Where the business rules are based on a small number of conditions, with each rule corresponding to a particular combination of data values or value ranges. Common examples include rate tables, pricing charts, discount schedules, and so on. The postage chart on the wall of your local post office is an example of a decision table, based on shipping method, weight and destination. Note that rules in a decision table are usually “exclusive” or unique (any combination of data only maps to a single rule), and often “exhaustive” (every possible combination of data is covered by a rule).

Decision trees allow you to trace a chain of conditions to a single appropriate action. Looking at branches coming from a decision point (or “node”) in the tree lets you quickly confirm that all applicable possibilities have been accounted for. A ruleset that has rules that share many initial conditions and result in a single outcome can be represented very effectively as a decision tree, such as a diagnostic tree. Like decision tables, the rules in the tree will likely be exclusive and exhaustive.

Although decision tables and decision trees are representations that are in common use, some approaches adapt decision tables to build additive score models, and new techniques such as EDAGs or Exception Directed Acyclic Graphs, are coming into play. The example below of an EDAG is a simplification of a tree with some 26 nodes that is wide and shallow and hard to use.

The bottom line with all visual representations is that each is suitable for different rulesets and should only be used when it is appropriate. No one approach works for all rulesets.

Editing style
The editing style – how the detail of the rules will be represented and modified – is a second key characteristic. Clearly some rules, such as those displayed graphically as described above, can be manipulated graphically. Some approaches build graphical models of rules individually and allow users to manipulate these diagrams. These can be effective for complex rules but cumbersome when large numbers are required. The Object Role Modeling picture below is an example.

The second approach is to actually allow a language, say English, to be used to edit the rules. In this case some tool controls the facts and syntax somewhat and interprets the written language. This is very familiar for business users but can be difficult if the same rule should be represented to speakers of different languages and the construction and management of vocabularies can be complex.

The third approach is to use some “technical” language such as LISP or another AI language. These are the “traditional” representations of declarative logic but typically require specialist skills to read and write. Some tools combine this with a template based approach, see below, to hide this syntax from users. Even when hidden the use of a technical language can be problematic as debugging and some coding must be done in it and this excludes business users from the process, defeating one of the key purposes in using a rules approach.

Many tools provide a structured syntax for editing the rules. These syntax definitions are more like a programming language in that they have strict rules about how the syntax is written but they are typically more friendly for end users as they are designed to be so. For example, given the right object model and names of classes, the following is a real rule:

If (vehicle’s age is between 0 years and 8 years) and
(policyholder’s age is between 21 years and 60 years) and
(policyholder’s number_of_claims does not exceed 3)
Then set policyholder’s case to “STANDARD”

Some environments allow the use of rule templates to provide a rule design pattern and restrict how a rule can be edited; such environments will then expose a point-and-click editor that allows business users to view and change rule parameters. These environments might expose the whole rule for editing, part for editing and part read-only or might keep some elements of the rule completely hidden to allow a business user to focus on a smaller part of the rule.

Execution Characteristics
The key third characteristic set is around execution. Rulesets may be inferencing or non-inferencing, interpreted or compiled. Various execution parameters might also be set.

The decision to use inferencing or not is a key one for any ruleset. Some environments will force one or the other on every ruleset in a project (either because the tool only supports one or because it allows execution mode selection only at the project level), but regardless each ruleset should be asessed separately. Inferencing is used where it is useful to have rules that could be dependent on other rules, or where it is important that the rule developer is not concerned about the ordering of the rules, or where only a small number of rules are expected to execute from a large number in ruleset. These use some efficient rule selection engine such as Rete or its derivatives (the latest being Rete III).

Non-inferencing is used where it is quicker to try and execute all rules than it is to figure out which rules are eligible and where rule ordering is either irrelevant (all rules are mutually exclusive) or explicit (the rule author explicitly orders the rules in the ruleset for execution – effectively programs the rules). In general it is best to start with inferencing as it is more change-tolerant and move to non-inferencing or sequential execution when performance demands it and it is possible.

Interpreted rulesets are used when rules change a lot and compiled when performance is key. Many engines manage compiling on the fly to optimize performance all the time. Many tools also "compile" the rules into a memory model even when running in interpreted mode to improve performance.

Ruleset execution can also be impacted by effective dates - those dates/times for which the ruleset or more usually individual rules are appropriate. This allows a rulebase to contain rules relevant now and rules that were relevant only last year or will be relevant only after a certain date, for example. At execution time only those rules "active" should be executed. Rule priorities also play here and can be used to force execution of rules in a particular sequence or at least before certain others. Some rulesets will also allow for individual rules to be on or off each time it is executed, offering some kind of programmatic control for this.