For years, these capabilities have been the exclusive domain of business process modeling tools from vendors such as Casewise, IDS Scheer, Popkin (now Telelogic), and Proforma, often as part of a broader suite of enterprise architecture tools. Now, however, vendors such as Global 360, IBM, and Savvion are implementing the process modeling functions of these tools within the BPM suite itself. At the same time, modeling vendors are improving interoperability among BPM suites by leveraging BPMN (business process modeling notation), a standardized graphical notation from the Object Management Group.

Where once the output of process modeling was a business-oriented specification intended to guide IT in any implementation efforts that might be needed, BPM assumes an automated process implementation will be executed on the process engine.  Modeling standards such as BPMN and interchange formats such as CIF allow the output of a modeling tool to be imported into a BPM suite's design tool and a skeleton implementation design to be generated. This skeleton design lacks the implementation detail to be executable off the bat, but it creates a business-specified starting point.

The closed-loop problem

Even with standard BPM design languages such as BPEL, each vendor's process design tool is specific to its own runtime environment. Today, there is no such thing as a portable process design that can be executed on your choice of process engines -- unless, of course, you consider human tasks, business rules, and complex data mapping to be "external" to the business process design.

Most BPM suites today provide a unified design environment that hides the complexity of combining human workflow, application integration, business rules, and transaction management within a single executable design. The benefits this provides over treating these process components as independent entities in the enterprise architecture stack are a common data model and common state management over the entire end-to-end process. 

Click for larger view.

Like modeling, process design is mostly graphical. The tool provides a palette of activity types from which the designer selects, configures, and assembles the process steps. Unless custom activities need to be created, process design involves minimal programming. Behind the graphical design metaphor, the tool creates an executable process implementation in the BPM suite's particular process execution language.

In BPM suites based on workflow architecture, the language is typically proprietary but compliant with the XPDL (XML Process Definition Language) standard from the Workflow Management Coalition. Process activities may be one of several predefined implementation types (Web service, user task, integration activity)‚ each assigned to a resource, such as a human task role or an integration adapter. The configuration dialog for each activity depends on its type.

By contrast, BPM suites based on service orchestration rely on the BPEL language standard. BPEL provides a single activity type -- Invoke -- to call a Web service, human task, or integration adapter, all of which must be implemented as a service, with an interface described by WSDL. But Invoke must be addressed to a service end point -- a URL, not a task role. To accommodate human tasks, what gets invoked by BPEL is not the user task itself but a task manager service, which handles the workflow details.