Click for larger view.
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.