by Jim Minihan, Document Magazine
04-19-2008
For the uninitiated, entering the market for a process management application can be daunting. An alphabet soup of acronyms abounds, with many having multiple meanings. And then there is the age-old debate of “workflow” versus “BPM.” With such a range of products all claiming the same marketing space, regardless of how capable they are, one can’t help being confused. Indeed, this problem has been so pervasive it hindered the marketplace adoption of the entire workflow/BPM product class for a good five years before some sense emerged from the fog of the marketing wars.
So how do we bring some definition to all this? Suffice to say that at some point, the more robust products started to carve out a new world to trump the old. More specifically, this meant that an ability to collect process metrics and operate variably on a much more sophisticated array of “rules”-driven parameters became a distinguishing characteristic. At the same time, it seemed that every application in the world claimed to have a workflow component. From an enterprise view, this meant that there were a number of “line of business” systems, each with its own workflow. Since enterprise processes generally span multiple application systems, these silo-restricted workflows fail to do much for an enterprise-wide view, thus, the need to orchestrate these individual systems and the people that interact with them comprehensively.
So is workflow still relevant? Has it been replaced by BPM entirely? The answers depend on what you want to accomplish. At a departmental level working within a single application, you might very well decide to employ a workflow product to better control the processes and procedures that surround that legacy application that may not have a workflow. This is still a legitimate, if narrowly defined, approach to getting better control of a tactical problem.
For the heavy lifting of sewing together many applications and the people that interact with them in a strategic way, a BPM tool should be your focus. This class of application has become increasingly popular with the advent of service oriented architectures (SOA) to orchestrate and connect the various components that comprise a solution. A useful BPM suite will have several essential components. A modeler is used to express the process and the various elements of it. A process engine (different vendors may have other names, such as “rule processor” or “orchestrator”) is the run time component that serves as command central for activities in the process. A Business Activity Monitor (BAM) is another component focused on accumulating process metrics that can be used to cause real-time adjustments at the process engine and provide management data about the operation. Tools and APIs are also included to enable the connection of the BPM to applications and, in some cases, application to application. In addition, some suites will include BPEL (Business Process Execution Language) as another tool to tie system-to-system transactions together, and some vendors will also assert that a simulator is necessary to test a process prior to deployment.
Don’t be surprised if you hear people insist that many of these components existed in workflow applications long ago. Some will even claim that BPM had nothing to do with workflow and came about independently to set their products apart. Dismiss this as more marketing wars hype, and concentrate on what the product can do for you today and leave the history to the historians.
Download: Full PDF Article