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.