Task Descriptor: Define Rule Schema

After the discovery activities it may be important to spend some time to classify the rules in different categories or patterns. This will help to decide where to implement the rules, and help to design future rule templates. We can represent the different classification schemes for business rules using the following diagram:

This scheme represents a conceptual breakdown of the different types of rules that are of interest to the business. Structural rules define the terms used by the business in expressing their business rules and the relationships (facts) among those terms. These comprise the vocabulary used in rule authoring. Structural rules are represented in ILOG JRules in the Business Object Model and externalized to rule authors as vocabulary (verbalizations of BOM classes and members in phrases that enable the business rules to be expressed in natural language.

Decision logic is the core of what is typically referred to as ‘business rules.’ When a business decision needs to be made (e.g. whether to sell a given insurance policy, whether to accept or reject a claim), the business rules are the individual statements of business logic that determine the result of the decision. The following table is coming from Barbara Von Halle’s book “Business Rule Applied”. It details those categories:

*Rule Classification*	*Explanation*
Mandatory constraints	Rules that reject the attempted business transaction
Mandatory constraints	Grammar to use during rule documentation not implementation. <term> MUST HAVE <at least, at most, exactly n of> <term>; <term> MUST BE IN LIST <a,b,c>;
Guidelines	Rules that does not reject the transaction; they merely warn about an undesirable circumstance. Usually translates to warning messages.
Guidelines	<term> SHOULD HAVE <at least, at most, exactly n of> <term>; <term> SHOULD BE IN LIST <a,b,c>
Action-enablers	Rules that tests conditions and upon finding them true, initiate another business event, message or other activity
Action-enablers	IF <condition> THEN action
Computations	Rule that creates new information from existing information based on mathematical computation. Result is a piece of knowledge because it cannot simply be known.
Computations	<term> IS COMPUTED AS <formula>
Inferences	Rules that create new information from existing information. Result is a piece of knowledge used as a new fact for the rule engine to consider.
Inferences	IF <term> <operator> <term> THEN <term> <operator> <term>

Figure 3 Rule Type: industry standard (Source KPI inc)

For the implementation of Guideline and Constraint it is important to consider what should happen when they are violated. Most of the time the action part will rise an exception or a high priority issue.

An important item to note in computation rules is that we need to manage the actual calculation but also if there are rules that are required to be managed prior to those calculations and the rules that are required to manage that are included in terms of the calculation – then the entire rule set needs to be managed not only just the actual computation rule.

Process flow rules are rules that purely direct the movement through a process flow (or workflow, etc.). It may be helpful to distinguish process flow rules from the business logic rules that determine the values of the parameters on which the process flow is directed.

ETL rules, or data transformation rules, are often considered separately from other business rules, although in pattern they are essentially inference rules and computation rules. Data transformation rules, while important to the business, are a side-effect of system implementation rather than a reflection of core business logic per se. For implementation, the decision to use a rule engine for ETL rules should depend on whether the rules are static or dynamic, but also the maturity of the mapping knowledge. We used rule engine to easily implement transformation rules between two data model, and once the environment is more stable, some of those mapping are put back on the code.

To the industry standard we can add some other rule pattern we found in lot of business application:

*Rule Classification*	*Type of application*
*Compliance Rules*	Rules that reject the attempted business transaction. Yes/no result but completed with reason code and explanation
*Compliance Rules*	Underwriting Fraud detection Data and form validation
Rating	Strongly interrelated rules that compute metrics for a complex object model
Rating	Scoring and rating Contracts and allocation Pure calculations on an object providing a final value (or rating).
Correlation	Strongly interrelated rules that correlate information from a set of objects to Compute some complex metrics
Correlation	Billing and cost estimation Complement by inserting information
Stateful	Strongly interrelated rules that correlate events in a stateful way
Stateful	Alarm filtering and correlation Web page navigation GUI customization

Classifying the rules will help to decide for the best implementation. Inference and action enabler type of rules are good candidates for a rule engine. Pure computation will most likely been done in code unless computation rules are subject to frequent changes. It is also helping to evaluate the complexity of the rule and so to evaluate the workload to implement it.