Analysis: Where Rules Management and BPM Meet

Rules management and process management are both aimed at improving business agility and performance, but they're fundamentally different technologies designed for complementary purposes. So which tasks do you handle in each toolset? We'll show you how to strike the right mix of techniques and score that perfect 10!

Bruce Silver, Contributor

September 11, 2006

11 Min Read

Is your company trying to accelerate cycle times, lower costs, improve responsiveness, ensure compliance with policies and best practices, and increase customer satisfaction? Well, of course! That's why you need a comprehensive approach to managing your organization's business rules. Wait a minute. Aren't those the same things business process management is supposed to do? Confused? That's understandable.

Unfortunately, business rule management and business process management (BPM) are increasingly being pitched as competing options--or one-size-fits-all solutions to business improvement--by vendors and consultants who focus on one area or the other. After all, BPM systems are based on rules, and business rule engines can execute actions without a BPM system.

In reality, BPM suites and business rule management systems serve fundamentally different and complementary purposes. In many cases, you need to use them together to fully achieve the goals of agility, alignment, compliance and the rest. The trick is striking the proper balance: Which rules are the domain of the BPMS and which are managed by the BRMS? What actions should be taken by the business rule engine, and what should be left to the process engine?

These aren't questions vendors and consultants tend to talk about, but this article will help you find the right mix and match the right tools to the task (or decision) at hand.

Process Logic Vs. Decision Logic

Business process management offers tools and methodologies to model, execute and manage the sequence of activities in a business process, separating process logic--the activity flow, task assignment, deadlines and escalation, and exception handling--from the business logic embedded in back-end applications. Business rule management provides similar tools and methodologies to model, execute and manage decision logic, unearthing that logic from back-end applications and business process logic.

Not all rules are business rules; business rules are just those used in decision logic. For example, in loan origination, the activities described by process logic might include receiving the loan application, ensuring completion, gathering supplementary information, underwriting and approval, document generation, updating the transaction systems, archiving for compliance and notifying the customer. Decision logic in that process might determine whether the supplied information is complete, handle credit scoring and other risk assessment, execute the required level of approval and ensure regulatory compliance. You could implement that decision logic using BPMS process logic or by embedding it in process tasks, but doing it with a BRMS makes decision logic more visible to business managers, more consistent across the enterprise and easier to change as required. For complex decisions based on hundreds of rules, using a BRMS in conjunction with BPM may be the only way to go.

By itself, a BPMS can automate simple rules but not manage them effectively. Similarly, a BRMS can trigger the execution of individual activities but not manage them as components of a business process. You need to use the two systems together.

Put The Business In Charge

Just as BPM is more than simply process automation, business rule management is more than just a business rule engine. In fact, the heart of a business rule management system is in the rule repository, which supports rule discovery, governance, versioning, traceability and reuse across the enterprise. The business rule engine executes business rules defined in a structured rule language supported by the BRMS rule design tool. Leading BRMS offerings from the likes of Corticon, Fair Isaac, ILog and Pegasystems vary in the level of technical skill required to implement and change the structured rule language.

Generally speaking, business rule management goes further than BPM in its promise to put businesspeople directly in charge of executable rules. To facilitate this, most BRMSs support rule templates in which variants of a rule created in the structured rule language can be specified by businesspeople via selection of a rule parameter. For example,

If Customer.balance > [param-1] then Customer.category = [param-2].

In addition, rule maintenance applications provide a Web interface through which business managers can tweak rule template parameters without touching the rule design environment.

Many BPM suites provide their own business rule engine but not a rule repository or true rules management. By extracting decision logic from the BPMS and managing it in a BRMS, you can apply rules consistently across multiple processes, across BPMS platforms and even in non-BPM applications. Rules are stored and managed in one place. Change a rule once and it takes effect immediately everywhere it is used, without having to change the processes and applications that rely on the decision logic. With rule templates and rule maintenance applications, nontechnical process owners can implement rule changes on the fly, safely, without troubling IT.

Play By The Rules

Like BPM, business rule management is not simply software technology, it's also a management discipline. And as in the case for business processes, many consultants and practitioners of business rule management believe you can achieve great benefit simply by documenting and centrally managing business rules, even without executing them on a business rule engine. You don't need a BRMS, just a methodology for capturing business rules in plain English from subject-matter experts in the line of business and then structuring that captured knowledge according to a few basic principles.

Barbara von Halle, one of the leading practitioners of the management discipline of business rules, describes 10 quality criteria that lead to rules that are clearly stated, easy to understand, precise and consistent:

1. Atomic--Represents one and only one fundamental constraint or guideline.

2. Precise--Has only one possible interpretation.

3. Declarative--States the nature of the constraint, not how it is enforced.

4. Justified--Linked to business objectives.

5. Authorized--Linked to a responsible entity in the org.

6. Complete--Does not require additional information to make decisions.

7. Essential--Is not redundant to another rule.

8. Consistent--Does not conflict with another rule.

9. Accessible--Can be located for use.

10. Traceable--Linked to both policies and decisions where used.

