• Home
• Consulting & Mentoring
• Training
• Bookkeeping & Forecasting
• About Us

Design Process - Business Rules

Imagine working on an application with 1500 business rules. Now try to imagine getting these business rules to work seamlessly together. Suppose you finally got it working and the client comes back to you and says that it needs to modify and/or add new rules. This is the dilemma facing most large scale projects.

Application logic is expensive to develop. Merging business policies and practises into simple procedural code can be difficult to maintain. From a requirements perspective, business rules may be thought of as small pieces of knowledge about a business domain. They generally represent key pieces of business logic that may be prone to changes. A problem with business rules is that they are often scattered across several classes within an application. The rules which are often coded as big nested if/then/else statements are often replicated and usually hard-coded. As a result, they end up being neither maintainable nor reusable. We once saw a Java Session Bean which included all of the business rules for a critical module in the system and it contained 10,000 lines of code. Nobody wanted to touch it for fear of breaking the code.

Business rules can have different meaning to different people and the term is used loosely across the software industry. The use of a parameter stored on a database (e.g. applied interest rate) is often confused with the core logic that uses that parameter. A business rule parameter can be changed at runtime on a production system. The core business rule logic that uses that parameter cannot. However, it is possible to minimize the turnaround time required to add and/or modify business rule logic with the use of a business rule engine.

Much of the programming developers do is procedural. The programmer tells the computer what to do, how to do it, and in what order. This approach is well suited for problems in which the inputs are well specified and for which a known set of steps can be carried out to solve the problem. For example, mathematical computations are best written procedurally. Rule-based systems differ from standard procedural or object-oriented programs in that there is no clear order in which code executes. Instead, the knowledge of an expert is captured in a set of rules, each of which encodes a small piece of the expert's knowledge. The rule engine determines which rules apply at any given time and executes them as appropriate. A rule-based version of a complex program can be shorter and easier to understand than a procedural version because developers can concentrate on the rules for one situation at a time.

Each rule has one or more conditions and a consequence (action). The conditions contain information about certain facts and objects which must be true in order for the rule to potentially fire (that is, execute). Any rules whose conditions match in this manner at a given time are placed on an agenda. One of the rules on the agenda is picked (there is no way of predicting which one), and its consequence is executed, and then it is removed from the agenda. The agenda is then updated, and a new rule is picked to execute. This continues until there are no more rules on the agenda.

// Check for high number of delinquencies
if (numberOf30DayDelinquencies > 4) {
  // Risky client. Increate mortgage rate
  mortgageRate = mortgageRate * 0.5;
}
                        

A rule bears a close resemblance to an if-then-else statement, but unlike an if-then-else statement, it stands alone and does not fire in any predetermined order relative to other if-then-else statements.

The advantage to this type of approach, as opposed to a procedural approach, is that if the system is designed well, then the expert's knowledge can be maintained fairly easily, just by altering whichever rules need to be altered. However, use of a business rule engine is not for the faint of heart. Although a rule engine can be very powerful, it can be difficult to learn and to use properly. Developers really need to change their development approach and frame the problem from the client's perspective. On most CRUD type of applications, a rule engine is overkill. However, we recommend using a rule engine on any system with a high number of complex business rules. Financial and tax based systems are both good candidates for the use of a rule engine.

Most rule engines are based on Charles Forgy's Rete algorithm. Several open source implementations are available with our personal favorite being the Drools Rule Engine tailored for the Java language. Drools provides for Declarative Programming and is flexible enough to match the semantics of your problem domain with Domain Specific Languages, graphical editing tools, web based tools and developer productivity tools.