Business Rules
Management System

1. Definition

To understand how Higson can be used as a Business Rules Management System, we need to lay out some definitions first.

1.1. What are Business Rules?

In application development, business rules define how the application should behave in a given context. In other words, they define the logic an application has to follow. Most often business rules are expressed in the form of when-then statements. Examples of such rules are:

when a customer’s cart value exceeds $100 then apply a 5% discount, or when some item is chosen then some other item becomes unavailable.

When the system we create gets large and complex, maintaining all the rules becomes a challenge. And this is where a dedicated management system comes into play.

1.2. What is a Business Rules Management System?

A Business Rules Management System is a software system designed to define and maintain business logic, often in the form of business rules or decision tables. Instead of embedding this logic in application code, the BRMS enables the logic to be externalized and managed away from the source code. Having business rules externalized and accessible to operational staff (not only developers), the BRMS delivers a boost to business agility and productivity, offering cost savings and faster logic changes.

1.3. What is a Business Rules Engine?

A business rules engine is a software component (often delivered in the form of a library) that can evaluate business rules to produce the desired actions or outcomes. Such engine should be high performing, and allow rules modification during runtime.

Read more: Why Higson is better than other rules engines?

2. Higson as a BRMS

Higson is a BRMS focused on performance. It is designed to easily handle large decision tables. The rules engine uses in-memory structures and a carefully designed matching algorithm to search large decision tables (1M rows and more) in a few microseconds. At the same time, developers and business experts may modify business logic without touching the application’s code. Changes are immediately reflected in any application that uses the Higson engine.

Higson business rules have the following structure:

when a condition is met
then a result value is returned

Business rules are grouped in decision tables called parameters. Higson uses Parameters as its most basic structures. Developers can design their applications as configurable on the fly by making the application’s code dependent on parameters.

The following is an example of the parameter “tariff” used as a decision table:

These business rules grouped as the parameter “tariff” can be interpreted as follows:

• when product is PRD_A and age is in [0, 30] then tariff factor is 0.95
• when product is PRD_A and age is in [31, 60] then tariff factor is 1.10
• when product is PRD_A and age is outside of [0, 60] then tariff is 1.30 (else semantics)
• when product is WB_2 and age has any value then tariff is 1.50
• for any other product and any client’s age, tariff is 1.80

All of these rules form a decision table with a clear structure and meaning. This table can be used as the parameter “tariff” in the application code:

This shows how a client’s fee calculation might be parameterized with the tariff Parameter. The terms parameter and decision table are used interchangeably in Higspn.
All Higson rules are presented in a user-friendly manner, in the form of tables easily exportable to Excel or CSV files.
Like other BRMS, Higson is useful in applications that have at least one of the following characteristics:

1. they have a very complex business logic
2. they have a logic that needs to be changed very often
3. they need to have a business logic externalized and accessible to business experts

3. Business rules as decision tables

Higson parameters consist of 4 elements:

• definition of conditions (input columns)
• definition of outcomes (output columns)
• matrix built from input and output cells
• meta configuration (rule matching mode, caching, sorting, etc.)

Each input column (condition) has to be bound to a source. It can point to valid data in the domain model – for example, policy.insurer.age is a valid path to the number which is the age of the client found on the insurance policy. It can be also bound to the outcome of a script or another parameter.

Each condition has a defined matcher which is used to check whether the bound value matches to a pattern in an input column. Common matchers are:equals, between, in, not-in, regex, like, contains/all, contains/any, etc.

Each output column holds the parameter’s potential value, which will become the outcome if all conditions in the same row evaluate to true.

Higson parameters can return a single value, several values (a vector) or even a matrix or table of values. In combination with different matchers, different matching modes and bound sources it is quite a powerful tool in developer’s hands.

The following screenshot presents a real-life example of a parameter defined in Higson Studio.

In this screenshot you can see a parameter that has 6 conditions (IN columns) and 4outcomes (OUT columns). Conditions include age and value of the vehicle (between matcher), name of previous insurer (in matcher) and insurer’s profile code (default matcher). The Higson rules engine will find the best matching row and return its 4values.

Typically, all Higson parameters are fetched from a database and converted into an in-memory index when used for the first time. The in-memory index allows matching rows to be found in a few microseconds. The index structure guaranteesO(1) lookups if all conditions use default matchers.

It is not uncommon to see a project with more than 500 parameters (decision tables), with many having more than 100k rows and some larger that 1 million rows.

4. Functions – script-based business rules

Although Higson decision tables are a very powerful means to express business logic, sometimes this may not be enough. For such situations Higson offers a scripting language. In other words, developers or business users can write functions that behave exactly the same as a decision table does – they consume certain inputs and produce an outcome.

Users can write functions in Groovy or JavaScript (whichever they prefer) with help of the Higson standard library. The functions let them implement any business logic they want.

The following is an example of a Groovy-based function:

Higson functions can read domain models, evaluate parameters or call other functions.They can perform any logic dependent on domain model data. Higson functions come with a standard library in the form of predefined objects that enable developers to:

• read data from domain model (context),
• read parameters,
• call other functions,
• operate on dates and strings,
• perform common math operations,
• perform smart type conversions,
• write statements to log files,
• read hierarchical business configurations.

The following screenshot presents a real-life function edited in Higson Studio.

Functions and parameters together form a coherent ecosystem:

• functions can depend on values evaluated from parameters,
• parameters can bind functions to condition columns,
• parameters can define outcome as a call to a function.

Let’s see how this can be leveraged:

The above parameter:

• defines first condition as bound to insured.age from domain model,
• defines second condition as bound to the value returned by the client.status function,
• the output column often uses literals like: 3.0 or 4.5,
• but sometimes it delegates evaluation to a function call like: $f factor(50).

Many projects developed for the insurance or finance industries have proven that Higson parameters and functions together can handle any business logic.

5. More business rules examples

It is difficult to see at a glance all the possibilities Higson offers as a BRMS. As mentioned earlier, users can express their business rules with different matchers and different matching modes. They can bind different sources to condition columns or use function calls directly in decision table cells. The following examples will demonstrate some of these aspects.

5.1. Cascading decision tables

Suppose we have a simple decision table with many rows but a single condition that maps an investment fund code to a management fee:

Unfortunately, after some time an exception to this simple decision table has appeared: from now on the H01 fund fee should depend on the policy year and the policy premium amount. Moreover, the YME fund should have the fee calculated according to a certain math formula.

We can adapt easily by creating a H01-specific parameter and YME-specific function as follows:

Parameter “fund.fee.h01”:

Function “fund.fee.yme”: