Business Rules and BPM
Monday, January 30th 2006 | Bruce Silver
A trackback to one of my BPM posts on this site raised the issue whether BPM and business rules should rely on the same engine. The confusion on this point continues to surprise me. Maybe some people consider any piece of process logic involving a bit of business data a “business rule,” so the process engine should be a business rule engine, right? Wrong. Business rules and business rule engines, as they are understood by vendors and users of rule engine technology, are about making decisions from a collection of assertions or “facts.” They are especially useful when the potential set of facts is large, such as those determining whether to approve a loan, what premium to charge for car insurance, or the applicable discount to a particular customer for a particular set of products at a particular point in time. These kinds of decisions come into play on occasion in BPM and in those cases the process engine invokes a ruleset deployed on a business rule engine.
The poster’s statement that “many workflow engines use rule engines at their core” is misleading or downright false. A process (workflow) engine is not a rule engine, or at least not a business rule engine. The only BPM suite I know of in which a rule engine forms the core is Pegasystems.
Rules in the generic sense are used in process logic in 3 basic ways:
1. Decisions. If the decision is simple enough to be implemented with an expression, even a complicated expression, no need to use a rule engine. If the decision depends on a large number of facts, only some of which will be supplied for each instance, a business rule engine is best.
2. Routing logic. This is the primary implementation of “rules” by the process engine. An expression determines which branch to take in a flow (e.g. Switch in BPEL); I suppose you could consider any conditional logic (e.g. Pick, Link) a “rule”. About a year ago, before BPM vendors started bringing 3d party rule engines into their suites, some tried to FUD the issue by calling these routing rules “business rules.” Happily we’re past that point now.
3. BAM. At runtime the process engine emits events marking state changes in the process instance. The BPM suite’s performance management component collects these events and uses them to aggregate predefined business metrics. A subset of those metrics, often called KPIs, is continuously monitored by rules that trigger some action when the rule fires, like triggers in a database. That capability is called business activity monitoring, or BAM. Some vendors call these “event rules.” They typically do not use a business rule engine.
The poster goes on to say that business rule engines should be service-oriented. Well, Duh. Virtually all integration today is service-oriented. Most BREs provide a single service interface for all rules, while some like Corticon define an interface for each ruleset.
Most BPM suites today accept the need for business rules in some circumstances and provide integration and co-marketing with one or more of the leaders, like ILOG, FairIsaac, or Corticon. Infrastructure vendors like IBM and Microsoft may provide their own as an app server feature. Pegasystems is the only vendor that plays in both the BRE space and BPM space (e.g. in Gartner magic quadrant for both).
Pega integrates business rules in ways that other BPMS cannot, such as determining the individual user to perform a particular process task, or the appropriate screen presentation for a user task. At the other extreme, at least one BPMS, Fuego, poo-poohs the need for BRE, since their process activities are user-defined scripts using the Fuego Business Language, not limited to simple expressions. In some BPEL engines you can write inline Java as well, but I’m not sure this is “moving the ball forward” as a business rule implementation strategy.
The last point highlights another key difference between business rules and process rules. Business rules are maintained in a repository independent of any process definition. They apply to the business, not to a single process. Process rules are not only specified within each process definition but at a particular step in that process. Thus when the rule changes, it needs to be modified in every step in every process definition where it is used.
A free white paper describing the complementary roles and integration of BPM and BRE can be found here. It is written in the context of FileNet and FairIsaac, but applies to process engines and rule engines in general. Illustrations of how business rules and BPM are implemented by Pegasystems, IBM, Savvion, Fuego, Global 360, Adobe, and Vitria can be found in the 2006 BPMS Report, a free download from BPM Institure.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Excellent summary Bruce. The ongoing confusion between the rules in BPM and other applications and the use of business rules technology to automate decisions is not helping anyone. Thanks for helping to keep these clear and distinct.
To help those that may still be confused by how business processes can be so different from business rules, let me try to propose some properties to distinguish them. These are debatable, but I often find them to be quite useful to determine whether I should implement some business logic as a business rule or as a business process.
Visibility. When you consider a business rule, which is all about evaluating some conditions within a specific context, it does not really matter how the rule is computed. You only really care about its outcome, so that you can decide what to do next. You do not need to track every single steps the logic went through in order to give you the output. Business processes are quite the opposite. Traceability is key and you want to make sure that a business process follows exactly all the steps you want it to, and you also want to be able to check after completion that indeed it did what you expected. If you consider certification processes, the “how” you got certified (or not) is at least as important as the outcome.
Completeness. It is very important for business rules to capture all possibilities. For example, when insurance companies validate claims and check all sorts of parameters to evaluate what to do with them, it is critical that there is not a single combination of these parameters that could not be treated in a way or another. Business rules must support the complete problem they have been designed to support. On the contrary, it is totally acceptable not to have business processes for everything.
Consistency. Business rules must be consistent within the “space” where they apply. There should not be conflicting rules that could lead to two different decisions with the same or overlapping data sets. Although consistency is typically better, it is acceptable for business processes not to be consistent. It might even be a good idea to deploy inconsistent processes in order to investigate how they perform and identify which strategy works better. Again, this is typically not an objective to define inconsistent processes, but it is interesting to notice that enforcing consistency is not as important for business processes as for business rules.
Performance. Typically, it does not matter how rules are being executed (see visibility) but it really matters that they are computed as fast as possible as they often constitute a performance bottleneck (CPU cycles). Time is an important aspect of a business process. Executing processes as fast as can be is typically not the primary objective. Using a BPMS to code logic that should execute as fast as possible is not using the right tool for the right thing.
This is not an exhaustive list but hopefully it can be helpful. What is interesting about these properties is that for each of them the difference may sometimes be as clear as I described it here. In fact, in many cases, they overlap. This may explain why there is so much confusion between the two, and why some people stretch a Business Process engine to use it as a Business Rule Engine and vice versa.
The above properties are also interesting as they can help understanding what differentiates a business process engine from a business rule engine, internally. A BRE will typically compile business rules, optimize the generated code, consolidate it, etc. Just like a compiler. A Business Process Engine works more like a virtual machine. It does not make sense for a process engine to compare processes between them and try to optimize the technical execution. Business processes are improved by analyzing business performancel, whereas business rules are improved thanks to mathematical algorithms to simplify them and optimize their global execution. This is also why you have so many different types of rule engines (they will like to talk about their rocket science) but not so many different types of business process engines (where there is really no rocket science).
So when you have to implement some logic and you are not sure if you need a business rule engine or a business process engine, think about what’s more important to you: execution speed, consistency checking, and completeness or traceability, business activity monitoring and business performance analysis.
Short version: Business processes come from the field of concurrent processing (e.g. pi calculus). Business rules come from the field of predicate calculus (e.g. forward and backward chaining). The two computational paradigms share little in common. But they make a great combination.
A BPMS, in my view, need to combine a process vm with a BRMS (Business Rules Management System). This provides the required business agility. The BRMS allows for the management of the business rules, which is very convenient for some tasks - such as changing a policy in real time or in response to external events. A BPMS needs a BRMS inside.
How about some terminological agreements for BPM 2.0:
- BPMS - Business Process Management System
- BRMS - Business Rules Mamagement Systm
- BRE - Business Rules Engine, within a BRMS
- pvm - Process Virtual Machine, within a BPMS
- A BPMS includes a BRMS
In the same way that business processes and business policies are equal and independent - but interlaced -aspects of a company’s operations, BPMS and BRMS are equal and independent - but interlaced - technologies that support the management of these aspects.
Neither of these new management systems should be subsumed by the other, included in the other, or otherwise enveloped by the other.
As long as there is benefit to be gained in using BRMS with OR without BPMS (and there is), BRMS should remain independent.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment