An attendee at one of my recent business rule seminars asked me to profile the "typical" business rule project.  After a faltering response, and a little reflection, I realized that I couldn't.  Even cursory examination of our clients' recent projects highlighted as many differences as similarities.

After much additional consideration, I found the best I could do was to divide our clients' projects into five major categories.  Without exaggeration, I suspect one or more of these categories applies to virtually every organization of any size worldwide.  That probably includes your organization too!

Re-engineering

This first category involves re-engineering a business process.  At the project level, these clients want a top-down, business-driven requirements process.  Business rule development — especially for core business rules — is a critical part of such an approach, for at least two reasons. 

• First, business rules play a central role in strategizing — that is, in re-thinking the business problem and in developing a full and optimal business solution up-front. 
  
• Second, business rules sharpen and complement other, more traditional deliverables, including Workflow Models and Fact Models (high-level data models). 

In short, business rules handle the business-logic portion of re-development efforts.

Re-vitalization

At more or less the opposite extreme are clients whose focus for their project is not on the business process or on re-engineering the workflows.  Instead, these clients are concerned with the on-going problem of how to implement changing policies and directives coming down from "above" (and/or from outside regulatory or governmental bodies) into existing processes. 

This needs to be done on a timely and efficient manner.  Typically, these organizations currently lack any effective means to trace the higher-level rules to their actual implementation in legacy environments and related procedures.  Because the connections are lost, impact assessment and modification can be performed only slowly and painfully. 

These clients view the business rule approach as a means to re-establish those lost connections by re-inventing their rule management environment.

Re-deployment

Just about every company these days is eyeing the web as an environment for re-deploying basic business services.  To do that, the client must identify and encode the business logic that governs those services — a.k.a. its business rules. 

This type of project actually represents the larger problem of how to exploit new hardware/software environments more quickly (and cheaply) — that is, to re-architect the technical environment.  By no means is this problem limited to older brick-and-mortar companies.  One of our clients is a dot.com who is using the business rule approach to help escape their "unlivable" five-year-old legacy hardware/software environment.  (Yes, "legacy" timeframes are shrinking!)

Re-capture

There are actually several related "Re's" in this category — reverse engineering, retention, and re-documentation.  This type of project is really motivated by fear (or prudence, if you chose to be more politically correct).  The issue is how to avoid "losing" your business rules. 

Many business rules, for example, are buried deep in undocumented legacy systems.  Here, the focus is on reverse-engineering that program code.  (In my opinion, the jury is still out on just how effective this approach can be.  We have some excellent presentations coming up on this topic at the Business Rule Forum Conference in October, so I hope to gain better insights about it there.)  Our clients have focused more on retention — that is, on identifying those workers who do know the business practices, sitting them down in a room together, and extracting the rules on a facilitated basis. 

The objective is to record this knowledge before the workers are lost to retirement — or to the competition.  Either way you go about re-capturing the rules — that is, through either reverse engineering or undertaking facilitated retention sessions — the objective is to re-document the rules.

Re-empowerment

We have seen a surge of activity in this last category since the beginning of this year.  Loosely speaking, this category focuses on customer relationship management (CRM).  Our clients are using the business rule approach to handle highly individualized customer relationships on a huge scale.  For that, you must do several things. 

• First, you must record and manage the rules of engagement.  (Many companies are so out of touch with their customers you could probably call this an attempt at "re-engagement.") 
  
• Second, you must operationalize new or modified rules of engagement quickly — weeks or months of delay in "programming" is unacceptable. 
  
• Third, you must manage the rules of engagement on the business side, not the IT side.  In other words, you must re-empower the business users to manage the rules directly. 

This is a clearly a target-rich area for business rules.  In my next column, I will tell you why I think this category may ultimately prove the most exciting of all.

Copyright, 2000.  Business Rule Solutions, LLC.