There’s an awful lot of keynotes in this conference: a couple of overall sessions this morning, now “track keynotes” for each of the four tracks within the BPM conference. I’m in Bruce Silver’s New Directions in BPM Tools and Technology session, where he started by taking a gentle poke at Gartner, saying that BPM is more than a management discipline (Gartner’s most recent definition of BPM).
He started out discussing process modelling, and how it’s inherently a business activity, not an IT activity, which speaks directly to the issue of the tools used for modelling: is there a handoff from a modelling-only tool to an execution environment at the point of business to IT handoff, or is the model actually just a business view of the actual implementation? With all of the vendor demos that I’ve done lately (I know, I have yet to document many of there here, but I’m getting to it), I’ve had quite a focus on the distinction between having a model shared between business and IT, and having a separate BPA tool that models much more than just the processes that will be implemented in a BPMS. Bruce positions this as “BPA versus BPMN” views towards describing process modelling, and doesn’t see them in conflict; in fact, he thinks that they’re ignoring each other, a viewpoint that I’d have to agree with given that BPA initiatives rarely result in any processes being transferred to some sort of execution engine.
Bruce, who often accuses me of being too nice, takes a stab a the vendors in a couple of areas. First is with their BPMN implementations, specifically that of events: he states that many of the execution engines just don’t support intermediate events, so that the vendors conveniently forget to include those events in their BPMN modelling tool. Second is with simulation, and looking at whether a vendor’s implementation is actually a useful tool, or a “fake” feature that’s there to enable it to be checked off on an RFP, but not functional enough to make it worth using.
He has a nice way of categorizing BPMS products: by vendor speciality (e.g., integration, human-centric), by process type/use case (e.g., production workflow) and by business/IT interaction method (collaborative shared model versus handoff). This was interesting, because I wrote almost identical words two days ago in my presentation for the Shared Insights Portals and Collaboration conference that I’ll be speaking at next month; great minds must think alike. 🙂 His point, like the one that I was making in my presentation, is that most BPM products have some strengths and some weaknesses that can make or break some process automation; for example, a product focussed on human-centric workflow probably doesn’t do some nice integration tricks like mapping and transformation, or complex data objects.
He also makes a good distinction between business rules (implemented in a BRE) and routing rules (implemented in a BPMS): business rules represent corporate or departmental policies that may need to be shared across business processes, whereas routing rules are the internal logic within a process that’s just required to get through the process but don’t represent policy in any way.
Bruce thinks that BPM and SOA together is still vapour-ware for the most part: it’s what the vendors are selling but not typically what they’re delivering. In particular, he thinks that if the BPMS and the ESB are not from the same vendor, then “all bets are off” in terms of whether a BPMS will work with any particular ESB or other services environment.
The session turned out to be too short and Bruce couldn’t even finish his materials, much less take questions: it was only 45 minutes to begin with, and shortened at the beginning while Bruce waited for stragglers for the previous session to make their way upstairs.