thinking in rules

Back to Basics II: What is a Business Rules Management System?

Peter Fudalej | 7/24/2017

And… we’re back with part two of our Back to Basics blog series! For those of you who missed part one, where I explained what a Business Rules Engine (BRE) is, you can catch up and read it here. In part two, I will answer the question, “What is a Business Rules Management System?”

Jumping Back In

A Business Rules Management System (BRMS) is a complete solution for everything related to business rules and includes multiple components for authoring, testing, storage and execution. In this blog post, I will examine each component of a BRMS. By the end, you will have a firm understanding of what a BRMS is and the problems it can solve.

The authoring tool is an important component of a BRMS as it allows users to write business rules. At InRule®, we call this tool irAuthor®. Typically, most BRMS’ offer multiple ways to write business rules, making it fast and easy for users to write a business rule or a rule application, which is a collection of business rules. Some options for business rules editors include:

  • Business language rules editor - provides a point-and-click, menu-driven interface to author business rules using custom templates with natural logic and language native to the organization

  • Decision table editor - streamlines large sets of related business rules in a multi-dimensional matrix by combining multiple conditions and actions

 

  • Syntax expression designer - allows rule authors to express calculations and complex conditions with expressions, formulas or built-in functions, similar to Microsoft Excel

  • Rule flow - provides the ability to diagram a specific, high-level sequence of conditions and subsequent actions for rule execution into a graphical representation of a ruleapp using drag-and-drop controls

These rule editors are used to create business rules that represent use cases or decisions specific to the user’s business and can be configured to meet the user’s needs.

After the business rules have been written, users will want to ensure they are accurate. Therefore, testing is the next essential step in the business rule lifecycle. The business rules testing tool in InRule is irVerify®.

In the testing stage users use the tool to confirm that their business rules are executing properly. They should be able to do this in numerous ways including unit tests or regression tests. You can also view logging information captured by the rule engine during each test execution so users can review individual rule results, state changes or final decision results, all at the push of a button.

After testing the business rules, it becomes imperative to store them. Storing and saving business rules in one centralized location ensures the integrity of the rules and guarantees everyone within the organization is working with the latest version.

Rule storage consists of two parts: a database and a web service. The database is the repository and the web service will be the mechanism used to communicate with the database and retrieve the business rule application. Changes to rules are logged in the database, so users can view the history of a rule application and see who made changes and when they were made. This “single source of truth” for business rules ensures consistency and transparency. At InRule, we refer to our storage tool as irCatalog®.

The execution component of a BRMS is the business rule engine (BRE). At InRule we refer to it as irServer®. As stated in my last post, the BRE executes the business rules or decision logic, separately from application code. The BRE reads the rule application to determine which rules it should execute and which rule it should start with. The data is located and transferred from the storage component, or irCatalog. When the engine finishes executing the rules, it spits out the resulting modified data.

BRMS in Action

A complete BRMS offering can appeal to many business applications across a range of industries, including insurance, healthcare, financial services and the public sector.

To give you a better example of how this might work as a real world application, I’ll pick up the example from my last post, and discuss how a BRMS might work in a loan processing application.

A loan officer uses the authoring tool to write a rule to determine whether an applicant will qualify for a loan. Since this is a pretty straight-forward rule, the loan officer uses the business language editor to create the ruleset.

The loan officer uses a couple of fields like age, debt total, length of credit history, and credit score for the rule. Using these fields, the loan officer creates a ruleapp that says if the loan applicant’s age is greater than or equal to 18 years old, their debt is less than or equal to $20,000, their length of credit history is 5 years or more, and their credit score is greater or equal to 550, then they will be approved for the loan. Below is what this rule looks like:

Now the loan officer needs to test the ruleapp to make sure it works. Using irVerify, the loan officer can test this ruleapp by entering in a few data points for these fields. For age, the loan officer enters 25, credit score is 650, debt comes in at $10,000, and length of credit history is seven years. When the loan officer applies the rules and tests them, the status comes back as “Approved” - this ruleapp works!

Now let’s look at where these rules will live when they are not in use and where the loan officer can track the history of their changes. Below, you can see them sitting in irCatalog, our storage component. From here, our loan officer can check the rules in and out and monitor the latest changes made to these rules. This will help provide consistency and transparency for the organization.

The last component, which is difficult to show in a blog post, is the actual rules engine, or irServer. This component was put to work when the loan officer ran the rules to see if the loan would be approved. The rules engine received the ruleapp and called out to the storage component where it read the data and executed the logic. Since we saw the rule fire back the correct output, we can see how this component works.

And… that’s it! You have now learned about a BRMS and how it is applied to real world business applications. You can now tell your friends you understand what a Business Rules Management System is and how it includes not only the execution engine (BRE), but also capabilities to write, test, and manage business rules. With all of these capabilities, the benefits of a BRE extend to not only developers, but also business users.

One more thing, if you are interested in learning about what types of applications the InRule BRMS can be integrated with, I encourage you to check out our products page! While our BRMS was originally built on .NET, you don’t have to be a .NET organization to use InRule. With today’s service-based architectures, InRule integrates with almost any type of application (desktop, web, mobile) or platform (Microsoft Dynamics®, Salesforce®) and can be hosted on-prem or in the cloud (Microsoft Azure®).


comments powered by Disqus