Forrester Day 2: The three B’s

I ended up skipping the session after mine at the end of the morning, but had some great hallway conversations with some of the business rules vendors who indicated that they think that I’m on track with what I’m saying about BPM and BR.

For the first of the afternoon sessions, I’m attending a panel discussion on the convergence of the three B’s — BI, BPM and BR — featuring Mike Gilpin (EA and application development), Boris Evelson (BI) and Colin Teubner (BPM). I covered a tiny bit of this topic in slides 22-24 of my presentation this morning, and will be doing a full-length presentation on this same topic at the Business Rules Forum next month in Orlando, so I’m interested to see if the Forrester analysts have the same thoughts on this subject as I do.

They start with the statement that “design for people, build for change” will drive the convergence of the three B’s. Interestingly, although a few people in the room stated that they use BPM and BI together, almost no one raised their hand to the combination of BPM and BR — a combination that I feel is critical to process agility. Gilpin went through a few introductory slides, pointing out that almost no business rules are explicitly defined, but are instead buried within processes and enterprise applications. He sees BI as driving effectiveness in businesses, and the combination of BPM and BR as driving efficiency.

Forrester will be publishing some reports about the convergence of the three B’s, and although there are some two-way combinations in vendor products now, there are no vendors that combine all three in a single product. I’m not sure that this is a bad thing: I don’t think that we necessarily want to see BR or BI become a part of BPM because it ultimately limits the usefulness of BR and BI. Instead, I see BR and BI as services to be consumed by BPM, with BI having the additional role of combining process execution statistics generated by the BPMS with other business data. An explicit question was asked about when to use the BR and BI included in the BPMS versus when to use a third-party best-of-breed BR or BI system; Teubner and Gilpin offered some guidelines for this as well as some examples of each situation, but it’s not completely clear if there’s a distinct boundary between when to use the BPMS’ in-built functionality versus the third-party specialist product.

My message on this topic is that BR is the key to process agility, and BI is the key to process visibility as well as feeding back into BR in order to further increase agility. By using the BR and BI functionality within your BPMS, however, you’re typically not getting full BR or BI functionality, but some limited subset that the BPMS vendor has selected to implement. Furthermore, you can’t reuse that functionality outside the BPMS, and in the case of business rules, a change to the BPMS’ rules often requires retesting and redeploying the process models, and does not apply to in-flight processes. However, if you’re not sure if you need BI or BR (hint: you do), then using the in-built functionality in the BPMS gives you an easy-to-integrate and lower cost way to get started. Moving to a separate third-party business rules system gives you a couple of key advantages: you can reuse the same rules across different processes and across other applications in your enterprise, and changes to the rule impacts in-flight processes since the rule is not executed from the BRE until that point in the process is reached. Moving to a separate third-party business intelligence system also provides the advantage of being able to analyze the process data in the context of other business data, and potentially feed back the results of complex analytics to inform the business rules, that in turn drive the business processes. The bottom line: BR and BI are used for many applications in the enterprise that are not explicitly process-related, or combine data from many systems of which the BPMS is just one source. For example, although there are processes embedded within your ERP system, your BPMS may not have direct access to all the information that’s in those processes and hence the BI that’s part of your BPMS can’t (easily) include that data in its analytics and reporting; a general-purpose BI platform may be much more suited to combining your BPMS statistics with your ERP statistics.

A lot of the conversation in this session, which was very interactive with the audience members, was around whether to use converged products versus separate products. It’s not a completely simple answer, and I’ll definitely be thinking about the use case boundaries between converged and separate products before I show up at the Business Rules Forum to continue this discussion.

Evelson and Teubner will be publishing an initial paper in this area in the next few weeks, using the concepts that they’ve presented here today, but see it as a springboard for more discussion in this area rather than an end-point.