The annual BPM Think Tank, now in its second iteration, is an event I?ve been looking forward to all year. Unlike most BPM conferences, which are generally aimed at helping newbies get started, Think Tank is a forum where experienced BPM vendors, analysts, academics, and user organizations come to discuss what needs to come next in terms of technical standards, software capabilities, and overall business value from business process technology. The event is hosted by OMG, the standards organization that last year absorbed BPMI.org, the original creator of the Business Process Modeling Notation — the emerging standard for process modeling and, increasingly, for business-driven process design.
This evening, before the event got underway, a number of Think Tank leaders gathered in an informal dinner meeting to discuss a new proposal not even on the official agenda: a way to query running BPM systems about process performance, from the state of an individual process instance to aggregated metrics displayable in a management dashboard. The idea, variously called the Business Process Performance Management Interface or the Business Process Runtime Interface, would complement BPMN?s focus on process modeling and design.
Even if the entire BPM world suddenly standardized modeling and design on BPMN, today there would still be no standard for the runtime artifacts of executing processes, i.e. the data used to measure process performance. Each BPMS defines and stores those artifacts in its own way, from how it logs process state information and related business data to how it propagates that information in the form of events, to how it correlates and aggregates those events in KPIs and other performance metrics, and displays the aggregated data in management dashboards and alerts.
The proposed new standard would do for process performance data what BPMN is doing for front-end process modeling: allow process information to be understood in a common way across vendor offerings and become accessible to third party tools. If such a standard became widely adopted, process performance data would not be the proprietary domain of BPMS vendor-specific performance management engines and dashboards, but could be incorporated, for example, in the performance management dashboards created by leading business intelligence software vendors.
Wouldn?t it bother you, I asked the CTO of one BPMS vendor advocating for the new standard, if your customers didn?t use the performance dashboards of your own BPMS but funneled all their process performance data to Cognos or Business Objects? Not at all, he replied. We don?t want to be in the dashboard business. As long as our BPMS owns the data, we?re fine. In fact, a number of our customers have more than one BPMS vendor installed and are looking for ways to tie together management data from all of them. Today there?s no way to do that.
My gut reaction is I see the need, but BPMS as a technology has more immediate concerns, such as really standardizing BPMN, for instance, with an official metamodel that nails down the precise meaning of all the graphical constructs, and a standard XML schema to store and exchange process models. At last year?s Think Tank OMG was supposed to be working on that, and it still isn?t done. That?s coming soon, however, according to OMG sources. A new draft of the Business Process Definition Metamodel (BPDM) covering BPMN and process orchestration is due in June. The final BPDM draft needs to tackle the harder problem of message exchanges between the processes of two trading partners, called choreography.
Standardizing the precise semantics of BPMN could have a profound effect on BPMS. A number of vendors are already using it as a common modeling and executable design tool shared by business and IT. Others are using it for modeling and simulation analysis, followed by automated mapping to BPEL, creating a skeleton implementation completed by IT in a technical design tool. Vendors are beginning to automate the mapping of BPMN to BPEL and back again, allowing the model and executable design to stay in sync even after IT has fleshed out the implementation. If BPMN became a portable standard for modeling and business-oriented process design, it could make the underlying execution language, whether BPEL or vendor-proprietary workflow language, almost irrelevant.
If OMG can make BPMN a success, BPPMI (or whatever it winds up being called) is a logical next step. The reason BPM is becoming the ?business face of SOA? is its emphasis on performance management. With BPM you can model process performance, analyze it through simulation, instrument it in execution, and continuously monitor it in dashboards and alerts. Standardizing access to process performance data brings BPM into the broader realm of corporate performance management, which is a true CEO concern.
Success with both BPMN and the performance management interface would firmly establish OMG and its BP-* standards as the business-oriented management layer for SOA surrounding the WS-* technical standards stack managed by OASIS and W3C, and would likely lead to well-defined mappings between the two. That would mark BPMS as truly mainstream IT. When it happens, I can say I remember when that started at the BPM Think Tank.
I think that BPRI is critical, now, because customer organizations are building ad hoc solutions to do exactly that. Most of the large companies that I work with have multiple BPMS and have no intention of using a BPMS’ dashboard as their performance management tool: they have a full-on solution such as Cognos, and want to just seamlessly feed into that.
BPRI shouldn’t wait for BPMN to be “a success” (however that’s measured), but should be developed now to fill the ever-increasing void in incorporating process runtime analytics into corporate performance management.
Bruce, it was good to catch up at Think Tank … and I am glad that both you and Sandy see the sense in what we are trying to do with this runtime BPM data thing.
The idea is to standardize the way in which runtime data is stored to enable a new raft of innovation – both in terms of the reporting that is possible, but also a common worklist and the ability to optimize process execution on the fly. Indeed, if we get this right, it then becomes possible to do things like “find me all process instances that relate to this customer, and have them displayed to a customer service rep who is handling the call and ensure they are all dealt with”. Or as in one of my current client scenarios (working with a major police force) “find me all cases related to children under the age of 10 who are deemed to be at risk”.
What I am getting at here, which is perhaps missed by some who look at this issue, is that with a user extensible meta-model of runtime data, we take the lid of what is possible.
Your dashboard then effectivley becomes a mechanism to steer the organisation (whether that is a fully blown concept such as Cognos or Hyperion or a more humble cockpit in the BPMS itself.