What are business rules
Business rules are rules that define how a business responds in different scenarios. These decisions can be big huge strategy decisions (invest more in a certain geography), operational decisions (which vendor to procure raw materials from, how much discount to offer for different types of products), or more day-to-day decisions (which call centre operator to route a call to). Coming up with business rules is the stuff of the big league – CXOs, consultants, managers, big data, ML, AI, excel sheets, all of these come together at different levels to decide what rules should run an organization.
No matter how complicated the decision making process may be, all rules at all levels have something in common. They take a bunch of factors into consideration, and define what should be done for various combinations of these factors (e.g. If losses are high and cash reserves are low, stop hiring more people). In general terms, a rule can be expressed as a function mapping multiple parameters to an outcome.
func(param1, param2, param3) => outcome
In general, the parameters may be dynamically determined, and the expression combining all parameters could be very complex.
Much of software engineering is about codification of business rules in programming terms, using them to drive business workflows, and keeping up with the constant changes to them. Our technical systems have to support business decisions, and an important part of doing that is modelling of business rules.
Most business rules are simple
Coming up with business rules is a complicated process, filled with lots of trade offs. However, the rules coming out of this process are often quite simple. Very often, all of the brainstorming results in a simple 2D matrix with one set of columns representing decision parameters and another set of columns representing the different outcomes. The decision parameters are mostly set value and rarely dynamic, and the outcomes are also static values or real-world business processes.
In the pseudo-technical syntax we used earlier, practically speaking, rules are of the form.
[Param1 OPERAND some value] (combiner) [param2 OPERAND some value] (combiner) [param3 OPERAND some value] => outcome
In a vast majority of the cases, the combiner is AND or OR conditions.
Look at some typical taxation rules below. Here’s how you’d read the third rule:
IF [source state EQUALS “Karnataka”] AND [type of Sale EQUALS “Interstate”] AND [item type EQUALS “Jeans”] AND [MRP BETWEEN Rs. 0 and Rs. 500] => applicable taxes are 3%CGST and 3% SGST
This is one of the reasons why it is so hard to beat Excel in the corporate world – our mental decision making models map exceedingly well to the static columnar representation that Excel is wonderful at facilitating. This makes sense too. No matter how complex the rules are, business leaders need to be able to make sense of the rules that run their business. N-dimensional super dynamic rules would be difficult to express, explain, and validate when put into practice. So regardless of the complexity and sophistication of processes which come up with business rules, the rules themselves are tame entities.
What is a business rule management system
A business rule management system (or BRMS) is a tool for modelling, storage and evaluation of business rules as first class entities. A good BRMS offers expressive ways to model business rules, flexible ways to store and access them, and performant ways to make decisions on these rules.
Most BRMS use some sort of DSL (Domain Specific Language) to model rules. The DSL is typically a combination of condition checks (e.g. equals, greater than, contains) and combination operators (e.g. and, or) put together to compose rule expressions.
Why use a BRMS?
Technical systems must model business rules to serve the business, but there are two ways of doing it.
One way is to embed them inside the application logic. When this choice is made, business rules manifest themselves as if-else conditions or other forks in code. This approach is fine if we know that the rules are very few or trivial, but in the long run and a large system it always leads to messy code and repeated, futile refactoring to make things clean.
The second approach is to model business rules as entities in their own right, and to model the applications flows around them. When the architecture follows this style, we find that rules exist independently from the use of those rules. All parts of application logic refer to these rules to make decisions, meaning that the application doesn’t always know “why” it is doing something, because it is only doing what the rules tell it to do.
An easy check to determine which approach is being followed in your software is to take a business rule and ask how it is being implemented. If rules are being modelled as rules, you will almost always find some central repository or class or configuration containing them, no matter how rudimentary. On the other hand, if you find yourself chasing value based switch conditions all over the codebase, you know that the former modelling choice was made.
So what does the second approach get us, specifically?
Better communication
If rules exist as first-class architectural entities, it means that the tech and the business teams have a shared point of reference about what should be happening in the system. The two sides can easily come together to understand and evolve systems with common understanding of the business rule model.
Better rule management
Using a BRMS externalizes the rules form the application code. This decouples the “what to do” from the “how to do” and makes it easy to modify and evolve the rules independently from the application.
Rulette approach to rule management
Rulette is a BRMS that makes it super simple to model and evaluate the vast majority of business rules. If you find yourself modelling excel sheets with many column mapping to one column as output, or dealing with a large set of “IF something AND something AND something…, THEN some output” type of code, Rulette can take you from requirements to code complete in only a few lines of Java and SQL.
We have seen before how most (not all) rules are simple. Rulette embraces this reality by supporting a minimal modelling tool-kit and leaving out the rest. The Rulette model of a rule is as follows.
[Param1 EQUALS/BETWEEN some value(s)] AND [param2 EQUALS/BETWEEN some value(s)] AND [param3 EQUALS/BETWEEN some value(s)] => outcome
The only operands that are supported are EQUALS (price = 100) and BETWEEN (9 am < time < 2 pm). The only supported combiner is AND (because OR can always be achieved by defining two rules). Parameters (called rule inputs in Rulette world) can be string, numbers, or timestamps by default (open to custom extensions).