Kenneth Down asks Should Business Rules be Technology Neutral? I respond by saying that Business Rules Must be at least Implementation Neutral.

Kenneth argues that business rules are best captured in the language of database tables, stored procedure descriptions, and the like.

He is perfectly right, when

1. No specs have been drawn out
2. It is upto the developers to figure out what the business system is supposed to do.
3. When the business is not interested in understanding how the software system is going to deliver
4. Business Requirements change rarely.

I am sure there are many such situations, and my developer self, agrees with him. But, I have to say that this is a Highway towards Maintenance Hell.

Commission Calculations - A Case Study

Let me take the example of a Insurance Commissions Calculations and Management Application to illustrate why.

Insurance Companies use a whole variety of commissions as incentives to their Sales Agents. Commissions are calculated on the basis of a number of factors.

1. Commission rates vary by product
2. Commission rates vary by geographical location
3. Initial commission, arrears, clawback commission
4. Commission calculations depend on when policy was taken. A lot of date driven rules
5. Commission vary based on the type of intermediary the Insurance company uses between itself and the agent.
6. There can be many many types of commissions
7. Extra Commissions also can be allocated as part of seasonal marketing campaigns
8. Commissions also depend on the amount of Policies sold.

Now, if you see, commission data will be stored in the database. But, the question is how will commission calculation rules that determine how commissions are computed be implemented and captured?

Business Interest in Commission Calculation Rules

1. Sales Managers need to control how commissions are computed and doled out. Therefore it makes a whole lot of business sense for these rules to be very visible.
2. Commission rules change often as a result of marketing campaigns, a new product being added and so on.
3. Mistakes in commission calculations must be rectified immediately, and not take days

A Traditional Database Driven Implementation Approach

1. Commissions data is stored inthe database
2. Commission calculation rules are written as Stored Procedures that get Triggered on data change

The problem with this approach is that over a period of time

1. The rules in the database become extremely complex, and require experts to be able to understand and change the rules
2. It becomes very difficult to measure impact of change when new commissions are intruduced
3. Turnaround times are large as business analysts cannot understand DB Rules, and the change process has to go though the full SDLC change cycle.
4. Mistakes are harder to detect and harder to fix.
5. It is very difficult to unit test commission rules as and when they are added or change.

Business Rules Driven Implementation Approach

1. Commission calculations are implemented as Business Rules in formats like Decision Tables, and Flow Rules
2. Commission Calculation is performed by a Business Rules Engine by applying the commission calculation rules on the concerned data
3. The application calls the Rule Engine.
4. The Business Rules are independent of how the commissions are stored. The Rules can be implemented on the Domain Model, or the XSD that represents the data model.

The advantages I see with this approach are

1. The Business Rules are visible and the Sales Managers will be able to see the commission rules. Mistakes are easily caught.
2. The Rules themselves are stored separately from the application, and any change to the rules can be tested independent of the application.
3. This in turn, reduces the turnaround times when changes are requested.
4. Business Analysts can actually change the rules by themselves, over a period of time, after the organization has acquired maturity with Business Rules Technology.

The Final Argument.

As you can see, Business Rules offer a clean and maintainable approach when it comes to implementing complex business policies. They provide a clean Layer of Abstraction that is near to impossible with tradition development methods.

Additionally, of course, business rules look very close to plain English, and go a great way towards documenting the complex system behaviors.

I believe developers Must learn to love Business Rules Technology, and not just write it off.