In just about any business, one will encounter rules. They may not necessarily be called “rules,” but they almost certainly exist in the business’s day-to-day operation. These rules could be as complex as an insurance company using myriad factors to determine a policy quote, or a retail shop having a return policy. While a small “mom and pop” store may not need any kind of computer system to process the occasional return, a Business Rule Management System (BRMS) is invaluable for managing the complex policies of larger enterprises, especially if rule processing needs to be understood or administered by business users as well as IT.
A business rule can ensure that day-to-day operations are handled in the best way depending on all the relevant factors for each business situation. An example can be as basic as “If the status of a customer is gold, then the customer is eligible for a room upgrade” or far more complex, using multiple factors in different combinations to make a single decision. An airline could make its less expensive fare restrictions based on time of purchase, travel period, origin and destination, whether the itinerary has a stopover or Saturday night stay, and perhaps some astrological occurrence – just for good luck.
Business rules are designed to be flexible so they can be used in nearly any industry. If the business entities can be modeled (e.g. a customer has an age, a gender, an address, etc) and business policies can be expressed using these models, a BRMS can be used to improve the consistency, transparency, and agility of business operations.
Of course, every tool is made for a specific purpose. While a BRMS is great for processing business rules, there are still situations where other options should be considered. For example, you could have a “rule” like this:
If the database is down, then display the error message “Cannot display this page, please try again later.”
Yes, a rule could be created for this but unless the action to be taken when the database is down is considered a business decision, a BRMS would not usually be involved in generating an error message.
Another example could be a statement like this:
Increase customer loyalty by giving more benefits to loyal customers.
This is certainly something you may hear in a department driven by the business but ultimately it is more of a strategy than a rule. However, specific rules guiding daily operations could certainly be written to implement that strategy.
When properly used, a BRMS will maximize collaboration between people in the business and IT areas of an organization. Because these departments will use different tools and terminology to perform their work, it is important to choose a BRMS that emphasizes the following features to bridge that gap and manage distribution of responsibilities:
Vocabulary and Language: Business users will work with their own spoken language, such as English, and terms used in their industry. While IT workers often read, write, and speak “code,” some people may not realize that IT users also communicate with one another in a spoken language, such as English. A proper BRMS will maintain a standard set of vocabulary that is understood by both business users as well as IT. This includes data models (“the age of the customer”) as well as how the data is used (“if the age of the customer is less than 21”).
In an international organization, there may be a need to use different spoken languages. In those cases, the BRMS should be able to support translations of the business model to provide a clear understanding of rules for all users, without any language barriers.
Rule Execution Orchestration: Sometimes rules are only evaluated in certain situations. For example, a mortgage may only need insurance rules performed if insurance is necessary. It is important that everyone have access to this process just as well as the rules themselves to maintain agility and to ensure that there are no misunderstandings about when a rule will be executed.
Controlled Accessibility: Having business-friendly features is a moot point if the users have no easy way of accessing them. A BRMS should have turnkey features to provide this, with additional configuration options to grant CRUD (Create, Read, Update, Delete) and other advanced permissions for any combination of groups, so that each user has the access necessary to do their job, while being restricted from areas and activities out of their scope.
