Executive Briefings

Standardizing Management of Process Performance

I recently attended an event where experienced BPM vendors, analysts, academics, and user organizations came to discuss what needs to come next in terms of technical standards, software capabilities, and overall business value from business process technology. The event was hosted by OMG, the standards organization behind the Business Process Modeling Notation standard used for process modeling and, increasingly, for business-driven process design.

One of the "offline" discussions that took place revolved around 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. This is something that the OMG is still working on; hopefully it's coming soon. 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 BPMN becomes widely adopted as the modeling standard, 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.

I recently attended an event where experienced BPM vendors, analysts, academics, and user organizations came to discuss what needs to come next in terms of technical standards, software capabilities, and overall business value from business process technology. The event was hosted by OMG, the standards organization behind the Business Process Modeling Notation standard used for process modeling and, increasingly, for business-driven process design.

One of the "offline" discussions that took place revolved around 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. This is something that the OMG is still working on; hopefully it's coming soon. 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 BPMN becomes widely adopted as the modeling standard, 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.