BPM and BR: Mars and Venus again

As I mentioned in this post, there’s a bit of Mars and Venus about BPM and business rules (BR).

I’ve viewed two BPM-BR webinars recently. The first, a replay from back in March on the convergence of BPM and business rules; since I’ve been writing a lot about this topic lately, I gave it a quick browse. It’s hosted by BPM Institute; there are a lot of other webinars (“round tables”) on BPM-related topics on their site, both past ones that you can replay or future ones that you can sign up to attend live. The speakers in this webinar were from Knowledge Partners and Pegasystems, both heavily into business rules: Knowledge Partners is a business rules consultancy that also does some training and software extensions that integrate business rules with other platforms such as RUP, and Pegasystems is a BPM vendor whose product is built on a rules engine.

You’d have to have your head in the sand not to notice the importance of business rules in BPM, but if you’re still having trouble convincing anyone, then this webinar might give you a few pointers about why it’s so important. From a business standpoint, the two key drivers for having BR in your BPM are agility and compliance: the rules that define your business must be flexible and extensible (agile), as well as explicit and measurable (compliant). To have these rules explicitly defined and managed by the business community, separate from the logic in the BPMS, goes directly to the issues of agility and compliance. The speaker from KPI made the point that your business is already running by these rules, whether you know it or not, and by collecting them into a BRE, you’ve made a step towards getting control of your rules and procedures (and therefore compliance).

To decide where the interface lies between BPM and BR, take a look at your processes (c’mon, I know that you’ve modelled them already) and highlight the activities that involve decisions and rules, such as scoring. These activities are where you’ll invoke business rules, whether directly in the BPMS (as with Pegasystems) or by calling a third-party rules engine. These rules should be directly tied to business motivations/key performance indicators. Then, walk up KPI’s pyramid:

[As a side note, I especially like the second step in the pyramid: “understand which rules are worth managing formally, and why”. Organizations typically get locked into the old way of doing things not because things are done in a certain way, but because no one understands why something is done that particular way.]

The KPI speaker pointed out that there are often different groups within an organization who are looking at BPM and BRE, with one from the business side and the other from the IT side. She mentioned the scenario of BPM being driven by business and BRE by IT, but I’ve seen it the opposite way around recently with a large insurance company client. In fact, I think that most people who even think about this see BPM as still “belonging” to IT, whereas BR “belongs” to the business. I could write a large tome on why they both belong to the business, but that’s for another day.

Yesterday’s live webinar was by TIBCO on increasing your BPM ROI by incorporating BR; there’s a registration form on the TIBCO site that I assume takes you to a replay of the event. The main speaker was John Rymer from Forrester, and he gave a good overview of how BR improves BPM. From his presentation:

  • Speedy, accurate business decisions and actions
  • Common expressions of policy, practices, other logic can be evolved in business time
  • Single source of truth for core business rules aids compliance reporting
  • Automation of conditional steps in flows and conditional calculations improves agility
  • Business analysts can make adaptations and change

He showed how these factors related to hard ROI in this chart:

This is not different from the KPI/Pegasystems webinar mentioned above; it all comes back to agility (by allowing changes to rules without changing the process flow, which is somehow seen as less agile) and compliance (through standardization and documentation).

Rymer sees three different BPM-BR implementation scenarios: the decisions are embedded within the BPM flow; the BPM is rules-based (like Pegasystems); or the BPM “calls out” to a general-purpose rules engine. There is a fourth scenario, which I have seen used (and have myself implemented) extensively, which is that the rules logic is resident in another system, sometimes a legacy system, and the BPMS integrates with that system in some way to execute rules. This is a broader definition of “call out” that includes his third scenario, and I’ve seen it often in insurance implementations where underwriting or claims rules are already implemented on a legacy system and just need to be called at a point in the flow.

Since TIBCO hosted this webinar, they found an analyst who speaks very well of the idea of having a BRE embedded within your BPMS; I don’t disagree with this, but I can also see the advantage of having the BRE as a foundation of the BPMS, as with Pegasystems, or even using a third-party external BRE that may also be in use for other rules applications within your organization. It works any of these ways; the important thing is to have a BRE in there somewhere.

No matter how it’s implemented, I imagine that some BPM advocates may see the integration of BR as somehow demoting the importance of BPM: for years, the BPMS vendors have been building increasingly advanced decision-making capabilities into their products, and now the BPMS will just be used to route work and call the BRE when instructed. My advice: get over it. Sure, you’re going to build much less complex decision-making directly in the BPMS once you integrate a BRE, but you’re going to get so much more in return.

Leave a Reply