Where Rules Management and BPM Meet

Business in Balance

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!

By Bruce Silver
October 1, 2006

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.

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.