Change Agent: Process Modeling Will Deliver on SOA's 'IT Agility'Change Agent: Process Modeling Will Deliver on SOA's 'IT Agility'

Perhaps the most significant advance of business process management over its workflow and enterprise application integration ancestors is the integration of modeling with executable process design. Once strictly a standalone technology, process modeling has become a standard feature of BPM suites, which then go on to execute and monitor the modeled processes. By including a modeling tool in the suite, BPMS vendors give process owners on the business side a way to assert direct influence over the IT implementation.

Integrating modeling into the BPM suite adds something crucial. Instead of just creating a business requirements specification, modeling creates a skeleton implementation as well, including the key performance indicators (KPIs) monitored by the BPMS at runtime. By outputting results to the same management dashboard used for runtime management, simulation builds concrete links between the model and the IT implementation.

The fly in the ointment has always been keeping the model in sync with the final design. With BPM, we're still about a year away from that "round-tripping" capability. Some BPM suites avoid the problem by using a single tool for modeling and executable design. Either way, model-driven implementation will mark a tipping point for BPM, making it a significant force in IT--perhaps the killer app for service-oriented architecture (SOA).

A process model is more than just a flowchart. It improves business-IT alignment by creating a shared understanding of how the process works: the sequence of activities, who does what, rules and milestones. It also links activities to process resources, modeled as systems or human roles, and it lets you assign cost and availability parameters to resources. The model also should support assignment of duration, cost and revenue parameters to process activities and milestones.

The purpose of parameterizing the model is to optimize the design through simulation analysis before calling on scarce IT resources. Simulation transforms the output of a modeling tool from a business requirements document to a cost-justification analysis, with the target ROI connected to specific process-improvement assumptions. This in itself enhances business-IT alignment.

Shared understanding is enhanced by standardizing the modeling language. OMG's Business Process Modeling Notation (BPMN) is now widely accepted as the diagramming standard for process models, and an XML storage format for BPMN is very close. Standardizing the XML representation makes process models portable so they can be shared by a wide variety of BPM tools.

Transforming models into executable implementation is difficult because not every process you can draw maps easily into a particular process execution language. Researchers have found that 15 percent to 20 percent of BPMN diagrams, for example, must be redrawn to conform to the rules of Business Process Execution Language (BPEL), the standard for service-oriented BPMS. The redrawing is mathematically possible, but it takes a Ph.D. to do it. Developing algorithms to redraw those "problem" models automatically will require magic that's still in the labs.

Model-driven BPM implementation is the key to realizing the promised agility of SOA, by letting IT off-load to the business some of the burden of building and maintaining process solutions. Imagine that you want to improve a critical business process. A modeling tool lets process owners document the current process, define and analyze variants of an improved to-be process, specify its performance metrics and project ROI from the implementation. That model automatically creates a sizable chunk of the implementation. IT doesn't start over; it simply layers on additional technical detail required for application integration, data mapping, transaction management and so on--but in such a way that the model can always be re-created from the design.

The model and implementation always stay in sync. That means the simulation analysis reflects the actual implementation. When the design is deployed to the BPMS runtime environment, the system monitors the metrics defined in the model (by process owners) and supports comparison of estimated and actual performance, enabling the cycle of continuous process improvement.

This is the real promise of BPMS, and we're very close.

Bruce Silver [[email protected]] is an independent industry analyst and author of the blog BPMS Watch. Engage in the discussion at www.brsilver.com/wordpress.