How does a business rule engine work?

Business rules form the backbone of many processes within an organization. Examples include rules for customer acceptance, price calculation or compliance. A business rule engine (BRE) helps you apply these rules efficiently and flawlessly. But how exactly does a BRE work? In this article, we will explain the inner workings of a business rule engine.

The core of a BRE: automating rules

A business rule engine works on the basis of business rules that are stored in the system. These rules are written in an understandable, often non-technical language, so that both business and technical teams can work with them. The process can be divided into three main phases:

1. Input: The BRE receives data from systems, users or other processes.
2. Application of rules: The BRS compares the input with the defined business rules.
3. Output: Based on the rules, the BRE makes decisions or generates actions.

For example: a telecom provider can use a BRE to allow new customers to sign up for a subscription. Input (customer data and desired subscription) is compared to rules (such as those regarding financial solvency and age), after which the BRE decides whether to approve the application.

What does the process look like?

You can compare the work that a business rule engine does to making a complex dessert. You set up a business rule engine to make an - often complex - decision or to set up a complex process.

Imagine you want to make a layered ice cream cake: a nice light cake base topped with creamy ice cream, and finished off with a thin crispy layer of chocolate.

Before you can assemble and serve this cake, you will have to go through a few steps.

The very first step is to gather the right ingredients. For the base of your cake you need eggs, flour and oil. You may be able to use ready-made ice cream for the ice cream layer. But what if you can't find any? Then you can also make ice cream with cream, eggs and vanilla. This will make your ingredients list a bit longer.

The ingredients for decisions are data. Sometimes you have all the data you need for your decisions neatly at your disposal. Sometimes you first have to combine data to arrive at the right information. For example, when you need the customer's age, but you only have the date of birth and the current date at your disposal. In short, you need to make sure you have all the data to make a good decision, whether quickly or with a few detours.

The business rule engine receives data from various sources, such as:

• CRM or ERP systems
• Web applications
• External official data sources, such as the land registry or the Chamber of Commerce
• Manual input from users

In our example of a new telephone subscription, you could import the date of birth and the bank account via a bank (IDIN). You can check whether someone has had serious payment arrears in the past via the Credit Registration Office. To assess whether someone has sufficient income for a subscription, you could check a payslip. This can be done by a person, but you can also have an AI tool automatically read a document. Data sources can therefore be very diverse in nature. And it is important that all data has a clear, unique name in the system, so that you use the right data at the right time. Date of birth, current date and entry date should not all be called 'date'.

In the second step to making your cake, you also gather the kitchen utensils and follow a recipe to make your cake. If you have ready-made ice cream, you need fewer recipes and kitchen utensils than if you have to make the ice cream first.
Your business rules describe step by step how you get from your ingredients (the data) to the cake (a good decision). You also use constants: tables and calculation numbers that always remain the same. It is somewhat comparable to whisks and mixing bowls: you use the same tools for every cake. It is the ingredients and the recipes that make the difference.
In our example of the telephone subscription, there is a minimum age at which someone can take out a subscription. That is, for example, 18 years old. It does not matter who makes the request, or when they make the request, the final age is always compared to that number: 18 years old. That is a constant.

Describing rules

The steps to reach a decision are recorded in rules. This can be done in natural language, a standard rule language that the system understands, such as Decision Model and Notation (DMN), or a proprietary Domain Specific Language (DSL). With complex decisions, decision rules follow each other in a logical sequence, just like the steps in a recipe.

A set of rules must be described in such a way that you cannot 'get lost' and accidentally make the wrong decision. Consider our recipe: in total you may need 8 eggs. But for the base you only need to beat 4 eggs. If your recipe only says 'beat the eggs and add the flour', your base will fail. You need to make it clear that the first 4 eggs are for the base, so that you can use the other eggs later in the recipe. In your business rules, you have to be careful not to make decisions before you have made all the considerations necessary for the decision.

For example:

Rule 1: First you look up how old someone is by calculating their age using their date of birth and today's date.

Rule 2: You compare this rule with the minimum age constant: 18 years. If someone is not old enough, the application is rejected.

Rule 3: If someone is old enough, you check their BKR status. They must meet the criteria to be allowed to proceed.

And so on.

If a 16-year-old is allowed to take out a special prepaid subscription, you make sure that you have clearly included that in your rules. You do not immediately reject someone under the age of 18, but first check whether they are over 16. The order in which you apply your rules is important here.

Once you have the ingredients, the right kitchen utensils and a good recipe, it is time to bake the cake. The business rule engine analyzes the input and executes the stored rules. This often happens in a fraction of a second, even with complex rules.

When assessing income situations for business or private loans, for example, these rules consist of, among other things

• complex calculations
• strict requirements for the customer, such as age, a credit rating and nationality and place of residence
• criteria for any collateral, such as a house or a car
• comparisons with tables stating how much of the income may be used for a monthly payment on that loan
• criteria for the customer's overall financial position, such as how many other loans they may have

A business rule engine executes all these rules and keeps track of which rules are and are not being met.

Your cake is finished. With the help of good ingredients and all the right tools, you have a beautiful end result. But now it still needs to be served on a nice plate and with a suitable fork and spoon so that it can really be enjoyed.

The business rule engine generates an output based on the analysis. This can vary from a decision (“application approved”) to an automated action (“apply discount to invoice”). To be able to “serve up” that outcome neatly, you must link that outcome to

• a database in which the decision is recorded
• the process/workflow, so that the employee or the software takes action based on the decision

A good business rule engine therefore offers solutions for more than just defining the correct business rules, but also for data integration for both input and output. Ideally, you can fully integrate the business rule engine into your workflow and processes.

Would you like to know more about how to make your organization a little healthier with the right recipe? Request a personal demo now using the button below.