This blog post is the second part of a series of blog posts on business rules engines. Part 1 covered business rules engines in detail; what they are, how they work, and why you might need one. This blog post provides a high-level overview of a specific rule engine called Drools and how to build a a modern business rules management system using Drools:
Drools basic glossary
Challenges with Drools
Weak support for frequently changing rules and related data
Redundancy and inefficient management of rules
Limited expressiveness and steep learning curve
Building a modern Drools based business rules management system
Conclusion
See Oscilar in action, schedule a demo
What is Drools?
Drools is a rules library with a forward and backward chaining-based rules engine. It uses an enhanced implementation of the Rete algorithm and supports the Java Rules Engine API standard for its rules engine.
A short history
The Drools Project was started by Bob McWhirter in 2001 as a SourceForge project. In 2005, Drools was federated into JBoss as part of their JEMS offering and rebranded JBoss Rules. In 2006, JBoss itself was acquired by Red Hat and got renamed back to Drools in 2007.
Drools basic glossary
Here are some of the basic concepts in Drools:
Drools Rule Language
The Drools Rule Language or DRL rules are business rules defined in .drl text files. A DRL file can have one or more rules that define the rule conditions and actions in a when-then form.
Rule
A Rule consists of a condition that fires the rule (when) and a consequence that performs actions (then) when it fires. It associates facts with matching actions. As we mentioned in the previous blog, business rules can only be true or false.
Facts
Business rules are composed of facts and facts represent data that serves as information for rules.
Working Memory
Working memory is storage containing facts. The working memory enables a business engine to use facts for pattern matching. Facts can also be modified, inserted in, and removed from the working memory.
Knowledge Base
Knowledge base is an interface that manages a collection of rules, internal types and processes and it represents the knowledge of the Drools ecosystem. Knowledge sessions are created using the knowledge base.
Knowledge Session
The knowledge session holds all the resources that are required for firing rules. Facts are inserted into a session, and then matching rules are fired.
There can be stateless knowledge sessions and stateful knowledge sessions.
Stateless knowledge sessions have facts or a working memory inserted into them, and it means a new session is created for each request, while stateful knowledge sessions maintain the old sessions, continuing where the previous one left off.
Module
A module contains multiple knowledge bases, which help create knowledge sessions.
Challenges with Drools
While Drools enables you to define and manage the business rules outside of your code, it presents some challenges as well.
Weak support for frequently changing rules and related data
The primary challenge with Drools is the lack of support for frequently changing rules. Generally, a Drools-based Java application requires all the rules artifacts such as DRLs, decision table excel files to be part of the application binary itself. That means, artifacts have to either be present in the source code repository or be pulled from it during the application build process. This becomes cumbersome with frequently changed rules; every rule change necessitate adding or modifying the rules artifacts, building the application code, and deploying to production servers.
DRL rule uses Java data objects to retrieve facts or a set of results. Like DRL rules, creating and using new data objects also necessitates code modification and deployment. As a result, Drools usually works well with a static dataset rather than a dynamic dataset. However, most real-world use cases require dynamic datasets for accurate decisioning. For instance, most account takeover decisions require multi-dimensional data about the user's activity history and recent actions, that are themselves changing rapidly under the covers.
This reliance on code—and the resulting build and deployment—both for rules and the related data, significantly slows down the speed of iteration of decisioning.
Besides limiting its effectiveness for solving real-world problems, this also slows down response time for business decisioning.
Redundancy and inefficient management of rules
The same business rules may apply across different applications and services, leading to redundancy and governance challenges. Drools imposes the burden on the user of keeping the rules and DRL files in sync. This necessitates building tooling to manage rules in a source code repository along with a rule service that manages updates and serves rules, which requires ownership and maintenance of a centralized rules service. Furthermore, the rules service must test and assess possible side effects of every rule change, which itself imposes a significant burden on the user of Drools.
Limited expressiveness and steep learning curve
Drools has its own Java-based DSL with a non-trivial learning curve whereas majority of the data science community has a Python background. The Drools DSL is also limited in its expressive power. For instance, Drools has limited support for some common math functions such as factorials, greatest common divisor that are useful in practice. To address this challenge, Drools allows the development of "custom DSLs", but again, they are limited by the underlying rule support.
Building a modern Drools based business rules management system
Given the understanding of the challenges imposed by Drools, let's look at what's missing in Drools to make pragmatic application of Drools easier:
Rules Database: A way to store all the rules outside the application binary in an external system such as a database.
Rules Service: A rules service with a REST API that programmatically rebuilds Drools objects based on changes in rules, thereby eliminating the need to modify code. Such a rules service must also enable rolling out new changes to rules quickly without deploying or restarting applications. Thereby, it must build source code management of rules coupled with a CI/CD pipeline to push changes to the central rules database.
Knowledge or Feature Database: A way to integrate feature data across third-party tools, databases, data lakes and other applications into a central feature database, eliminating the need to store all the facts that rules use in memory and powering the ability to backtest new rule changes.
Feature Service: A central knowledge base or feature service with a REST API that accepts features or facts in a common format and responds with any data required by the rules.
Rule Analytics: Central management and monitoring of rules to assess their performance over time to know when to evolve them.
Canary rollout: Any pragmatic use of a rules engine for production requires careful rollout of new rules. This process starts with backtesting rules on past data, followed by deployment of the rule in shadow mode, followed by a gradual canary rollout of the rule before it processes 100% of the available data.
No-code automation: A UI that allows business analysts and any non-developers to easily evolve rules based on new signals and use cases, without writing any code.
As might be clear from the description above, building a modern business rules management system—or decision engine—is a substantial proposition requiring deep expertise.
Conclusion
Drools is a good but low-level abstraction for a rules engine and not a modern business rules management system. As such, it necessitates building numerous capabilities in order to turn it into a comprehensive decisioning solution.
Oscilar is a no-code real-time modern decision engine. It automates custom fact or feature creation, enrichment and analytics, combined with a rules engine that runs rules synchronously or asynchronously, and offers an easy-to-use UI to go from new feature to new rule in minutes.
