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:
The Case for Business Rules

online columnist Malcolm Chisholm     Column published in DMReview.com
January 2, 2004
  By Malcolm Chisholm

Editor's note: DMReview.com welcomes Malcolm Chisholm as our newest online columnist. He will share his expertise on the topic of business rules. Look for his Business Rules Evangelist column on last Friday of each month as he discusses the current and future business rules' movement.

When Mary Jo Nott, Web editor, asked me to begin a new column on business rules for DMReview.com, I asked her what the tone of it should be. "These things take on a life of their own," she explained. "Just begin and see where it goes." That comment is strangely reminiscent of where the business rules movement finds itself today. It has begun, but we are still waiting to see exactly where it is going. Yet, if we look hard enough we can make out the shapes of things to come. Perhaps some things are still hidden and others are just mirages, but there is plenty of interest on the road ahead. Because of this, many people are now at a point where they want to know if it is more hype than reality - is there really a case for business rules? Let's try a little prophecy.

First, what can business rules potentially do for the average organization? One problem is that the average organization usually does not understand how it runs very well. Pockets of complexity exist in most large organizations where things usually kept going by a combination of clunky systems, subject matter experts and the organizational equivalent of duct tape. If the business rules in such pockets could be documented (and that is a big "if") then the thought is that things could be made more efficient. Perhaps so, but a more tempting option might be to simply outsource such areas of confusion to lower- cost service providers. The notion that organizations do not know what they are doing is also open to challenge. In some ways most businesses do know pretty much what they do, and it is rather simple - so why bother with business rules? For instance, most businesses just sell products and services to customers. Each sale is identical, and the rules can be inferred from what is printed on a receipt.

All of this is true, but there is a deeper reality, which is that the world we live in is becoming more complex and organizations need to adapt to this complexity or face the consequences. Before computers there were "computers" - the term given to human beings who did calculations and updated ledger books. Today, no modern enterprise, such as a bank, could hire enough experienced clerical staff or buy enough ledger books to process their customers accounts manually and still deliver the timely and quality service these customers expect. Something similar now seems to be happening with complexity. Each customer would like their own special "deal" with their bank, mortgage lender or stockbroker. In the future, transactions will likely not be monolithic, i.e., buying groceries - where very product and customer gets processed the same way at the checkout. Even today some of this can be seen. Companies may sell things in only one way, but they have complex ways of giving rebates or discounts to favored customers. Private client stockbrokers allow their rich customers to specify general rules about how their money should be invested, e.g., no tobacco stocks, keep 67 percent of my money in bonds or invest in U.S.-based companies only.

How can companies adapt to increased complexity? Hiring more programmers to hand craft more code is the equivalent of hiring more clerical staff and ledger books in the nineteenth century. But what if we could directly specify rules and have them implemented automatically in our computer systems. That might enable any business to develop true one-to-one relationships with its customers, suppliers, employees and investors. The ability to take on and manage this amount of complexity successfully will be a formidable competitive advantage.

Another apparent driver for business rules' approaches is the elimination of programmers. Unfortunately, the extinction (or at least a significant reduction) of this species of artisan has been predicted several times in the past, such as when third-generation programming languages were introduced a few decades ago. Every time these predictions have been made, the ranks of programmers have actually grown. The business rules approach now seems to present a way by which entire systems can be automatically generated without the assistance of programmers. Perhaps so, but the presumption behind this view is that programmers spend all of their time developing new functionality. The reality is quite different. Studies have shown that programmers spend about half their time reverse-engineering code to figure out what it does. Today's applications are black boxes whose inner workings are largely unknown. Only by testing their behavior, or by reverse engineering, can we gain any understanding of what rules actually govern applications. This knowledge is extremely expensive to garner and yet is almost never stored in a format where it can be reused with confidence. Also, a good number of these rules are not "business" rules, but logic that is needed to make the system work, e.g., because its database is denormalized or the code is spaghetti. If we could really see inside the black boxes that are applications, we would be able to make changes more easily - to keep pace with business evolution. In addition, the applications could be truly audited, for instance to see if they had proper financial controls in place. It would also be possible to compare an application to its specification - to see if a rule in the specification was actually implemented.

In the end, business rules' approaches will have an impact on programmers. However, the scope of this impact is likely to be well beyond forward engineering of functionality.

The case for business rules is more about doing things that are completely new than about increasing efficiency. Management of complexity and the "un-black-boxing" of applications may not be mentioned very often, but they are very likely to play important roles in the future of the business rules' movement. The movement may still be in its early years, but it is not hype. In fact, as we will see in future columns in this space, its roots are deeper today than most people realize. Organizations in general, and IT professionals in particular, cannot afford to ignore it, even if it seems that there is not very much that is actionable today. The future will be different.


Check out DMReview.com's resource portals for additional related content, white papers, books and other resources.

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
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.