Introduction

As a Business Rules Consultant, I have worked on multiple rule projects and I would like to highlight some of the common mistakes I have found made by developers in implementing solutions that employ business rules.

Business Rules are the backbone of any business process.  However, most of the time, the rules are either submerged within the process layer or within the integration layer; rarely do organizations realize the importance of the independence of their business rules.  Business rules need to be independent of the processes so that they can be easily managed and reused across many processes.  Increasingly, organizations have begun to adopt Business Rules Engines into their technology stack and are using them in their decision management solutions.  However, most of these organizations have not been able to get the full benefits hoped for.

The Business Rules Concept

Not everyone understands the core concept of business rules.  Too often developers focus on learning particular product features and fail to understand what is meant by 'business rules'.  So while a Business Rule Management System (BRMS) can play a vital role in a business transformation project, simply adopting a BRMS product won't, by itself, enable an organization to achieve real benefit.  To achieve any real advantage it is important to have proper solution design.  Technical consultants may be familiar with the product features, yet they might not understand the actual business problem.  Understanding the core concept of business rules will help in the design of better rule solutions.

Designing a business rule system is a joint effort that should involve the business users, subject matter experts, architects, and business analysts, from the inception stage to the final stage of the project.  In traditional systems development, the business analyst first gathers requirements from business users, and then the users are introduced to the end system during the user acceptance stage. 

This is not the case when designing solutions that use business rules — projects where business users play a vital role in the design.  They should be able to understand the underlying object model and the orchestration of the rules.  Unless they understand the object model, they won't be able to manage the rules.  If you are someone who is in the process of adopting a business rules approach, it is strongly recommended that you read Business Rule Concepts by Ronald G. Ross, which explains the concepts of business rules in layman's terms.^[1]

Major Components of a Business Rules System

There are many Business Rule Management System products in the market.  The core functions of BRMS products can be classified into two major categories.

1. Business Rule Engine — BRMS products normally use sophisticated pattern matching algorithms to execute the rules.  A pattern matching algorithm (for example, Rete^[2]) provides faster processing time by only executing the rules that match the state of the object.  Contrast that with traditional systems in which each and every rule is evaluated.
   
   
2. Management User Interface — The second core function is providing a rich user interface in managing the rules.

Common Mistakes in Rule Solutions Design

In many organizations, business rule adoption has either failed or been abandoned after the first implementation.  Here are some of the reasons:

1. Business users unable to see the differences between the traditional implementation and this new form of implementation
2. Management not achieving the estimated return on investment (ROI)
3. IT support team still facing the same challenges they faced in the legacy applications
4. Traditional SDLC process needing to be followed when making any rule changes

Typically, when designing rule-based solutions, the technical team will define the business terms, facts, and vocabulary, based on the business requirements.  In addition, the application needs a lot of supporting artifacts, a framework to facilitate the organization and orchestration of business rules.  The following sections will analyze some of the common mistakes during the implementation of solutions that employ business rules.

Complex Rule Flows

Rule flows are used to control the sequence/selection of rules based on specific conditions.  The organization and orchestration of business rules needs to be designed carefully.  The end solution should be designed in such a way that a non-technical business user can easily understand the rules and their execution.  Having complex rule flows controlling the execution of rules defeats one of the main objectives of rule-based solutions.

Consider a simple promotion engine for loans with the following set of requirements:

1. The system should process more than one loan application.
2. The system should support four different levels of promotion.
3. Only one promotion should be selected for an application.
4. If any one application matches the criteria for priority-1 promotion then all the applications in the transaction should get the priority-1 promotion.

Solution 1

Explanation

The rule flow is largely self-explanatory.

1. Each application is processed, one at a time, until a matching promotion is found.
2. When an application matches the criteria for priority-1 promotion, that priority level is applied to all applications.

The design is good, and it satisfies the specified requirements.  However, here are some of its hidden drawbacks:

1. The hierarchy is hardcoded; the business won't be able to change the hierarchy (say, adding a priority-5) without a code change.
2. Today's priority-1 promotion overrides other promotions.  If, in the future, the business user decides to change to favor priority-2 or -3, then the rule flow needs to be changed.  This is not desirable.

Solution 2

Explanation

