Rules Engine

Business Rules are instructions on how the system (software or service) should behave given the exact conditions. The typical business rules structure looks like this:

• when [condition],
• then [result].

Business Rules usually refer to statements that concern a business model, pricing, offer, product/service attributes, or communication with a customer.

The following statements are Business Rules:

• In banking: when a customer is new, then offer a $200 bonus.
• In retail: when a customer buys three items of the same product, then make the third one free.
• In insurance: when a customer has a history of claims, then raise the price by 10%.
  

As the name suggests, business people create business rules.

The companies use business rules among others to:

• gain new clients (special offers for new customers),
• upsell (quantity discounts),
• segment clients (higher prices for more costly clients)

The when-then statement is generic, and it can cover a lot. Consider the following sentence:

• When a user clicks on the buy button, then she or he goes to the checkout card.

Is it a Business Rule or not? It might be, but it's standard e-commerce button behavior, and the business people usually don't focus on it. Instead, they concentrate on the Rules that are not obvious and need a business decision (such as the amount of the discount).

The examples in the previous subchapter are simple on purpose. They highlight the main idea. In business reality, business rules are far more complicated. The more complicated system or service, the more sophisticated the rules are.

Business Rules should help you simplify and organize the business process.

A Business Rules Engine is a software that helps you manage and execute Business Rules. The main advantage of the engine is the separation of the business logic from the hard code. It leads to:

• easier maintenance (business users might update the rules by themselves after the initial configuration)
• and faster deployment (sometimes there is no need for releasing the new version of the system).

The users might model the rules as (depending on an engine):

• decision tables,
• decision trees,
• functions (code),
• DSL (Domain Specific Language),
• workflow (with visual graphs modeling).

Usually, Business Rules Engines deliver a user interface in the form of:

• web browser app,
• desktop native app,
• or through Excel.

Business Rules Engine might come as:

• a library for the specific language,
• or an autonomous component that connects by API.

You can install Business Rules Engines:

• on-premise,
• or in the cloud.

You should decide on a Business Rules Engine if at least one of the statements below is valid:

• you change the Business Rules frequently (a few times a month),
• you want to empower the business users to update the rules autonomously,
• the Business Rules are multilayered, and it's challenging to test them (most Business Rules Engines simplifies tests).

On the other hand, implementing the rules engine might occur an unnecessary effort, if:

• your business logic is very seldomly modified,
• or there is no will for engaging the business people as users,
• or your Business Rules are plain simple (for instance, the only variable is a one-size-fits-all price).

It depends on several factors:

1) Who is going to use the Engine?

‍Are they business users, technical users, or both? Do they need the user interface? Do they prefer Excel? Higson provides the GUI and supports working in Excel.

Some solutions require installing a desktop native application on every user's computer. Others are browser-based (Higson, for instance), and it makes it easier to access the tool.

2) Do you need to install it on every user's computer?

3) Cloud or on-premise?

Most Business Rules Engines (including Higson) works both ways.

4) How complicated are your Business Rules?

a) Simple (several when-then statements, almost none exceptions, no scoring needed)

Look for tools supporting:

• natural language,
• decision trees,
• and workflows.
  

b) Medium (hundreds when-then statements, some exceptions, simple scoring)

Look for tools supporting:

• natural language,
• decision trees,
• workflows,
• decision tables.
  

c) Advanced (thousands or more when-then statements, lots of exceptions, advanced scoring)

Look for tools supporting:

• highly customizable decision tables,
• functions as a flexible addition to modeling.

Higson is the best fit for advanced Business Rules. Decision trees or natural language processors with thousands of rules lose clarity. Decision tables are more straightforward to comprehend. Moreover, functions add unlimited possibilities to modeling.