Most business processes require business rules to decide the best next activity or another business process that should be followed.. Workflows, which automate business processes typically include several decision points. “Is this a new Customer?”, “Has the customer enough credit?”, “If the age is above 50?, “Is there any trouble ticket created for this user before?” These are just a few examples that represent business rules.
Typically, these business rules are bundled into the Application code. So, if you want to change the business rule, you need to upgrade your application. This is not a very feasible method. Alternatively, if you just need to change a value of a parameter, you may also want to implement a solution that needs you to edit a configuration file or a database table.
Another problem arises in here. Business users (Marketing, Sales, Strategy etc.) are the main parties that manipulate the business rules. However, these people are not technical and they do not know how to change a parameter in the application server configuration, or recompile the code. Because of this, they rely on IT to do this job. In today’s competitive environment, where rules need to be changed everyday, business users demand more from IT to implement new rules or change the existing ones. This puts a heavy burden on the top of current IT operations.
What if the business users would be able to change the business rules without consulting to IT? This will definitely bring agility, flexibility and lower IT operational costs.This is possible via Business Rule Management Systems or BRMS.
Business Rule Management Systems aim to externalize the decision logic from the application. BRMS involved architectures, include a separately installed BRMS server that work in conjunction with the application server to accomplish a specific task. In the code flow, whenever a decision needs to be made, the application consults the BRMS server about the result of a decision. After receiving the result, the code continues to move forward.
Applications interact with the BRMS servers over standard interfaces, mostly web services. These web services are run by the rule engine that is responsible to run the required rule against a set of parameters. There are multiple rules that are managed by the BRMS system. These rules are kept in the Rule repository and can be changed via business users.
In order for business users to change the rules easily, BRMS platforms also provide tools that eases rule authoring. Most BRMS solutions employ a dictionary that maps the rules to common words. This way, user will have the option to write the rule in plain English, such as,
“if the income of the customer is more than 1000
then
allow customer”
Decision trees and tables are other types of methods that shields the business users from technical details.
One note in here: Moving to another web service protocol stack will slow down the code. That’s why BRMS systems are well suited for business side processes which allow certain delays in the code execution.
Another note for session handling: The BRMS systems are stateless. That is to say, each rule is run separately, without taking into account the previous results of the queries. The state full behavior should be implemented by the application itself. (or a complex event processing engine)
Typical use cases where BRMS systems are utilized are;
– Order decomposition
– Client side validation
– Credit Checks
– Availability Checks
– Pricing
– Customer experience differentiation
There are lots of BRMS products on the market. Some of them are open source, some commercial; but idea is the same and promising.