Here the rule flow has been simplified into three simple steps.  The design will provide a vocabulary to set dynamic priorities and selection of the best promotion.

1. Pre-Processing — Identify the application type; an application might fall into one or more categories.
   
   
2. Promotions — Apply all promotions matching the categories.  Provide flexibility allowing the user to add more dynamic priority levels.
   
   
3. Post-Processing — Select the best promotion.  This can be the promotion that provides more (or less) savings.  Users will have more flexibility in selection of the best promotion.

Rule Chaining

Rule chaining is a good concept, but care needs to be taken.  Rule chaining will remove the atomicity characteristic from the rule.  One of the basic principles of a business rule system is to make sure each and every rule is atomic enough to explain its purpose.

Continuing with the promotion application example, when any one of the applications matches the criteria for priority-1, then the same will be applied to all other applications in the same transaction.  Here are two different implementation options, one with rule chaining and one without.

Solution 1 (with rule chaining)

1. For every application in the transaction, apply the promotion that satisfies the criteria specified in the rules.
   
   
2. If any one of the applications matches the criteria for priority-1 promotion, re-evaluate the other applications and make sure they also get the same priority-1 promotion.  Re-evaluation will happen when the same object is asserted (something of a technical term, which might make it difficult to explain system operation to the user).

Solution 2 (without rule chaining)

1. For every application in the transaction, apply all the promotions that satisfy the criteria specified in the rules.
   
   
2. In the post-processing, check whether any application matches the priority-1 promotion, and if there is then override the other applications with priority-1.  This can be achieved by a business rule, and if required it can be easily changed.

Implementation of Complex Business Logic

There are scenarios where a particular business rule requires a lot of calculations or complex logic.  In such cases, technical developers might be tempted to opt for hiding the details/complexity in a technical rule (or hidden function) and exposing them as business vocabulary.  However, since the implementation of such technical rules and hidden functions can't be managed by business users, this approach removes the agile characteristic from the solution.  Instead, proper vocabulary should be defined to break down the complex logic, which in turn helps externalize the business logic as user-readable rules.

Governance

Governing the business object model, vocabulary, and other aspects of rule solution development is very important.  Lack of governance will lead to a bad solution.  This principle is something that is not always accepted by agile developers, who believe a governance process delays the design and implementation of the solution.  Actually, a slight delay in the current timeline might help in adapting future requirements at rapid speed.  The Application Solution Architecture team can lay the foundation for this by establishing a Centre of Practice for Business Rule Governance and by ensuring that the organization has a standard way of defining the Common Business Language (CBL) and the implementation of business rules.

Here is a very basic example of how governance helped us in establishing a Common Business Language.  In an inventory management solution the terms 'product' and 'order line item' are used.  The term product represents anything that is offered to the market.  The members of the order management team will refer to them as a line item in the invoice.  The terms 'product' and 'order line item' represent the same thing, having perhaps slightly different characteristics based on the context where used.  These terms can be represented differently based on the context, but the underlying object model should be the same.  The object model governance team ensures that there is no duplication of information.

Business Rules vs. Validation Rules

Everything is a rule, but not all rules play a vital role in decision making.  In the broadest sense, we can classify rules into two different categories:  validation rules and business rules.  It can be hard to differentiate between them — what is a validation rule in one context might be a critical business rule in another context.

For example, email address validation might not be critical in a simple order management system, where all the system needs to check is whether there is a valid email.  On the other hand, the marketing team might be interested in knowing the email domain; if the requestor has a public domain he can be classified as a general user, and if the email contains a non-public domain then it might be a potential business opportunity.

In Conclusion

In this article I have covered some of the reasons why the adoption of business rule products has not been successful.  When working with business users on a rules project, every step has the potential to uncover business rules.  To achieve success it is very important to work closely with the users in understanding what is meant by business rule so that the focus is on understanding basic concepts rather than focusing on specific product features.  Without such an understanding there tends to be confusion in selecting the right tools to solve a particular problem.

References

[1]  Ronald G. Ross.  Business Rules Concepts.  Getting to the Point of Knowledge.  Fourth Edition.  Business Rules Solution, LLC (2013).  

[2]  For information on the Rete algorithm visit http://www.jessrules.com/docs/71/rete.html  

# # #