Demystifying Drools: Architecting for Automated Decision-Making in Financial Institutions

In today’s fast-paced financial sector, automated decision-making has become essential. It helps institutions navigate the complexities of financial regulations and customer expectations with agility and precision. In this context, the Drools Business Rules Management System (BRMS) plays a critical role. Here’s how each component of Drools Rule Engine could work in that context:

1. KIE Workbench:

The KIE Workbench acts as the creative hub for rule development. For instance, a financial institution like a bank may set a rule for loan approval: “If a customer’s credit score is above 750 and the debt-to-income ratio is less than 30%, then approve the loan”. The analysts and developers will use the KIE Workbench to define and validate this rule before deploying it to the KIE Repository.

2. KIE Repository:

The KIE Repository stores and manages all the rules. Let’s assume the bank decides to change its lending criteria, raising the credit score requirement from 750 to 800. The revised rule will be updated in the KIE Workbench and a new version will be stored in the KIE Repository. This way, the KIE Repository maintains the different versions of the rules and processes for use.

3. KIE Server:

The KIE Server is responsible for fetching these rules from the KIE Repository. When a customer applies for a loan, the application data is passed to the KIE Server, which retrieves the relevant rules and evaluates the application.

4. KIE Containers:

The KIE Server loads rules into KIE Containers, each corresponding to a specific version of a rule or process. For example, during a promotional event, the bank may temporarily lower the credit score requirement to 750. The previous version of the rule can be loaded into a separate KIE Container and executed for the duration of the event.

5. Load Balancer:

As the bank services a large number of customers, it may need to process many loan applications simultaneously. To handle this volume and ensure efficient distribution of requests, a Load Balancer is used. It routes the requests among multiple KIE Servers, ensuring optimal performance and resilience.

6. High Availability Manager:

Given the critical nature of banking services, system downtime could have significant repercussions. The High Availability Manager ensures that the system as a whole remains operational even if a particular server goes down. It detects server failures and redirects the traffic to the other functioning servers, providing a seamless service experience.

7. External System:

Finally, the bank’s online loan application platform acts as the external system that communicates with the Drools system. When a customer submits a loan application, the platform sends a request to the KIE Server via a RESTful API. The Load Balancer receives this request and directs it to an available KIE Server.

To enhance our comprehension, let’s further explore the architecture diagram and see how these integral components interact with each other in the system.

1. An External System communicates with the Load Balancer using a RESTful API.
2. The Load Balancer distributes traffic to two KIE Servers (KIE Server 1 and KIE server 2).
3. Each KIE Server loads multiple KIE Containers (KIE Server 1 loads KIE Container 1A and 1B; KIE Server 2 loads KIE Container 2A and 2B).
4. Each KIE Container is labeled with the version of the rule it contains (e.g., “Rule v1”, “Rule v2”).This illustrates that different versions of the rules can be loaded into separate KIE Containers.
5. Each KIE Server has access to the KIE Repository. The KIE repository can be stored on a shared file system that all the KIE servers have access to, or it could be a distributed file system like Git that automatically synchronizes changes between servers. For HA, you would also want to have a backup system in place, such as regular snapshots of the KIE repository, to prevent data loss.
6. A High Availability Manager manages both KIE Servers.

This should give you a clearer picture of how a financial institution can leverage the Drools architecture for its rule management and execution needs.