Many can argue that the reason why software applications exist today is because of business rules. And, as applications become more robust and sophisticated, it becomes more important to consider how your system is managing them.
As business rules become more complex, it typically translates to higher development costs, longer timelines, and more releases and deployments. And, if your system’s business rules are baked into the code, developers are required because they are the only ones who should make software updates.
Enter Drools
Drools is a Business Rules Management System (BRMS) solution. It is a Java-based, open-source project backed by JBoss and Red Hat. It allows solutions to separate data and business logic.
Implementing Drools requires two things: authoring and runtime. Authoring is the creation of rules files, and runtime involves working memory to execute the rules.
But rather than go through a development tutorial detailing how to create a solution, let’s dive into how a Drools Decision Table can be used to create a rules engine that is isolated, dynamic, and cost effective.
Isolated Rules in a Spreadsheet
Authoring rules for a Drools Decision Table are done in a spreadsheet file (.xls). Thus, rules are isolated from static business and system logic.
Keep in mind that decision tables are only a good option if rules can be represented in a rule template and data. Each row in a decision table is a separate rule with separate conditions:
The first rule can be read as this: If Segment Code is 5, Travel Type is B, State is NY, Impact Type is DELAY, and Delay Time in Minutes is between 121 and 10,000, then issue a reward of 10,000 points.
Because the rules are authored in a spreadsheet file, you have more control over what data elements in the rules are configurable.
For example, imagine State is a data element in a condition. The rules only apply to the state of NY, because there are only NY customers. Because the rules are managed in a spreadsheet, the State column can be hardcoded to NY and made hidden so it cannot be altered:
Also, you can restrict a list of options available for a condition by using the data validation feature in Excel. If TX is now available as a state, a spreadsheet cell can restrict only NY and TX values:
Rules are Dynamic
The Drools rules solution is dynamic. Meaning rules can be added and removed at runtime while the engine is still populated with data.
Rules can be created on the fly and picked up by the application without requiring a release and deployment (I still recommend version controlling your decision tables). This can speed up testing as business analysts can change the rules and re-execute tests without requiring development and downtime.
We implemented a solution on AWS for one client that would watch the rules file on an EFS. If it changed, it was reloaded and went live immediately. This allowed the client to make quick changes to business rules in response to frequent daily operational changes.
Rule definitions are flexible. Attributes that you can set include:
Priority – The “satience” value of a rule.
Duration – How long the rule will last.
Enabled – The enabled state of the rule.
Timers and Calendars – Timers with start and end dates.
Activation Groups – Grouping so that only one rule will fire and cancel any existing activations of other rules within the same group.
Business Rules Engine With Cost Savings
If business rules are hardcoded into the application, it requires developers to make changes and then juggle release management, scheduling, and deployments. Additionally, if the business rule development does not work, you must repeat the release and deployment cycle all over again.
If a Drools decision table solution is implemented correctly, you can potentially bypass the additional development, release, and deployment work. Since the rules are authored in a spreadsheet format, a business analyst who is comfortable with spreadsheet software and features can design, implement, and test without the additional overhead.
This reinforces an ideal separation of concerns. Decision tables via spreadsheets facilitate collaboration between development and subject matter experts, as well as making business rules clear to business analysts.
Rules Are Meant to Be Managed
Once a system has an established business rule engine and framework, rules become a lot easier to manage. You can use this framework to:
Route loans to certain queues based on applicant data and application status.
Automatically reward customers based on inconvenience, reward preference, and segmentation.
Score insurance claims.
Create a pricing tool.
Set Black Friday pricing to start and stop on specific dates.
Theoretically, you can use a Drools Decision Table to create a Drools Decision Table to be used for another business rule engine.
The most important step is finding a partner firm to lay the foundation. If you have questions regarding how to lay the foundation, how this framework has benefitted our clients, or if this strategy can benefit you, please reach out to us at findoutmore@credera.com. We’d love to assist you in creating a system that will… rule.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
