From its earliest beginnings back in the 1980s, process automation technology has always emphasized the notion of “rules-based” logic. Meanwhile, in parallel, a completely independent technology evolved for the enforcement and management of business rules, primarily for decision support. While many BPMS vendors have shamelessly promoted their own process models as examples of “business rules,” process engines and business rule engines – and their respective notions of rules – are actually very different. Today, however, BPMS and business rule engine (BRE) providers have both come to realize that the two technologies can work together effectively to make processes more effective and agile. Let’s take a look at how business rules differ from traditional process rules, and how new BPMS offerings are leveraging the benefits of BRE integration.
The rule logic in a process engine typically directs the flow of work at a branch point in the diagram: If Amount > $10,000, route to Manager Approval. Typically the rule is expressed in the process model as a Boolean (true/false) condition enabling a particular branch or transition in the flow. Process rules of this sort in fact can and do enforce policies, procedures, and best practices, but they differ from true business rules in a number of important ways.
Since they are defined as Boolean expressions of workflow variables, process rules are by necessity simple. True business rules, on the other hand, can be extremely complex, and typically reference other rules. They can, for example, compute a “score” based on dozens of criteria using data stored in multiple business systems, and then apply a threshold to that score to pay a claim, approve credit, or determine that a transaction is compliant with regulations.
Process rules are bound to a specific point of use in the process model, typically a branch point in the flow diagram. If the same rule is to be used globally, it must be replicated at each point of use. That means that if the threshold for Manager Approval should change to $15,000, the change must be implemented separately in every branch point in every process template where the rule applies! Business rules, in contrast are defined globally and stored centrally. If the Manager Approval threshold were defined using a BRE, the change would just have to be made once, and it would be immediately applicable in any step in any business process that referenced it.
Compared to business rules, process rules are also limited in their effect: they can only enable a branch in the flow diagram. As we shall see, when integrated with a BPMS, business rules can do more: start a new process, release a pending task, update process data, assign a task to a particular user, or send a notification.
Another advantage of BRE technology is that the rules are meant to be defined by business analysts, not programmers. While many traditional workflow offerings geared their process design tools to non-programmers, today’s more powerful BPMS technology – based on J2EE, .Net, and web services – has made the process design environment less business-friendly. So when a process rule changes, it must be implemented by IT. That hampers agility.
BRE technology improves process agility in an even more significant way. When a rule change is deployed to the BRE, it takes effect immediately in all processes invoking the rule. The process model on the BPMS does not need to change at all. In contrast, changing a process rule means creating a new version of the process model and redeploying it to the process engine. Usually the new rule takes effect only for new instances created with the new model version; in-flight instances continue to use the old rule.
For all of these reasons, a BRE is increasingly seen as key component of a BPM solution, and BPMS vendors are beginning to compete on the basis of their BRE integration.
The most common form of BPMS-BRE integration is synchronous invocation. Here the process engine commands the BRE to evaluate a rule at a particular step in the process, and uses the returned result to control the flow at a subsequent branch point in the diagram. For example, the process could invoke the BRE to score a credit request, and, based on the score returned, either reject the request, route to a manager for approval, or approve the request and continue the transaction.
An additional form of integration is event-driven invocation. Instead of waiting to be invoked by the process engine, the BRE “listens” for specific events in the process environment. These may be updates to specific values in a database (e.g., one monitoring service levels), or messages received from an external source. The event triggers the BRE to evaluate a rule, which may involve additional data. Also, the result of the rule is not limited to returning a data value but can itself execute some action, such as starting a process on the BPMS or releasing a pending BPMS task.
Like a BPMS, a BRE offering is a complex and not inexpensive system, comprising a point-click design tool, a rule repository, and an execution engine, which may include its own integration framework. In most cases, BPMS vendors have chosen to partner with existing BRE suppliers like Fair Isaac or ILOG, while a few, like Pegasystems and Savvion, include their own business rule engine within the BPMS, simplifying the integration and generally lowering the total cost. When a BPMS is integrated with a separate “best of breed” BRE, the tricky part is getting the BRE to understand the BPMS’s process data model so it can be used in business rules. While any BPMS can usually “talk” to any BRE, a special integration module between BRE vendor X and BPMS vendor Y may be required to use process data within business rule definitions.
BRE’s are adding a powerful new dimension to BPM by providing centralized global management of rules, vastly more complex rule logic, increased agility, and more business-oriented rule languages. But, as always, it’s not a simple checkoff item. You need to understand how the integration is performed, how the BRE understands and uses process data, and what kind of actions can be triggered by a business rule. And these dimensions vary widely with each BPMS.
