Business Rule Management Systems
An overview of BRMS, rules engines, inference methods, the Rete algorithm, and implementation considerations.
Business Rule Management Systems
A Business Rule Management System (BRMS) is software used to manage decision logic that is used by systems within a larger application, organization, or enterprise. The logic, also referred to as business rules, includes conditional statements, often in the form of IF-THEN constructs, that are used to determine the actions that take place within a system.
Usually, the logic is managed separately from core application logic so it can be managed and reused. BRMS may, and usually, contain numerous tools to manage and measure the impact of business rules.
A BRMS typically minimally includes:
- Decision logic externalized from core application code
- Tools to manage the decision logic
- An exposed API which invokes the business rules engine
A BRMS may be deployed within numerous industry verticals to serve any number of purposes related to business decisions. For example:
- Health care: clinical decision support, drug interaction alerts
- Retail: tax calculations, warehouse stock management, discount management
- Manufacturing: order configuration validation, customer-specific billing
- Travel: ticket pricing, loyalty programs
- Public sector: benefits calculation, tax fraud assessment, security screening
Business Rules Engine
At the core of the BRMS, in the same way a database is at the core of a Database Management System (DBMS), is a business rules engine. A business rules engine, also known as an inference engine, is a component of an expert system. Expert systems, and their underlying inference engines, were the first forms of artificial intelligence (AI).
A business rules engine may exist as a stand-alone system, which may be integrated with a BRMS, the same way a database may exist as a stand-alone application, which can be integrated with one or more DBMS.
Business rules engines, among other things, allow for the definition, management, and execution of business rules. A rules engine contains rules external from the application which utilizes them.
A pseudo-code example of a business rule:
If user is a platinum club member
Then apply 20% discount
Apply 5% discount
Business rules engines generally implement one of the following inference methods: backward chaining or forward chaining.
Backward Chaining Inference
Backward chaining starts with a list of goals (or a hypothesis) and works backwards from the consequence of the IF clause to see if there are data available to support the consequence of the IF clause.
Forward Chaining Inference
With forward chaining, a business rules engine will iterate through a process until a goal is reached. It searches through known facts until the IF clause is known to be true. When such a rule is found, the engine can infer the consequence, resulting in the addition of new information to its data.
For example, suppose the goal is to conclude the number of legs for a pet named Frank, given that he barks and eats milk bones. And suppose the rule base contains the four following rules:
If X barks and eats milk bones, then X is a dog.
If X chirps and X eats worms, then X is a bird.
If X is a dog, then X has four legs.
If X is a bird, then X is has two legs.
Assume the following facts:
Frank eats milk bones
With forward chaining, the business rules engine can conclude that Frank has four legs in a series of steps. Since the base facts indicate that “Frank barks” and “Frank eats milk bones”, the antecedent (IF clause) of rule #1 is satisfied by substituting Frank for X, and the inference engine concludes: Frank is a dog. And, additionally, the consequence of rule three, substituting Frank for X, is that Frank has four legs.
Most rules engines bused by businesses are forward chaining, which are divided further into two classes:
- Rules engines which process production/inference rules. These types of rules represent behaviors of the antecedent/consequent (IF-THEN) condition. For example, a rule could be applied as such: “Should this customer be allowed a credit card?” by executing a rule in the form of “IF customer credit score > 700 THEN allow customer a credit card.”
- The other type of inference engine processes what are referred to as a reaction/Event Condition Action rules. The reactive rules engine detect and react to incoming events and process event patterns. For example, a reactive rule engine could be used to alert a clinician when a certain patient is taking a particular medication that has been recalled due to contamination by a manufacturer.
The Rete algorithm is a pattern matching algorithm used with production rule system implementations. Using the system’s data store, it is used to determine which rule to execute. Even a moderate sized rule set, of IF-THEN statements and a corresponding knowledge-base, can perform much too slowly at scale. The Rete algorithm, first published in a working paper in 1974 at Carnegie Mellon University, provides the basis for an efficient implementation and underlies many modern implementations of business rules engines.
Implementation Challenges & Opportunities
Business rules are gathered in these situations:
- When dictated by law or regulatory agency
- During a business analysis
- As an aid to engineers
A consistent approach is often lacking in the definition and documentation of business rules. This may happen due to a number of causes, including, but not limited to:
- Need for multi-disciplinary approach to business process definition
- The large effort required to maintain the list of rules
- The cost of maintaining the list increases in situations where rules are rapidly changing
There are currently no industry-wide accepted standards to assist in the gathering and documentation of business rules. But there are currently multiple modeling approaches, such as:
- Unified Modeling Language
- Z notation
- Business Process Execution Language
- Business Process Modeling Notation
- Decision Model and Notation
- Semantics of Business Vocabulary and Business Rules
UX research opportunities and UI design opportunities will be present in three particular areas within the domain of Business Rules Management Systems.
- Rule definition and maintenance: Business processes are very often user experiences. UX practitioners will find ample opportunities to provide value when discovering, defining, and documenting business rules.
- Rule maintenance interface: In case it is not already clear, the actual rules engine and the system to manage those rules are abstracted as two different components within a BRMS. UI designers and implementors will find themselves primarily focused on making it easy for non-technical users to manage rapidly changing business rules without the intervention of information technology specialists.
- Analytics: Providing insights into the efficacy and relevance of business rules will support and enhance the economic case for implementing a BRMS.
Business Rules Management Systems provide a set of components and features to allow non-technical users define, maintain, and execute business rules. Business rules can provide the necessary information to make business decisions or to guide workflows. Most modern BRMS, and their underlying rules engine, use a forward chaining inference method, which is often supported by the Rete algorithm. There are multiple competing standards currently employed to document business rules, which can be a complicated and costly process. There are opportunities for UI and UX practitioners within the scope of business rule definition, business rule maintenance, and business rule analytics.
As businesses continue to operate in a decentralized and globalized manner, and as business operations become more complicated due to the ever-increasing capabilities of technology, the role of BRMS, and the UX/UI professionals who service the market, will have an expanding and very wide range of opportunities to provide value to decision makers.