I’ve posted a number of times in the past about the importance of business rules engines (BRE) in conjunction with BPM in order to keep rules and process separate. To sum up my thoughts on this:
- Most BPMS don’t have sufficient functionality in their in-process expression builders to offer true business rules capabilities. A notable exception is Pega, which is built on a rules engine. I’m not going to wax poetic on the benefits of business rules, since there’s lots of other people who can do that better than me, but take my word for it: you really need business rules.
- Having the ability to change work in progress. If the business logic is embedded within the process map, then typically that logic is fixed for a particular item of work at the time that it is instantiated. For straight-through short-running processes, this isn’t a problem, but for long-running processes (with or without human interaction), it is, since most BPMS don’t provide for changing the business logic or process map for an item of work once it is instantiated. If the BPMS retrieves its rules from a BRE at the time that each rules-oriented step is executed, then the rules are as current as what’s in the BRE.
- Using the same rules engine and rules across multiple applications, not just within the BPM. Imagine it: the same business rules about, for example, how you deal with a customer’s order in a particular situation being applied identically across your CRM, your BPMS, and any other applications that it might impact, because they all retrieve their business rules from a common business rules repository at the time of execution. This idea is just starting to creep into the consciousness of most large organizations (they’re still digesting the first two reasons), and is ultimately the most critical since it not only provides for greater business agility, but also has a huge impact on compliance.
This last point is exactly why I see Pega’s position as a disadvantage rather than an advantage: although they market themselves on the fact that they’re built on a BRE, the requirement for business rules in multiple applications across the enterprise is finally being recognized, and stand-alone BRE will become more commonplace in organizations in the next few years. And if you’re using Fair Isaac for all of your business rules across the organization, you’re not going to want to use a different, proprietary BRE inside a BPM product to re-implement some of the same rules that exist elsewhere in the organization.
I thought of this last week at the TIBCO seminar when I learned that they also have a proprietary rules engine embedded in their BPMS, although the BPMS is not based on the BRE (as with Pega), it’s just there to provide additional functionality, and TIBCO allows for integration with popular third-party BRE including Fair Isaac and ILOG. My prediction is that as organizations start to roll out these best-of-breed BRE across the enterprise, TIBCO will abandon their own rules engine in favour of integrating only with well-known third-party BRE.
{ 3 } Comments
Sandy
I think Tibco’s BRE is cordicon, if I am not mistaken.
Tom
Good post, although have to disagree that Pega’s position is a disadvantage.
Pega is first and foremost a rule engine – so you could use it as your enterprise repository without needing to employ the BPMS aspects. It also provides easy integration of external services; so conversely you can also use it as a bpms and call out to a different engine if needs be.
Pega’s big advantage is the seamlessness of the environment. You really do get compelling benefit from using it both as a rules engine & BPMS. If you want to use an external you’re no worse off than Tibco where the integration between the rules engine and BPMS is very thin.
(Note I’ve no allegiance to Pega but have just finished an in-depth eval of it vs. Tibco).
Scott, I’d love to hear more of your thoughts on this. The reason that I see Pega’s position as a disadvantage is that although Pega could be your enterprise rule repository, I don’t think that’s a significant part of their business. If an enterprise wants an enterprise rule engine/repository, they’re going to pick one of the vendors who are squarely on this space, not (in my opinion) a vendor who primarily uses it as a platform for their BPM product.
{ 6 } Trackbacks
Keeping rules and process separate, but linked
Nice post by Sandy Kemsley on ebizq – Separating rules and process. Don’t think I need to add anything to this one…
Fair Isaac
The following discloses our information gathering andBurt Helm reports for Business Week on increasing co…
Platforms, platforms, platforms
Tower Group’s Jerry Silva recently published on “.NET vs. J2EE: Does the Future of Service-Orientation Hang on Myth and Misconception” He has some great data on platform preferences in various industries, especially banking, and about how people perc…
Some business rules principles (after Ron Ross)
I was reading Ron Ross’ book Principles of the Business Rules Approach (reviewed here) and thought his basic principles deserved both an airing on this blog and some additional “sub principles” when applied to the automation of decisions using busine…
CEP needs business rules too
I saw a comment on IT Analysis that talked about The difference between complex event processing and event stream processing. I liked the distinction drawn but have to take issue with the comment Philip makes agreeing with a CEP vendor about “why and…
[...] Separating rules and process (Sandy Kemsley) [...]
Post a Comment