January 13, 2023 | 3 min read
Why you should consider adding a rules engine to your tech stack
Mario DiBenedetto
Managing Director
One of the long-running themes in the technology industry is the componentization of technology. In the context of the software you use everyday, this means taking each piece and breaking it down into smaller, independent components without you knowing (or caring) that they are, in fact, separate components. The ultimate goal is to make the software development process faster without adversely affecting your experience. Componentization achieves this goal by:
- Improving maintainability: Componentization can make it easier to maintain and update individual components of your stack without affecting the rest of the system. This can be especially useful if you have a large, complex technology stack.
- Enhancing scalability: Componentization can also make it easier to scale your technology stack. By breaking your stack down into smaller, independent components, you can more easily add or remove components as needed to meet changing demands.
- Increasing flexibility: Componentization can also increase the flexibility of your technology stack. By creating independent components, you can more easily mix and match different components to create customized solutions that meet your specific needs.
- Enhancing security: Componentization can also enhance security by limiting the impact of any vulnerabilities that may exist in individual components. If a component is compromised, it is less likely to affect the rest of the system if it is properly componentized.
One of our favorite macro componentizations is the introduction of a rules engine. We say “macro” because the actual integration of a rules engine can be broken-down into many sub-components.
Let’s start with the basics…what is a rules engine and why do we find it useful?
A rules engine is a software application that processes a set of rules to either provide a recommendation, take an action, or provide an answer to a question. This is not to be confused with a workflow engine, which is a software system that allows you to automate and manage the execution of business processes, which often involve a series of tasks that need to be performed in a specific order. Some benefits of using a rules engine include:
- Improved efficiency: By automating decision-making processes, a rules engine can help organizations save time and resources that would otherwise be spent on manual decision-making.
- Increased consistency: A rules engine can ensure that decisions are made consistently, based on predefined rules, which can help to reduce the risk of human error and increase the fairness and transparency of decision-making.
- Greater flexibility: A rules engine can be configured to handle changes to rules or to incorporate new rules as needed, which can help an organization to adapt to changing circumstances or requirements.
- Better accountability: A rules engine can provide a clear audit trail of the decisions that it has made, which can help organizations to be more transparent and accountable in their decision-making processes.
- Enhanced customization: A rules engine can be tailored to an organization’s specific needs, allowing it to make decisions based on the rules and criteria that are most relevant to the organization.
Each of the above bullets could be a rationalization on its own for using a rules engine. The biggest value we see with introducing a rules engine into your tech stack is that you get these benefits together. A rules engine can bring order to chaos. It can bring agility to a clumsy process. It can simplify change.
What’s the catch?
The opportunities to use a rules engine are so varied that it can be daunting to figure out how to leverage it effectively. As with all software, the best answer is to start simple. If you try to solve too many problems at once, your risk of failure can increase dramatically. For example, we like to start with a simple use case where a rules engine is used to perform workflow validations. This use case is interesting because it can introduce the concept into your environment without too much disruption. But even this use case has a lot of overhead the first time you implement it. That’s a reason to engage a company like Brimma…we have already dealt with the initial overhead and can help you realize the benefits quicker.
Regardless of the use case you pursue, another reason to start with minimal disruption is that the introduction of a rules engine is an exercise in software development. That is not to say you need to have software developers develop and maintain your rules; We have seen multiple instances where customers have line-of-business staff write rules. But whoever is responsible needs to take responsibility for standard software development best practices related to rules versioning, regression testing, production readiness planning, and code promotion. Without the proper procedures and controls around these areas, you are likely to create more chaos than benefits.
In fact, one could argue that it is not so much the rules engine that brings all of the benefits to your organization as it is the regimented processes that the rules engine enables. And here’s why: introducing a rules engine requires YOU to decompose your problem in such a way that you can efficiently, consistently, and flexibly manage your business. That, too, is part of the benefit of using a company like Brimma; We can help you to quickly envision your ideal processes and make sure you have the right procedures and controls in-place to succeed.
This point might be best illustrated by an example:
Imagine you’re a lender that maintains its own product overlays to GSE/investor loan products. As a part of this, you maintain a custom set of pricing adjustments related to borrower qualification eligibility or pricing adjustments.
In our example, let’s imagine that your current process is to pass spreadsheets back and forth with whoever maintains the product eligibility and pricing adjustments. By it’s very nature, a spreadsheet is not going to make versioning easy, so intended changes will likely get lost as spreadsheets are passed back and forth and people lose track of “current'' versions. Additionally, spreadsheet approaches tend to “send everything everytime”, which can be particularly cumbersome and hard to sift through without missing relevant changes. And, lastly, spreadsheets do not make it inherently easy to keep track of effective dates, particularly around individual rules that have morphed multiple times over time.
The attributes of a simpler process might be that you should only have to communicate the subset of what is changing each time you want to make a change. Furthermore, you might want a way to be able to audit your changes before you sign-off on them because a full regression testing of millions of permutations is not practical. And you likely would want the ability to introduce changes quickly without sacrificing quality controls. None of these inherently require a rules engine. But a rules engine combined with well thought-out processes can provide you all of this without the complications involved in the spreadsheet approach.
There are many companies that offer rules engine technology, including:
- Red Hat Drools, which is a Java-based open-source rules engine
- IBM Operational Decision Manager (ODM)
- Microsoft Azure Logic Apps, which is a cloud-based service
- InRule is a company that provides a rules engine called InRule for .NET
- FICO Blaze Advisor
In a perfect world, you shouldn’t have to spend a ton of time deciding which rule engine to use. If you listen to the sales pitches, each will have some unique features that will inevitably be deemed critical to your success. We are advocates of selecting the least expensive option that meets your infrastructure, security, and scalability needs. The truth is, you probably want to avoid using platform-specific features because it locks you into the platform.
If you’re still reading, you’re probably wondering “how hard is all of this to do?” and “what is the ROI?”. The answer to both questions can be illustrated by our favorite use case, performing workflow validations. One of the most compelling reasons to address this use case is that your systems do not apply a consistent set of validations throughout the loan lifecycle.
So, for example, your system might do a great job making sure you have sufficient employment documentation on a loan application when the documentation is initially assessed, but it may fail to apply the validation when the borrowers or borrower pairs on the loan change. Or when the loan product or investor changes and results in a different level of employment or income documentation being required. Most of you can probably rattle off a long list of similar scenarios that result in validation “misses” you have to monitor to avoid post closing defects coming back from your investors.
The expectation for a rules engine is that the same set of validations exist in one spot: a rule set within the rule engine. And that set of validations can be enforced in as many places in your process as is necessary to avoid those post closing defects. It’s not a huge leap to suggest that this approach is going to (a) reduce post closing defects, and, more importantly, (b) help avoid loan buybacks. If you accept that to be true, then the ROI math is pretty easy.
There are other ROI calculations like increased agility to adapt to changing business conditions, but they can be harder to use as the starting point. That's because, more than likely, the first use case will bear most of the burden for ROI for all of the start-up overhead.
Want to learn more about this topic? Comment on this article, visit us at www.brimmatech.com, or use this link to schedule a 1-on-1 session.
