In today’s world, globalized business operates twenty-four hours a day, three hundred sixty-five days a year; it talks to customers and partners over a host of channels ranging from point-of-sale to Web portal to call center; and it is audited and monitored in support of a wealth of new compliance regulations. In this new environment the demands upon a company’s computing ecosystem are immense, and they are growing, seemingly exponentially. Success in this hypercompetitive world requires responding to changing market conditions in real time, with as little friction – and cost – as possible.

The technical barriers to real-time business are gradually coming down, but many remain. To get the most from investments in often heterogeneous business applications we desire that they function as an organic whole, and so we devote large sums of time and money to rationalizing, or to use the technical term, “normalizing,” diverse software architectures, integrating legacy systems, standardizing business-to-business protocols, and so on. The increasing adoption of Web Services and XML will, over time, make the job of technical interoperation easier, but the goal of extracting true business value – fine-tuning business operations as conditions warrant, rapidly exploiting new opportunities – still remains elusive.

Many customers report success in automating complex business processes such as supply chain management, health care forms processing, electronic funds transfer, and numerous other areas. However, they often add that changing these processes is expensive, laborious, and requires negotiation between multiple groups (usually, the business organization and the IT team).

Consider this scenario: a business manager of an online retailer notices that a competitor is offering discounts to its best customers. Obviously, our retailer would like to make a similar offer, perhaps with a deeper discount – and would like to see the results of this promotion by the end of the day, perhaps.

Now, this retailer may have a well-automated process to take orders from the web site, validate and debit the customer’s credit card, and pass the aggregated information to the fulfillment group, which then ships products, and all this may involve the harmonious interoperation of a half-dozen to a dozen separate business applications: e-commerce web site, credit authorization, master inventory database, fulfillment, to name a few. But how easy is it to change? Does our business manager have to call a meeting with the company’s programmers – and ultimately have code changed, with all the risk of regression errors that that entails?

Ideally, of course, the business manager should be technically empowered to make these sorts of changes – directly. After all, it’s no different from a shop owner a century ago, who, noticing price cuts in the competitor’s store across the street, scratches out the prices in his store and replaces them with new ones.

Every business has examples like this: business analysts at an insurance company want to change the criteria by which it determines risk during the process of policy application and approval.  Learning of a hurricane approaching Florida, a business decision maker desires to re-route a shipment of flashlights currently sitting on a palette in Asia. Before sending a promotional email to a customer, the company’s extensive, and often dynamic, privacy policies must be consulted – and so on.

All of these scenarios, of course, are examples of business process in action. What is often missing in current business process deployments is approachability by the business user, by the one constituency that is accountable for the operation of the business. To make these sorts of changes to running business systems too frequently requires the analyst to request IT assistance – code changes, regressions, and redeployments.

This problem, however, is solved by the tight integration of business rules technology with business process technology. Business rules are simple and intuitive: if platinum customer, offer 20% discount. Indeed, years of research have concluded that the if-then structure of rules is central to the cognitive structure and operation of the human brain.

This being the case, rules offer a safe business-user-focused window into the often highly technical business process. While an IT architect would shudder to think of a business analyst changing an application’s security model or communications protocol, changing the value of a condition in a rule is exceptionally powerful – and doesn’t risk the integrity of the underlying applications. If we want to offer the discount to platinum customers today, and gold and platinum customers tomorrow, that may have interesting implications for the business, but none for the underlying applications.

Certainly, business rules engines have existed for some time, and a number of vendors sell standalone engines. However, the true value of business rules appear when the rules engine is integrated as a fundamental building block of the business process.

Let’s look at rules in a little more detail, and then see how they might actually be used in a process.

Rules can be used for many purposes within a business process. Rules can validate data, for example: a platinum customer must be a homeowner. These are simple, declarative rules aimed at ensuring the consistency and correctness of the data consumed by a business process.

Rules can also be used to direct the flow of a process.  Such rules, as we have said, consist of a condition followed by an action: if this, do that (if platinum-customer, offer 20% discount). See Figure 1.

Here is where the business analyst can gain access to the process – a well integrated engine will permit the analyst to change both the condition and action at runtime, and to deploy these changes. It’s easy to imagine a dashboard where the analyst can simply make precisely these types of changes.

But what is a “platinum customer”? More specifically, how is platinum customer defined in the underlying technologies (applications, databases, Web Services, and so on) of the process? This highlights an important fact, namely, that constructing a powerful rules environment for the analyst does not come for free; a vocabulary must be built which relates natural-language terms to the technology underneath. Creating these bindings is of course the job of the developer, who may (say) relate platinum customer to a technical artifact of the business process, say, a database row where a column value is greater than 3.

Thus, as shown in Figure 2, the analyst is building a rule using the vocabulary phrase “platinum-customer” – and may not even be aware that this in fact dynamically refers to data in a system of record elsewhere in the computing ecosystem.

That point is worth reiterating: the IT developer sees databases and rows and queries and objects and messages; the business analyst sees a vocabulary (of business objects) rich in business semantics.

Rules can also be used to direct interactions with humans in the course of a business process. If a purchase amount is greater than some predetermined figure, then an exception subprocess, perhaps requesting human approval, may be invoked as the result of a rule firing.

Sets of rules are called policies. Policies may include tens, or hundreds or even thousands of rules: approving a mortgage for example involves an examination of credit, compliance to lending laws, and achieving maximum return given current interest rates and competitive conditions.

But as seductive as rules engines are, they come with unobvious challenges. Making large policies performant (running thousands of instances over thousands of rules) involves sophisticated engineering (for example, the RETE algorithm optimizes the evaluation of conditions). Inconsistencies within a set of rules can also be difficult to find; consider:

 If Age is greater-than-30 offer 20% discount
 If Age is greater-than-40 offer cash back

If the customer’s age is 45, does he get cash and a discount?  Perhaps yes, perhaps no: the business intention is unclear. Sophisticated rules engines come with technical capabilities and tools to at least highlight, if not correct, these sorts of potential ambiguities.

Still, it’s clear that rules offer a great deal to the business. But how to determine the ROI of rules? This is where the business process server offers a great deal of useful infrastructure. First, the server usually supports a rule repository, which not only holds the rules themselves in a centralized location but also controls access and – most importantly – records changes to the rules, which in today’s regulatory climate is essential.

Further, most business process engines come with tracking mechanisms which enable both IT and business users to view their histories: how many platinum customers bought products before and after the promotion, for example. Process engines with built-in rules engines will also record branches taken and decisions made by rules. Then, using dashboard technologies such as Business Activity Monitoring (BAM) it’s straightforward to infer causality, and thus the financial return.

Thus, the value of rules as a critical component of business processes should not be underestimated. By giving the business user a chance to interact with the process and to safely change its running parameters, the costs associated with automated processes can be very substantially reduced. Conversely, the business user can now control the process to an important extent, in real time, enabling quick and efficient responses to changing business conditions.

In evaluating integration and business process products, then, customers should inquire about an integrated rules engine; if one exists in the product, how it fits into the overall architecture and how its capabilities are exposed to the business user. Rules are the gateway for the business into the process.