Selecting the right business rules engine or BRE in short is always overwhelming. If you are at the beginning of this journey, you will have so many questions. If you have used any rules engine before, the technology has evolved so much. Either way, you need a guide on what to look at and what to evaluate. This article attempts to give you that guide and explain what things are important as part of your selection criteria and why.
How to Choose a Business Rules Engine – BRE?
Business rules engine allows your team to extract business rules from the applications and processes so they can change them later with more flexibility. Additionally, this enables non-technical staff to be able to manage business rules. Which essentially means a non-developer can create, test, debug and understand business rules independently.
But the need to make rules flexible is hardly the only thing that will be needed. What you essentially need is to make the whole process (including rule modification and creation) flexible. This involves rules modeling and execution, as well as many other steps before and after business rules creation and execution. Business rules engine (BRE) is a component of Business Rules Management System (BRMS) and the next generation of that category which is called Decision Management System (DMS).
You need to think about many different aspects of immediate and future needs while answering too many questions, such as:
- Do you actually need to buy a rule engine (or BRMS)? Or do you need something more comprehensive that covers different needs of other team members as well?
- How do you deal with data structure, data connectivity, and data processing logic changes?
- What components in your application are responsible for handling data and processing them for rules execution?
- What if you need to have more dynamic workflow, customer journey etc. to deal with border scenario rather than only rules?
- How do you enforce the rules execution as part of a process?
- How do you extend the business rules?
- How are you going to integrate and execute rules into applications?
- Do you need a development team to extend the rule engine capability?
- Do you mind that vendor has access to your data? and how are those data collected, processes and stored?
- Do care about vendor locked-in? A proprietary language and sub-optimal UX.
These can be overwhelming and somewhat very hard to know when you are at the early stage of this journey. We aim to put together a high-level guide on what are the different aspects of rules engine that you need to look at.
Maybe you may not even need to buy any rule engine at all, and it can be just fine for you with a FREE and open-source options which we are going to discuss based on your technology stack.
So, let's look at the decision criteria of your business rules engine…
Ease of Use
Ease of use is very subjective and always depending on how familiar you are with a platform. It is not always as easy as seeing if a platform supports drag-and-drop! Even when you work with a platform you cannot determine how easy will it be for other people in a long run.
Having said that, there are elements that you can check to determine if the platform is easy and will work outside of IT and software development team.
Familiarity in UI
One thing that makes using rule engine easier is familiar user interface. For instance, what is more familiar than Excel to anyone? So if you allow users to model rules in such user interface it will make their life easier and they already familiar with how it should work. Therefore, there is a very little learning curve.
Familiarity in Business Terminologies
Rules are based on business glossaries and your business terminologies. What if you could write and execute business rules in your own domain specific language? That makes it very easy for end user as it is very natural to them to speak and live those terminologies all day long.
Point-and-click to write rules: Natural Language editor that allows you define your own DSL and create business rules using your own business terminologies and glossaries.
For instance, you need to be able to define business glossaries and terminologies and use them to create, edit, update and execute business rules. Natural Language is a very easy way of building business rules.
Standardized technique and UX
Standardization means you can leverage the best practices of the industry. So if the platform is Decision Model and Notation that means your user can leverage the best practices of designing complex rules and therefore not only they can have a seamless experience in designing rules but also, when things get complex, it does not break their workflow and how they get things done.
Low-code and No-code
It means the platform is designed for the non-technical staff to create, test, execute and deploy business rules. Will they do it? Sometimes yes, and sometimes no. Depends on the team, people, and organization's culture.
Additionally, main challenges of developing rules using a rules engine is not always about empowering non-technical staff or business to do it. It sometimes is about clear communication and the same understanding about the decision-making driven by business rules.
Then, the platform is Conformance Level 3 of Decision Model and Notation (DMN) which means not only the best bred of low-code/no-code for rules modeling execution but also
- help all stakeholders understand a complex domain of decision-making using easily readable diagrams
- provide a natural basis for discussion and agreement on the scope and nature of business decision-making
- reduce the effort and risk of decision automation projects through graphical decomposition of requirements
- allow business rules to be defined simply and reliably in unambiguous decision tables
- simplify development of decisioning systems using specifications that may be automatically validated and executed
- provide a structured context for the development and management of predictive analytic models
- enable the development of a library of reusable decision-making components
That's the power of Low-code and No-Code based on Decision Model and Notation with Conformance Level 3.
Modeling Methods
When it comes to business rule engines (BRE) it's very tempting to assume everything is a rule. But in fact, rules are just one type of logic these engines should handle. Additionally for each type of logic they should provide multiple approaches which the compound the ease-of-use as each individual might have their own preference.
Rule Logic
Business rules are the combination of “conditions” or “inputs,” and when the conditions are satisfied, the “actions” or “outputs” are determined. There are different types of business rules, each different in nature and structure. Therefore, it is important that the platform provides various modeling techniques for rules, such as Decision Tables, Natural Language, Tree-Subtree, and more.
Non-Rule Logic
Other types of logic are important for a BRE to handle. When it comes to domain knowledge, the formulas, calculations, procedural logic etc., are significantly important. The business rules engine (BRE) should allow them to be modeled and executed outside of the application code or process – without developers' involvement.
Otherwise, the whole purpose of BRE is in contradiction. Modeling this logic requires specifying Expressions, Functions, and Boxed Expressions to make them reusable and modular. These will allow non-technical domain experts to specify complex domain logic, like payment formulas, rate calculations, etc., within the BRE itself, similar to what they would have done in Excel!!
Definitions and Terms
Rules and non-rules logic should be based on business terms and glossaries, as well as data and fact structures. This type of modeling allows the end user to create dictionaries for business terms, glossaries, and fact concepts to be used across different rules and cross-projects at the enterprise level. Business rule engine (BRE) must enable non-technical users to define domain and terms related to the business.
Extensibility
During Proof of Concept (POC) and trial things are easy. Your scope is limited and almost always all vendors can show you how things are done. easy-peasy. In the real scenario scopes will be changed. Different aspects of integration, reusability, deployments and extending the rules engine capability will come to picture. Make sure you will look at extensibility of platform from below aspects.
Executing custom code
Make sure rules engine can execute custom code such as C#, Python and JavaScript. This enables your development team to extend the functionality of rule engine when needed using the vendor SDK.
Extending without code
Although often SDK allows your developers extend the rule engine. However, most of the times you use rules engine to reduce the burden from development team and get things done as quick as possible. Therefore, you need to be able to extend the business rule engine (BRE) capabilities without coding and SDK.
Orchestration
Imagine you write business rules and test them. They do not run in isolation. They need to collect data from users or applications, access databases and services, process the data and transform them on the fly, pass it to the rules for execution, and create the outcome the consumer needs.
Example of orchestration that connects to database and calls REST api.
Rules engine just does the middle part. When things change, you hardly need to ONLY update the business rules; you need to adjust things everywhere, and that's why an advanced orchestration is very critical to ensure you still get the benefits of extracting and executing rules outside of your application and process.
Quality Assurance
To ensure business rules are behaving as expected your desire platform must provide multiple capabilities. All of them go and in hand for the Quality Assurance of your project. Your authoring platform should provide all the below capabilities to make it painless for users to change and update rules, but also inspect and analyze misbehaviors.
Simulation
Executing business rules against one or more inputs and checking the values and outcomes. Being able to compare results of multiple different data points at a specific timing to ensure your rules will behave as expected. Or to ensure the impact of your new changes on existing data points.
Test
Building test cases and test scenarios and executing them as part of QA and change management scenarios. You need to be able to run tests as part of CI/CD automatically as well as manually in groups or one by one.
Live Debug
When you change business rules the outcome of the decision they are involved will be changing. The end-user of the platform should be able to step in and run the rules one at a time and enable you to inspect inside the values and context to understand what is going on.
Live inspection of values while changing and evaluating them on-the-fly.
Capability such as live inspector, breakpoints, step-in, step-over etc. are critical part of authoring platform when it comes to troubleshoot misbehaviors.
Data Integration and Processing
Your application needs to pass data to business rules engine (BRE) for processing and making decisions. But not all applications have all the data available. Even if they have, it is very sub-optimal for applications to get the data (retrieve) and pass it to rules. Rather, a better approach is for the engine to be able to deal with it. As a result, your application just passes reference data such as an identifier, e.g., customer id, policy number, etc., and the rules engine does the rest.
The advanced data integration and processing ensure your application does not need to do all the plumbing and data retrieval in the first place. It makes your application simpler, more flexible and the automation of rules more independent, therefore, more reusable and dynamic.
Deployment and Operation
Operationalizing generally has multiple aspects to it. From deployment options to monitoring, measuring, analyzing, and identifying best performing versions. Last but not least, it comes to how you need to operationalize the business rules. There are multiple options based on what your requirements are.
SaaS platform
Meaning vendor will run it for you, but then you are going to share your intellectual properties (IP such as rules, policies etc.) as well as your proprietary knowledge and sensitive data with the vendor.
Private SaaS (managed)
Meaning vendors run the platform for you on your own private cloud or data center.
Serverless
Which is when you deploy rules without worrying about infrastructure to your own cloud provider as a function, i.e., Azure Function, AWS lambda, and Google Function. This is an easy and cost-effective option, and you won't share anything with the vendor.
On-Prem
It means you can set up an infrastructure using containers, Kubernetes, VM, etc., in your data center or your private cloud to execute business rules.
CI/CD Integration and Version Management
For all of these options, the integration through CICD is critical so your new platform and tools will be easily fit into your existing change management process. Additionally, it means the repository and version management of rules should be better done via the standard repository such as GitHub, Azure DevOps etc. and version controls that your organizations already leverage.
Measure Success and Outcomes
When you change business rules, outcomes will be changing. Therefore, you need to make sure not only you can measure the outcomes but also, can run multiple versions of them in parallel and be able to safely and gradually roll out the change.
Methodology and Process
To choose a Business Rules Engine (BRE) it is not enough to only focus on the technology requirements. It is critical to understand overall process of how to implement it in your organization. Because when you start on a business rules project early on, you may feel to follow the same process as you do software development. You can, but you should not. For example, you can write user stories for business rules but has no value.
Alternatively, you can start modeling business rules straight away, but you will face orphan issues as a set of rules that are isolated and have no use. Or you will face the problem of the big bucket of rules problem.
You need a new methodology that is based on business outcomes. You need to think about business decisions rather than business rules. This is called Decision-Centric Approach. It is a methodology that brings people, rules, data, and processes together to ensure organizations can consistently make optimized, customer-centric, and situation-aware business decisions while they meet the objectives on revenue, costs, and mitigating risks.
Use cases for Rule Engine
It may seem obvious that there are many use cases for a business rule (BRE) engine. But you need to pick the right fight; otherwise, you apply a solution that is either too big for the problem or not a good fit.
Here are the criteria that you need to look at
- More than a handful of rules must be involved. My rule of thumb is more than 50 rules. When I refer to a rule, I don't mean the whole decisioning scenario, just the individual business (or system) rules.
- The nature of rules should be based on regulations, policies, and customer demands etc. They should change at least a couple of times a year. Otherwise, if you set it up and they don't change, well, you may not need a rules engine.
- If they don't change, they must be complex at least and interconnected to drive critical business operations such as audit, compliance, underwriting, pricing, product setup and configuration, etc.
- They require domain knowledge rather than technical knowledge, such as engineering or science, or things like configuration, claims, underwriting policies, etc.
Industry use cases
There are various use cases in various industries:
And for sure, many use cases are cross industries such as Validation, Data Quality, Pricing, Customer experience personalization, etc. and more. Depending on the complexity of the use case the business rule engine (BRE) needs to do more than just simple if-then-else execution.
Conclusion
If you feel that the only thing you need is to make your business rules using a BRE flexible and modular, do NOT buy a rule engine. There are free and open-source versions are available
- Java technology:
- Drools
- .Net technology:
- GoLang
But that's hardly always the case. Your project grows, and your requirements evolve despite the fact that when the project was started, you felt it was a simple project. Start small, think big, to understand the full requirements. Otherwise, it becomes too late if your preferred platform is not DMN Conformance Level 3. Therefore, you will be locked in, and you will need to start fresh.
The goal is to make business rules become the productivity and efficiency component of your applications and processes, which means:
- The approach to how to manage business rules are crucially important, and if you do start with rules you are going to suffer the big bucket of rules problem.
- Standardization, such as Decision Model and Notation with Conformance Level 3, is important as it makes you the owner of your domain knowledge
- Authoring environment is critical for Ease of use, Live debugging, toolsets around deployment, and QA
- Advanced capabilities such as orchestration, data connectivity and processing, CICD integration, and a wide range of deployment options will become handy as your requirements evolve
Book a Custom Demo
Last but not least, standardization based on DMN Conformance Level 3 that ensures BRE platform is easy to learn and easy to be adapted in your company for a wide range of end-user. Additionally, it also ensures it is an extensible platform even without the need for SDK and developers' involvement.
Our platform meets all the criteria we discussed in this article. If you are interested to learning more, please keep in touch.
Last updated November 3rd, 2025 at 11:23 am Published January 29th, 2025 at 03:20 pm
