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

RESOURCE PORTALS
View all Portals

WEB SEMINARS
Scheduled Events
Archived Events

RESEARCH VAULT
White Paper Library
Research Papers

CAREERZONE
View Job Listings
Post a job

Advertisement

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

GENERAL RESOURCES
Bookstore
Buyer's Guide
Glossary
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

DM REVIEW
About Us
Press Releases
Awards
Advertising/Media Kit
Reprints
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Business Rules Evangelist:
Controlling Rule Redundancy

online columnist Malcolm Chisholm     Column published in DMReview.com
January 27, 2005
 
  By Malcolm Chisholm

A few months ago my wife and I were picking up some bargains in a major department store. The store was having a special housewares sale, and we came armed with a discount coupon. The clerk we were dealing with suggested that we open a new credit account with the store, since that would give us an even bigger discount for the day. We took this advice and purchased quite a few items which were not in stock. The clerk assured us they would be shipped in due course and even gave use exact dates when they would arrive.

We waited for the shipped items to arrive - and waited and waited. They never came. Eventually, I went back to the store to find out what had happened. After a lot of searching across multiple incompatible information management systems, it turned out that our orders had been cancelled, and the goods had never been shipped. Why? Ultimately, the reason turned out to be because the store had a rule that only one discount could be used during one transaction. We had tried to use three different discounts. The system responsible for shipping detected this and cancelled the transaction. The fact that it never notified us, the purchasers, about this appeared to be something that was not totally unexpected by the store staff.

Finding Rule Redundancy

One of the things that this story shows is how rules that affect a transaction can be implemented in more than one system. Clearly there were rules about handling discounts that existed in the point-of-sale system that were different in the shipping system. How do I know this? Because I did get multiple discounts applied to the items I was able to carry out of the store but not to the items that had to be shipped from the warehouse.

A question that naturally arose in my mind was whether the store staff knew where the rules were located. In other words, was there any knowledge about what rules were implemented in each system? It became evident that the store staff I was deal with was not aware of this. However, I do not think it is fair to expect that they would need to know such a thing. The assumption that I had at the start of the transaction was that one set of rules would be applied one time to the transaction. Just knowing that this was not the case was an eye-opener. After that, finding out that different systems applied similar, but different, rule sets was depressingly expectable.

If the floor staff was not aware of how the company managed its business rules, who might be? Perhaps a better question to ask would be: what kind of design would be needed to support knowledge of what rules exist and where they are implemented.

Repository Design

The answer has to be a repository that maps business rules to implemented systems. Yet this seems to fly in the face of one of the major advantages of the business rule approach, which is to define a business rule once in one place and reuse it multiple times. Most people see the advantages in this; and in the rules engine functionality that I have developed, it has been possible to implement it. However, this is clearly never going to be the case for legacy systems. These systems are often black boxes and finding out what rules they contain can be a major effort. Beyond this, changing legacy systems so they take rules from some other source is probably unrealistic, to put it mildly. After all, legacy systems are often built in versions of software products that are no longer current, and experienced personnel who can safely make changes can be difficult to find.

The business rules movement does not seem to focus too much on the area of mapping rules to systems. It often seems to break down into two main areas of interest: building rules engines and compiling the rules of the enterprise independent of any particular implementation.

Meta Data Management

Yet, as my shopping experience shows, situations do exist where it is necessary to know how rules are being applied. Perhaps a more serious example is the need for auditors to know how financial rules are applied on a per-system basis. What this boils down to in practical terms is the need for good meta data management. A repository that tracks what rules are applied in each system would have to store meta data about rules and meta data about systems.

It sounds simple, but it is not. My experience of meta data management in major enterprises is not good. It is often approached as something that is a "good practice" without any clear idea of why it is being undertaken. Little is done in the way of identifying the priority meta data needs of specific users. Instead a "build it and they will come" approach results in the implementation of some generalized component of a portal that is exposed to the entire enterprise, yet contains very little functionality.

Rule redundancy is a fact of life. If it is to be controlled, the only viable approach is through meta data management. The risk of not controlling it is that transactions go awry, data quality gets degraded and decisions based on managed information become unreliable. The track record of meta data management, in terms of its usefulness to the enterprise, is mixed to put it politely. Let us hope that the business rules movement will provide practical pointers to improving this aspect of management of rules data.

...............................................................................

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

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
Advertisement
advertisement
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2005 DM Review and SourceMedia, Inc. All rights reserved.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.