Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Business Rules Evangelist:
How Useful are Business Rule Statements?

online columnist Malcolm Chisholm     Column published in DMReview.com
October 21, 2004
  By Malcolm Chisholm

Most people would agree that having a complete and understandable statement for every business rule is a worthy goal. Indeed, a lot of effort has been devoted to techniques for constructing rules statements that meet this goal. Yet, I have to wonder if rule statements that really work are always attainable and if spending a great deal of time on them is justified.

This topic was in my mind when I recently visited a client that has a whole floor of their office staffed with people who do nothing but extract business rules from legal documents about bonds. The rules they harvest are used to create mathematical models that project the future performance of these bonds. The source material is very precise, but to understand it you need to know a lot about the underlying business and the dialect in which the legal documents are written. So perhaps we have a conflict between precision and understandability, but I think that there are additional conflicts that limit the value of business rule statements.

What is in a Business Rule Statement?

A statement of a business rule should completely describe the rule in English (or some other human language) and should be as understandable as possible to the reader. Unfortunately, the English language is not all that clear. When I read statements for business rules that I am not familiar with I have problems understanding what I am reading. In particular, it may not be clear to me where one business term ends and another begins. Consider one rule taken from our friend's reverse-engineering bond deals: The first distribution date distribution day cannot be after the 16th of the month.

Is first distribution date distribution day one attribute in a database table or are there two attributes: first distribution date and distribution day? Or is first distribution date just a term that I will find in a business glossary and not a distinct piece of data maintained in a database. Or, is it really the case that first distribution date distribution is the important term for the business in this rule? I think we all have these problems, especially reading legal contracts where we are not familiar with the underlying matter.

Writing Business Rule Statements

If reading business rule statements is difficult, what about writing them? Lawyers and legislators have a lot of problems getting rules stated properly, and we require judges to interpret laws and juries to adjudicate disputes over contracts. Lawyers and legislators are experts in drafting rules, yet they can cause this level of confusion. What chance, then, do IT staff struggling to document business rules have? Chris Date has written that business rules statements are very difficult to state in an unambiguous manner, and this corresponds to what I have experienced over the years. Even so, a great deal of effort has been put into developing methods to improve business rules statements. This is a very laudable effort, and better-formed business rule statements are surely preferable to poorly formed ones. However, I think that we run the risk of assuming that perfect business rule statements are possible and of investing huge amounts of time and effort in a quest that may have no end. Of course, with such quests there is ample space for quasi-religious arguments. If perfect business rules are not created by Project X, then it was almost certainly because Methodology Y was not used from the start.

Limits of Statements

My experience has a taught me to be cautious about simple solutions that appear to satisfy all circumstances. Business rule statements seem to fall into this category. They are written in natural English (or whatever language) that all English-speakers can understand. It seems self-evident that every rule can be expressed by a statement. Yet, it is difficult to accept that writing statements can fully describe all rules and that a statement is the best medium to fully convey a rule.

I prefer to see business rules as falling into classes that are based on business meaning. Now, taxonomies of business rules are also proliferating, but that is a subject for another column. Let me give an example of what I mean by a business-specific rule class: management fees charged by hedge funds and real estate partnerships. These businesses charge their clients fees just for managing their money. The fee consists of a "base," a "rate," a "frequency" and perhaps a "spread." The "base" is the amount of money from which the fee is calculated, usually the amount of money the client has given to the hedge fund (but sometimes just the amount the fund has actually invested). The "rate" is a percentage, the industry standard being between one and two percent. The "frequency" is how often the fee is charged, which is usually once a year. The "spread" is an additional percentage which the fund will add to the rate, if it thinks it can get away with it.

From this we can see that a rule of the class "Management Fee" can be defined with four pieces of meta data: base, rate, frequency and spread. If we create a rule template that calls for these pieces of meta data, we can at least see immediately if they are present or not. By contrast, a rule statement is so generic that we cannot see if everything that should be present in it is actually there. Different rule classes will call for completely different items of meta data, but rule statements are just rule statements for all rules.

I think that many professionals are still searching for perfect rule statements. Ultimately, they are going to be disappointed. The approach of analyzing rules to define them as classes with unique sets of meta data is much more likely to yield practical results.


For more information on related topics visit the following related portals...
Business Rules.

Malcolm Chisholm is an independent consultant focusing on meta data engineering and data management. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and frequently writes and speaks on these topics. Chisholm runs two Web sites http://www.bizrulesengine.com and http://www.refdataportal.com. You can contact him at mchisholm@refdataportal.com.

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.