BPMN Anti-Patterns

For several years BPM has been hyped as a key technology to bring great increases in agility and productivity to IT. It promises to help bridge the gap between business users and developers by using a shared, graphical notation accessible to business users yet rich enough to be made executable by developers. In the first paragraph of the BPMN standard it says: “The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.”
Unfortunately, it often fails to live up to this goal. We believe that the source of the problem is not so much in the definition of the standard as in how it is used in practice. A typical BPM project lifecycle will start with Business Analysts, working in conjunction with end users and subject matter experts creating initial BPMN processes. Typically they will be limited to the subset of elements described as the descriptive conformance level. When the business users think that they understand it and the Business Analysts think they have captured sufficient detail, it is handed off to developers to make executable. After completion, the business again reviews the processes to confirm that they have correctly implemented the desired behavior. At this point, the problems caused by the inherent mismatch between the skills of the business users and the developers become apparent. Developers naturally feel comfortable with the full scope of the BPMN notation and produce processes which the business users struggle to understand. Faced with unfamiliar notations, they make assumptions about how the process will behave. To further complicate things, BPMN allows multiple ways to model some of the most common constructs, often including “shortcuts” which hide important details. The result is often the same as with traditional development where failed communication between business and IT causes a project to fail.
With good modeling practices, this can be significantly reduced. By using the notation consistently and by always choosing clarity where there is a choice of modeling techniques, it is possible to improve the communication between business and IT and improve project success rates. One key to this is avoiding BPMN anti-patterns.
Most of the discussion of poor modeling practice has centered on preventing deadlocks or other incorrect modeling problems which will prevent a process from completing. While these are obviously important, they are not our focus. The anti-patterns described on this site are all legal BPMN constructs, which in most cases, will execute correctly. Still we avoid them because there is a clearer notation available which has the same behavior and expresses it better. In a few cases, we have observed implementation errors by several of the BPMN tool vendors which create vendor dependent differences in behavior.
We intend this to be a living site and welcome your feedback. We will continue to update the anti-patterns as we observe new usage patterns.

Sponsored by  BPMPros LLC