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.

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

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.