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:
Rethinking Rule Taxonomies

online columnist Malcolm Chisholm     Column published in DMReview.com
November 25, 2004
 
  By Malcolm Chisholm

Anyone delving into the area of business rules will soon encounter various classifications and groupings of different kinds of business rules. Most professionals tend to view these taxonomies as something that provides insight into the underlying nature of business rules, and indeed this is often the case. However, there is a tendency in human beings to get carried away with taxonomies and think that they hold some magic key to understanding. This leads to problems when different taxonomies describe the same thing, which is the case with business rules. In such circumstances we tend to think that the taxonomies are competing, that one is "right" and the others are "wrong" or that at least some taxonomies are "better" than others.

Taxonomic Strife

Because feelings can run high in this area, I do not want to get into a comparison of the different taxonomies of business rules that are out there. In fact, I think doing such comparisons is not a very productive activity. Rather, I would like to suggest that there is a perspective from which we can view all these taxonomies. This is not to say that some are bad and some are good, but they are good and bad as taxonomies, not necessarily in what they help us to understand about business rules.

Perhaps the biggest issue in working with taxonomies in general is that there is an expectation that they reveal truth to us about the universe. Biologists classify living organisms as species, chemists classify different substances as elements, astronomers classify stars into distinct categories and so on. Scientists tend to be forced to do this to look for patterns in their observations. The patterns can then be used to ask questions about the underlying mechanisms in nature that the scientists are studying. Further observations, experiments and building theoretical models then drive science forward. Taxonomies are an aid in this process, not the answers that science provides.

Unfortunately, we humans tend to want to categorize things to such an extent that we think that taxonomies really do hold keys to understanding. This may not be a wise approach for dealing with business rules. However, taxonomies can still have value.

Taxonomies Matter

Rather than looking at taxonomies as right or wrong, it is better to think of them in terms of the value that they provide in helping us to work with business rules. Just as one tool serves a specific set of requirements, so a taxonomy should serve a specific set of requirements. If the taxonomy does not serve any requirements, if it does not help us manage or automate business rules, then it is not very useful. This is irrespective of how much "truth" is contained in any taxonomy.

By way of example, I have noticed that some programmers tend to think of business rules in terms of the different programming constructs. Certainly, all business rules can be thought of as implementable as derivations or constraints using various groupings of syntax available in any given programming language. A major value in such a taxonomy is jump-starting a programmatic design to implement business rules. However, it says nothing about how to identify units of business logic, manage versioning or how to reliably relate business rules to reference data. Unfortunately, if such a taxonomy is adopted too fully, then it becomes difficult to see that the business rules movement has anything new to offer. Business rules can simply be viewed as more of the same logic that we have had to implement since the 1960s.

Taxonomies as Tools

It is important not to take taxonomies so seriously that they stop us from looking at business rules from different perspectives. If this is done, then it becomes possible to view taxonomies as tools. I have found that it is easier to do this if we can get away from taxonomies based in IT concepts. Indeed, I have found that business users in many situations think of groupings of business rules that make sense in specific business contexts. Understanding these taxonomies can be very enlightening as they can decompose a particular business domain into more easily understood parts and identify rules that have similar sets of meta data associated with them. This, in turn, helps with managing rules, for instance, designing repositories to hold the rules. 

However, none of this is to say that thinking of categorizing business rules in terms of IT concepts is not valid. We have to implement repositories to house business rules and build rules engines to execute them. In these contexts, IT-based taxonomies of business rules can be very valuable, if not necessary.

There are a few tests that can be applied to any taxonomy to determine if it is good. A good taxonomy will be built on a sound semantic definition. Each category in the taxonomy will have a sound definition. Furthermore, categories will not overlap, nor will there be obvious gaps in what they are supposed to cover. Assessing a taxonomy in these terms can tell us quickly if it is good or not, instead of engaging in endless arguments about which taxonomy is the "right one." Taxonomies have an important role to play in the business rules movement, but as tools, not as causes for dispute.

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

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