Following his excellent article on Process Component Models and JBoss Process Definition Language (jBPM), Tom Baeyens has just published another one, explaining different forms of business process management (BPM) through seven distinct use-cases .
According to Tom:
The term BPM is highly overloaded and used for many different things resulting in a lot of confusion. These use cases give concrete descriptions for the different interpretations of the term BPM.
The first use case tries to explore BPM as a discipline:
BPM as a discipline refers to the analysis, documentation and improvement of the procedures that describe how people and systems work together in an organization. Realize that most BPM is done in this way, not even resulting into any form of software or IT support. MS Visio is one the most used tools to document business processes.
This definition departs slightly from well-established and widely adopted BPM definitions, for example the one by Van der Aalst and colleagues:
BPM is a field of knowledge at the intersection between Management and information technology, encompassing methods, techniques and tools to design, enact, control, and analyze operational business processes involving humans, organizations, applications, services, documents and other sources of information.
Or Wikipedia’s:
BPM covers activities performed by organizations to manage and, if necessary, to improve their business processes. Software tools called business process management systems (BPM systems) have made such activities faster and cheaper. BPM systems monitor the execution of the business processes so that managers can analyze and change processes in response to data, rather than just a hunch.
Both definitions emphasize three main components of the mature BPM systems: process design, implementation and monitoring, where the last one is notably absent in Tom’s definition (and the rest of the use cases). Because you can’t improve what you do not measure, process monitoring is an essential component of BPM.
The rest of this use case concentrates on business process design, transitioning from design to implementation model and keeping the two in synch. When it comes to the design, Tom’s article concentrates on only one facet of BPM design - graphical representation of the process:
Original analysis diagram should serve as input with the rest of the software requirements. Developers should then construct an executable process that looks as close as possible to the original analysis diagram.
Although it is hard to argue this point of view, the question is whether diagramming truly represents process design. The more accepted approach to the process design is tooling that in addition to diagramming supports:
- Process validation, ensuring that the designed process is "implementable".
- Process simulation, which allows for a more disciplined process improvement through simulation of impacts of the process changes.
Granted, the majority of such tools employ a process model which is sufficiently different from a process execution model, which often makes transformation between these two models a week point of the overall approach. Although it’s easy to agree with Tom that "an automatic translation between pure analysis models and executable process models are not feasible in general", usage of a single model for both (jBPM approach) is not the only solution. Oracle’s implementation, for example, provides "partial" roundtrip support between BPMN and BPEL
The second use case concentrates on ad hoc task management based on Human Interaction Management (HIM) model. Inclusion of ad hoc collaboration processes into the mainstream BPM implementation will definitely increase the reach of existing BPM systems.
A story in HIM reflects a task that person creates for which an ad-hoc process will be created. People can get involved in different roles. There are big benefits of tracing such work with a task management system. First, people that get involved with such a task after a while will get instant visibility into the history of the whole story. And secondly, an audit trail is logged automatically.
Two closely related use cases, Service Orchestration and Transactional Asynchronous Architectures, discuss implementation and invocation of process activities, which is the foundation of the process execution. It is not completely clear what Tom’s intent in discussing these two patterns was – demonstrate differences between jPDL and BPEL? Explain technical details? Granted Java-based jPDL provides greater flexibility, but what Tom does not explain is the price of this flexibility - the additional code that a developer has to write. In a nutshell, the difference between BPEL and jPDL is that BPEL is a form of domain specific language (DSL) designed for implementation of business processes, while jPDL is a Java-based framework for building either processes or new DSLs (see use case 7), including BPEL. As a result BPEL, for example, shields developers from the threading issues while jPDL often requires explicit thread control (see use case 6). The choice between jPDL and BPEL is basically the same as choosing between higher and lower level languages - it is a tradeoff between flexibility and simplified development (although BPEL programming is not always that simple).
Finally, when it comes to Visual Programming (use case 5), BPEL and jBPM are very comparable, although usage of "named" activities (jBPM) rather then "named" services (BPEL) seems like a more user friendly approach.
Not everybody agrees Tom’s use cases are a good representation of BPM scenarios. According to William Vambepene, architect for the application and middleware management part of Oracle’s Enterprise Manager division:
Tom is right to write that "the term BPM is highly overloaded and used for many different things resulting in a lot of confusion". By adding a few more use cases that nobody, as far as I know, had previously attached to the BPM bandwagon, he is creating more, not less, confusion
While it is very much worth reading, the article is more about jBPM and its future, then about BPM in general.