This blog post is the first part of a series of blog posts on business rules engines. In this blog post, we will cover the following:

History of business rules engines: Rule Based Systems

• What are business rules?

• Business rules engines

• Business rules management systems

• When and why do you need a business rules engine?

• High-level architecture of a conventional business rules engine

• The 3 phases of inference in rules engines

• Step 1: The Match Phase

• Step 2: The Select Phase

• Step 3: The Execute Phase

• Conclusion

• See Oscilar in action, schedule a demo

This is the first part of our blog series on modern business rule engines. Read this blog series to learn the basics and the ins and outs of how it all works, whether you need it, and why.

History of business rules engines: Rule Based Systems

A rule-based system (RBS) is a model of computation that has been widely used in the field of Artificial Intelligence (AI) for modeling human reasoning and problem-solving processes in specific task areas. Rule-based systems use if-then, or condition-action rules, as their basic unit of computation and employ declarative programming. The sequence of operations is not pre-specified in a RBS. Instead, the control flow depends on the frequent evaluation of the current system state, represented by a set of facts. The computation proceeds by applying the rules in a sequence determined by these facts and concludes with the final recommended action.

This blog post outlines a rule-based system called business rules engine, when and why you need one, and their high-level architecture.

What are business rules?

Business rules resolve to either true or false and take the form of conditions and corresponding actions. They are based on policies, regulations, contracts, and best practices and describe operations and constraints that apply to the business. Their main goal is to assert business policies that helps control the business's behavior and outcomes.

Business rules are used to solve a variety of problems ranging from fraud and risk decisioning to IT policies and marketing segmentation.

Using if-then rules is a natural approach to model human decision-making and problem-solving abilities, as well as, to represent knowledge. Nowadays, business rules have become ubiquitous with a broad range of applications in various domains, namely:

• Risk-based pricing and other pricing strategies

• Loan origination, propensity to pay, recovery

• Segmentation strategies

• Insurance claim approval and related fraud

• Loan amount, credit limits and more

Business rules engines

A business rules engine (BRE) is a software component in a larger business rules management (BRMS) system that allows non-programmers to add, edit or change business logic, operational decisions, or company policies. These are defined, tested, executed, and maintained separately from the application code.

Business rules management systems

A Business rule management system (BRMS) is built around a business rules engine and automates decision-making across an organization's business processes. BRMS act as a central warehouse for rules and offer collaboration and analytics capabilities. A BRMS is used to define, redistribute, execute, monitor, and manage business rules and decision logic.

Modern business rules management systems are accessible to IT admins and business users alike, with features like no-code rules development and automated data engineering.

When and why do you need a business rules engine?

Best use of business rules engines are when they are applied to problems with no obvious algorithmic solution.

Here are some reasons for modeling problems as rules:

• The problem is not well understood upfront

  Rules are a good fit for complex problems where there are no obvious algorithmic solutions, or when the problem isn't fully understood.

• The logic changes often

  The logic itself may be simple but it changes often. In many organizations, software releases are few and far between and rules can help provide agility in a reasonably safe way.

• Data integration is necessary for the logic

  Business rules often require operating on data or facts that are frequently fragmented across several internal and external data sources. Tight coupling of logic and related data reduces efficiency and causes duplication as the data needs to be integrated several times wherever the logic is applied.

• Speed and scalability

  Rules engines employ various well-tested and widely deployed pattern matching algorithms. They provide very efficient ways of matching rule patterns to your data, thereby increasing the speed and scalability of decisioning.

• Centralization of knowledge

  The use of rules creates a central repository of knowledge, or a knowledge base, which is well understood and explainable. It serves as a single point of truth for business policies and related decisioning. Ideally rules are readable enough to serve as documentation.

• Domain experts or business analysts are readily available

  Domain experts often possess a wealth of knowledge about business rules and processes. Rules allow them to express decisioning logic without requiring to write application code.

High-level architecture of a conventional business rules engine

1. Production memory stores the list of rules.

2. Working memory stores the list of facts required by the rules.

3. Inference engine performs pattern patching to execute the selected rule.

The 3 phases of inference in rules engines

At a high level, the inference engine in business rules engines iteratively performs the following operations:

Step 1: The Match Phase

All rules are compared to the current facts in the working memory. This process is called rule pattern matching. Each ordered pair of a rule and the subset of facts satisfying the conditions is an instantiation—also called activation—of the rule. All rule activations are enumerated to form the conflict set.

The process of comparing rules to the current facts in the working memory is called rule pattern matching. In contrast to pattern recognition—recognizing patterns and similarities in data—pattern matching means that the match usually has to result in a boolean match/not match value.

Rules engines employ several types of pattern matching algorithms, such as Rete, Linear, Treat, Leaps. The Rete algorithm is a popular pattern matching algorithm and has become the basis for some of the most popular rule engines, including Drools. Efficiency was a central focus in developing the Rete algorithm and it is designed to sacrifice memory for increased speed. In theory, Rete performance is independent of the number of rules in the system, thus being many times faster compared to naive implementations.

Step 2: The Select Phase

In the Select phase, a single rule activation of the conflict set is chosen for execution. This phase is also called conflict resolution and the predefined criterion for selecting the rule to be executed is called conflict resolution strategy. This phase outputs the resulting selected rule.

Step 3: The Execute Phase

The actions specified in the selected rule are executed. They may change the contents of the working memory. At the end of this phase, the match phase is executed again.

There are two methods of execution for a rules engine: Forward Chaining and Backward Chaining; systems that implement both are called Hybrid Chaining Systems. The way rules are scheduled for execution is a key characteristic that differentiates the various types of rule engines.

1. Forward Chaining: Forward chaining is the predominant type of rules engine. In short, this type of rules engine starts with the data and reasons its way to the answer. They start with the available data or facts and uses inference rules—a function that takes premises, analyzes their syntax, and returns a conclusion(s)—to extract more facts until a goal is reached.
   
   There are two types of forward chaining rule engines:

   1. Production/inference: that take the form of if-then logic

   2. Reactive: that take the form of event → condition → action or 'when-then' logic
      
      

2. Backward Chaining: Backward chaining, as the name suggests, is the opposite of forward chaining. While forward chaining starts with data and works its way from there, backward chaining starts with a list of goals (or a hypothesis) and works backward to see if any facts support the goals or a hypothesis.

Conclusion

While business rules engines have become ubiquitous with a broad range of applications in various domains, they may be an overkill for certain use cases. They are a powerful abstraction when applied correctly and enable a broader user base—that do not write code—to solve key business problems ranging from IT policies, risk management to regulatory policies and marketing segmentation.

In this blog post, we went through what conventional business rules engines are all about. Part 2 of the blog post series will go through a popular business rules engine called Drools. The final blog of this series will go through modern decision engines and what's missing in conventional business rules engines.