Published in TDAN.com July 2003
The first of a three-part series based on Principles of the Business Rule Approach, the author’s groundbreaking new book from Addison-Wesley (2003). In this first part, the author
examines the business opportunities for business rules.
Where Does the Business Rule Approach Apply?
The Re’s of Business Rules
In our 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.
1. 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.
2. Business rules sharpen and complement other, more traditional deliverables (for example, workflow models). In short, business rules handle the business logic or knowledge
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, each 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 managers of a dot.com company that is 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—reverseengineering, 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 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.
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—more later.)
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.
Let’s Make a Deal
A Killer App for Business Rules
Let’s take a closer look at the reempowerment category of business rule activity mentioned above. This type of project often focuses on opportunities in the general area of
CRM—in particular, on making deals. Deals (or, more precisely, contracts and agreements) are how the company formalizes the “rules of engagement” with each customer.
Just about every company these days, of course, wants more and more customers—and highly individualized relationships with each and every one of them. Making the situation even more
challenging is the fact that products and services in today’s economy are also increasingly complex and/or differentiated. So the question becomes, how can you manage highly individualized or
even one-of-a-kind agreements for increasingly complex and differentiated products with increasingly large numbers of customers? And, by the way, how can you do it economically, flexibly, and
quickly?
One thing is for sure: you can’t do it successfully the way it has been done in the past. The traditional approach might be summarized as follows. A manager, marketing representative, and/or
lawyer comes to some agreement with a customer. Such agreement might be about the acquisition of a product or service as a whole (including options, timing, pricing, delivery, and so on) or about
some specific aspect thereof (for example, discounts). Once formalized (for example, in a contract or letter of understanding), the agreement is then handed over to the programming staff (or, if
simpler, to the operational staff) to implement and operationalize. Depending on the complexity and availability of resources, this might take weeks or months—a virtual lifetime at this
crucial juncture in building the customer relationship.
There are at least three things fundamentally wrong with this approach.
- It is far too slow. These days, operationalizing an agreement needs to take place in hours or days, not weeks or months.
-
It cannot be effectively managed. Even if the programming and/or implementation is done correctly (a very big if), the resulting code is far removed—almost completely
disconnected—from the original agreement. Any resemblance in form is vague at best. Subsequent changes in the rules (inevitable these days) become a slow, painful, and expensive affair. -
The approach is deeply flawed from an organizational viewpoint. Those workers in actual contact with the customers are displaced from those workers who have the skills to adjust the
implemented rules of engagement. This leads to gaps, inefficiency, and frustration all around.
The business rule approach offers a potent two-part solution. First, deals are viewed as nothing more than collections of high-level business rules. (We call these governing rules.) The
business rule approach has already evolved effective techniques to interpret and manage such rules.
Second, the programming of deals clearly must be eliminated. Rule engines address that problem by allowing the rules of engagement to be implemented much more directly.
This approach produces a huge additional advantage—much of the business rule activity can now go outboard. By this I mean it can be removed from IT and distributed to those directly in
contact with the customers. This will empower those users to manage the rules of engagement directly. Now the deal making (and deal remaking) is done directly, through what I call eDeals.
I believe enabling these power users for eDeals will prove a killer app for business rules—and, more importantly, for the business!
Reempowerment for the Company’s Provisioning Processes
There’s a Lot More to Reference Data Than Just Data!
A high-level manager at a large, well-established high-tech company recently summarized his company’s operational problems in two succinct statements:
These problems posed serious risks to the company’s ability to remain competitive.
A quick look at the company’s fulfillment process revealed two obvious signs of trouble. First, the rate of complaints from the company’s best customers was significant. Second, growing
pools of workers had formed at several points in the process focusing almost exclusively on problem resolution.
The manager’s first impulse was to consider reengineering the fulfillment process itself. That course of action was a daunting one, however, because of the size, complexity, and distribution
of the operation. It also promised only incremental improvements at relatively high cost.
Probing deeper, it became apparent that the real source of problems did not lie within the fulfillment process at all. The fulfillment process was highly dependent on other aspects of business
operations, and these other aspects were simply not well organized.
In IT terms, applications supporting the fulfillment process were dependent on data feeds from other operational systems. IT therefore viewed the issue as a data quality problem and proposed a
technical solution. From the business perspective, however, the real problem did not lie with the data but rather with the business processes that produced the data.
There were basically two such processes. First was the company’s product release process. This process, which for more complex products typically stretched over many months, involved
establishing valid product configurations based on a significant number of technical, packaging, and marketing guidelines (the business rules). It also orchestrated the timing of releases across
the large number of worldwide geographical areas of company operations. Each geographical area, of course, had its own local rules for releases, based on law, market factors, and customs. Also
important was coordinating the ongoing review and approval process, which involves many levels of staff in different parts of the organization. The product release process had evolved in an ad hoc
manner over many years’ time and was highly fragmented. This produced flawed product and release data before even reaching the fulfillment process.
The second business process supporting the fulfillment process was the company’s customer process—or, rather, the lack of one. The company had never evolved a global view of the
customer base (at least at the operational level), and consequently the company had no focal point for managing the complexities of customer data (for example, subsidiary versus parent company,
account versus customer, and so on). Rules about customer identification and data could not be effectively enforced at the source (that is, at the point of origin). Although the company’s
data warehouse did support a consolidated version of customer information, this data was aimed for business intelligence (that is, customer profiles, trending, competitive strategy, and so on)
rather than for operational needs.
As a result of this analysis, the company began to focus more and more on the two upstream business processes, product release and customer. Its motto became the following.
“Do it once, right at the source.”
Doing it right at the source is another basic principle of the business rule approach. As the above case study illustrates, it means reexamining the business processes that provide essential
business inputs (for example, product release information and customer information) for day-to-day operational processes. Our name for these upstream support business processes is provisioning
processes.
Provisioning processes present a high-yield opportunity to apply rule technology. They are inevitably rule-intensive but are not themselves highly dependent on incoming data feeds. Also,
they inevitably offer substantial opportunities for direct specification of rules by business-side workers.
From an IT perspective, provisioning processes produce what has traditionally been called reference data—data that historically often appears as codes and/or in look-up tables.
Typical kinds of reference data, as suggested by the case study above, include product configurations, product families, customers, geographical areas, and so on. This is obviously just
the tip of the iceberg. A more complete list is presented in Table 2–1. For each there is an associated provisioning process and a likely candidate for a business rule project.
The term reference data, unfortunately, does not do justice either to the problem or to the core issue of provisioning processes. From a business perspective, provisioning processes are
critical to the effectiveness of operational activities. For example, in the case study above, at stake was no less than correct product configuration. This capacity, by the way, encompasses
support for fast product reconfiguration—increasingly a must in today’s competitive business environment.
From a business rule perspective, the core issues lie with (a) the right methodology for business rules and (b) standard business vocabulary—the terms the business uses to
communicate (and potentially to automate) fundamental aspects of its knowledge. These will be the subjects of the next two parts of this three-part series, respectively.
Copyright, 2003. Business Rule Solutions, LLC. All rights reserved. Excerpted with permission from Principles of the Business Rule Approach, by Ronald G. Ross, Addison-Wesley, Boston,
MA, 2003. ISBN: 0-201-78893-4 – Available via www.BRSolutions.com — Mention “TDAN.com” for a 10% discount.
