Principles of the Business Rule Approach: Areas of Opportunity
- Where Does the Business Rule Approach Apply?
- Let's Make a Deal
- Reempowerment for the Company's Provisioning Processes
- Business Rules as Customer Interface
- What about Web-Based Commerce?
- Reference
This chapter is from the book
This chapter is from the book
This chapter is from the book
Where Does the Business Rule Approach Apply?
The “Re's” of Business Rules
In my experience, business rule projects generally fall into one of the following major categories. Without exaggeration, I suspect one or more of these categories apply to virtually every organization of any size worldwide—including your organization!
Reengineering
The first category involves projects to reengineer business processes. The focus here is on 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 rethinking the business problem and in developing a full and optimal business solution up front. I will have more to say on that point later (see Chapter 4).
-
Business rules sharpen and complement other, more traditional deliverables (for example, workflow models). In short, business rules handle the business logic portion of redevelopment efforts.
Revitalization
At more or less the opposite extreme are projects with no intent to reengineer any business process. Instead, their focus is on the day-to-day 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 in a timely and efficient manner.
Typically, these organizations currently lack any effective means to trace the higher-level policies and 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 projects view the business rule approach as a way to reestablish lost connections by reinventing their rule management environments.
Redeployment
Just about every company these days is eyeing the Web as an environment for redeploying basic business services. To do that, a company must identify and encode the business logic that governs those services (that is, the business rules).
This type of project actually represents the larger problem of how to exploit new hardware/software environments more quickly and cheaply—in other words, how to rearchitect the technical environment. By no means is this problem limited to organizations that have been around for a good while. For example, I recently talked with the staff members of a dot.com company (still alive and kicking as of this writing). They were looking for a way to escape their “unlivable” five-year-old legacy hardware/software environment. Legacy time frames are continuously shrinking, so the business must find new ways to become ever more nimble about migrating business logic from one environment to another.
Recapture
There are actually several related “Re's” in this category—reverse engineering, retention, and redocumentation. This type of project is really motivated by fear (or risk avoidance, to put a more positive spin on it). 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 of the program code to get at the business rules—that is, on rule mining.
Other projects focus more on knowledge retention: identifying those workers who 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. I will have more to say on this point later (see Chapter 3).
Whichever way you choose to recapture the rules (whether by rule mining or by undertaking facilitated retention sessions), the objective is to redocument your rules.
Reempowerment
This is perhaps the most exciting area of business rule activity. Initially, this category focused on customer relationship management (CRM). (This focus is currently expanding—I'll say more about this later in this chapter.) Companies are using the business rule approach to handle highly individualized customer relationships on a huge scale.
For that, you must do three things.
-
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 reengagement.)
-
You must “operationalize” new or modified rules of engagement quickly—weeks or months of delay in programming is unacceptable.
-
You must manage the rules of engagement on the business side, not the IT side. In other words, you must reempower business users to manage the rules directly.
This area is clearly target-rich for business rules. As an idea of great potential for your business, it is worth examining more closely.