Capturing and organizing rules this way is typically performed by a business analyst, sometimes called a business rules analyst. The process doesn't require implementation of a BRMS, but benefits are gained when the results of such careful rules modeling are then implemented in a centralized platform for decision management.

It's important to remember that a single business rule is typically reused in many decisions in multiple applications and processes. In the BRMS, individual rules are grouped into rule sets. The BRMS design environment typically provides a variety of rule set types, including decision trees, decision tables and scorecards. Decision logic determines which rule sets to evaluate under what conditions in order to return the decision. A decision service lets an application or business process execute a specific piece of decision logic on command (increasingly over a Web service interface).

SOA Makes Its Mark

Service-oriented architecture (SOA) is changing the way business rule management and BPM work together. Gartner has listed business rule management as one of the key functional components of a complete BPM suite. As a result, most BPMS vendors have either implemented their own business rule engine within the suite or entered into a partnership with a BRMS vendor. However, instead of proprietary integration based on such formal partnerships, today any BPMS that can invoke a Web service can execute decision logic managed by a BRMS. A better way to think of BRMS is as part of the SOA layer of enterprise IT. Like ordinary business services, business rules have their own repository, registry and governance infrastructure. The BPMS simply orchestrates them, along with other process activities, via standards-based interfaces.

Even though a BRMS can take actions such as executing a Web service or starting a business process, it would not be considered good business practice when it is integrated with BPMS. Instead, a decision service implemented on the business rule engine should return the decision result as data back to the BPMS. That preserves the separation between process logic, maintained within the BPMS, and decision logic, maintained within the BRMS. The process logic can then use the decision output to select a branch in the flow, assign a particular user or group to a process task, start another process or alert a manager.

In addition to implementation as a process activity, a decision may implement an automated function within a human task. For example, just as a field in a Web form can automatically look up a value from a back-end database, it can execute a decision service and display the returned output. Some BPMSs implement screenflows composed of multiple HTML pages and automated functions, including business rules. Thus, business rules can control the dynamic look and feel of individual process tasks.

Let Usage Be Your Guide

What kind of rules should be implemented in a BPMS without resorting to business rule management? In most cases, this depends on the scope and reuse of the rule. If it's just used in a particular process, and the rule logic is not especially complex, implementing it in process logic is fine. Everyone is familiar with rules of the type

If Loan.amount > $10,000 approval by VP is required

BPM often describes such a decision as logic directly implemented in a branching step or transition condition in the process flow. But is that rule actually a bank policy that applies to other processes and applications as well? What if the policy should suddenly change to make the threshold $5,000? If the rule is used in multiple processes and applications, implementing the rule in a BRMS is a better choice. The rule repository not only provides the decision logic, but also the source of the rule, where it is used, who is authorized to change it, and so on. A BRMS manages business rules consistently across the enterprise and lets you change those rules easily as needed. In the continuing quest to manage processes more effectively, off-loading this work to an external rule management infrastructure just makes BPM better.

Bruce Silver is an independent industry analyst and author of the blog Bpms Watch. Write to him at [email protected]. Engage in the discussion at

What's The Difference?

BPMS vs. BRMS: Business process management suites are designed to model, execute and manage complex processes, whereas business rules management systems are designed to automate complex decisions. Many BPM suites provide basic business rule engines, but you don't get the rule repository or rules management capabilities required to manage and reuse scores, if not hundreds, of rules. Similarly, a BRMS can initiate actions, but it's not designed to manage the many tasks in an end-to-end process.

Process logic vs. decision logic: Process logic controls the sequence and flow of activities, including task assignment, deadlines, escalation and exception handling. Decision logic can comprise hundreds of business rules, checking, for example, whether information is complete, assessing risk such as credit worthiness, executing approvals and checking regulatory compliance.

Process modeling vs. rule languages: While BPMSs provide visual modeling tools that lets business analysts design and modify processes in drag-and-drop fashion, BRMSs employ templates and structured rule languages that let business people select and tweak rule parameters without touching the rule design environment.

Executive Summary

If your organization is struggling to increase productivity, ensure process consistency, meet compliance demands and improve IT flexibility and responsiveness, you'll likely encounter both business rule management systems (BRMS) and business process management suites (BPMS) as potential answers to these challenges. Confusingly, each technology crosses over into the function of the other, but BPMS and BRMS serve fundamentally different and complementary roles. The key is to strike a balance, handling certain tasks in the most appropriate domain.

The idea is to handle process logic that controls activity flow, deadlines and exception handling in the BPMS and decision logic that quickly provides answers to complex, multivariable questions in the BRMS. Both systems model, execute and manage this logic, abstracting it from back-end applications so business users can see and change it as required without facing long delays for conventional IT coding and testing.

A BPMS can automate simple rules, but it can't effectively manage complex rules or those that are used across multiple processes. Similarly, a BRMS can trigger the execution of individual activities, but it's not designed to manage the execution of complete business processes. By using the systems together, your business gains more complete and effective control over each process and decision point.

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights