The Re's of Business Rules
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!
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.
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.
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.
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!)
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.
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
- 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.
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules