|
In recent years, use of BPM systems as a platform for custom business application development has accelerated. Many organizations have achieved significant benefits in efficiency, consistency and transparency of their business operations. Unfortunately, other organizations have achieved less than expected. In some respects this is not surprising. Developing applications on a BPM platform is a new development paradigm, and in some aspects it requires a new mindset to ensure a successful outcome. A key element is re-thinking the approach to initial process design. The process model is a directly executable manifestation of the business activity. Developers trained in traditional programming methodologies need to make a significant adjustment in their thought processes to fully take advantage of the new tools. Because BPM systems model the application at a very high level of abstraction, it is easy to get something working, but it is much more difficult to design processes which support the full range and flexibility of most actual business needs. Experienced process designers, just as experts in any development methodology, instinctively understand how to approach new processes. They have many “rules of thumb” and other empirical guidelines learned from experience which help them avoid problems. If these rules of good process design could be codified and widely disseminated, more organizations could more quickly reap the benefits of process automation.
BPM systems have sound mathematical foundations, typically Petri nets, but typical Business Process Designers cannot be expected to know these formalisms. Some BPM Suite vendors will tell you that the above notion is nonsense. Their tool implements BPMN or some other standard, and therefore all process designs will automatically be good. That type of statement is the true nonsense. First, BPMN is an incomplete and ambiguous standard that intentionally does not address many aspects of process execution. Second, many vendors have taken liberties with the standard, omitting some parts and extending their product in nonstandard ways. Many older products pre-date the standards and each uses its own unique model. Perhaps most important of all, any good BPM tool, like any modern development platform, is extremely general and flexible. In order to support the widest possible market segment vendors include features which are only occasionally appropriate, or inappropriate in certain combinations. So claims of standards adherence should be taken with a grain of salt at a minimum, and in the larger sense, must be understood to not be the sole answer to the problem anyway. Since the quality of the process model implementation is a such key determinant project success, the starting premise must be that some process model implementations are in some qualitative way “better” than others. That premise alone, of course, doesn’t help; you can’t improve what you can’t measure. Unless we can quantify that quality gap, we are left in the situation of Supreme Court Justice Potter Stewart talking about pornography: “I can’t define it, but I know it when I see it.” BPM vendors can, and must, do better than that. There are a number of characteristics which can be automatically measured, in a fashion similar to how many source code analysis tools can detect actual or potential coding errors, and also identify questionable constructs. Most BPM vendors provide validation tools that ensure a minimal level of correctness, in the sense that a process will execute, but it is increasingly important to get beyond that and perform static analysis on process models and identify potential problems. Qualified vendor services teams should be required to provide guidelines for process designers (remembering that absolute rules do not exist, so the designer must use his or her judgment as to whether to follow the advice). The goal is to accelerate the learning process for new process modelers by identifying potential problems in models. Most current research is focused on overall process structure. This can generally be divided into two categories: model correctness and understandability. The definition of model correctness is inseparable from a particular vendor’s implementation, and will not be further discussed in this article. BPM processes change more often than most software, which places an extra premium on understanding and maintainability. In general, smaller and simpler processes will be easier to understand. We have investigated several measures of size and complexity. In addition to these overall process metrics, we believe that there are many local details which affect the overall understandability and quality of a process. Most of these are subjective and will not apply in all cases, but tools to automatically identify these provide valuable assistance during design and implementation reviews. The remainder of this article will describe key attributes and metrics that we have identified and implemented via experiment. This provides a “checklist” for increasing the quality of your process models, and consequently, the success of your BPM project. Note that this list is broadly based on the BPMN standard, but – per my standards comment above – be aware that they may need to be somewhat tailored to any specific BPM tool in question.
Overall Process Metrics
1. Process Size: Just as with conventional programming, a process should do one thing and do it well. We find that as process size increases, it quickly exceeds the visualization capabilities of current tools. When you can no longer see an entire process on one screen, you have lost one of the key advantages of BPM. We generally consider 40-50 nodes to be an upper limit for good process models. If a model is larger than this, it is a candidate for re-factoring into sub-processes.
2. Process Flow Complexity: In his article, “How to Measure the Control-flow Complexity of Web Processes and Workflows,” in the Workflow Handbook 2005, Jorge Cardoso introduced a metric for control flow complexity of process models. Basically, this is a measure of the number of independent flow paths through a process. More independent paths increase the complexity of testing, and even comprehending, the full process.
3. Process Density: In the article “Testing Density as a Complexity Metric for EPCs” Jan Mendling proposes a measure of process density. This is the ratio of actual connections between nodes in a process to the maximum possible number of connections. One advantage of this over some other metrics is that it is independent of process size. It is a normalized value, always between 0 and 1.0. In calculation of this metric, we assume that good modeling practices are followed and that all branching occurs through gateways. Local Modeling Practices 1. Unreachable nodes: This is an important attribute and most BPM tools on the market will detect unreachable nodes as part of the validation process.
2. Deadlocks: The AND join, and certain configurations of the Complex Gateway, can create deadlocks, where the continuation condition can never be satisfied. If one or more of the paths into an AND join has conditional execution, then it cannot be guaranteed that the AND join can always be satisfied. The simplest way to ensure this is for all paths into an AND join to flow unconditionally from a single AND split. Several conditions of this can be detected, but others are data dependent and cannot be resolved with static analysis. As a conservative test, any AND join for which all incoming paths do not flow from a single AND split should be flagged for further review. An obvious deadlock is illustrated below: 
3. Multiple End Nodes: Many tools allow multiple End Nodes, and in some cases this can improve the clarity of the diagram. In all cases only one can have a terminate event. Processes with multiple End nodes should be identified for further examination.
4. No End Node: BPMN allows models with no End node. If the tool you are using does not automatically detect them, they will need to be flagged for review.
5. Multiple Start Nodes: BPMN allows multiple start nodes. If a process requires independent Start events, it is probably multiple processes. There are BPM tools that do not allow this, but if using a tool which does, it will, as above, manual flagging for review.
6. No Start Node: BPMN allow processes with no Start Node. That means any node with no incoming path is an implicit Start Node, but the Start and End of a process should be explicit and unique. Make sure your BPM tool supports this.
7. Nodes with no incoming paths: The BPMN spec allows nodes with no incoming paths only if there is no Start node. Some tools allow nodes with no incoming path in all cases. As previously stated, process Start and End should be clear, meaning nodes with no incoming paths need to be identified.
8. Nodes with no outgoing path: As above, nodes with no outgoing path have implicit flow, and need to be reviewed.
9. OR split: The OR split can lead to confusing process flows. In most business cases, the XOR is the correct control mechanism.
10. XOR as both split and join. It is possible to use the XOR gateway as either a split or as a join. Combining these behaviors in a single gateway can produce unexpected behavior. XOR gateways with 2 or more incoming and outgoing paths will be identified.
11. AND as both split and join. Similarly, it is possible to use a single AND gateway as botha a split and join. While not as confusing as a combined XOR, it is recommended to always use a gateway as only a split or join, never both.
12. Implicit splits and joins: All flow branching should be explicit. Most tools allow implicit splits or joins by having multiple incoming or outgoing paths from any node. Multiple incoming paths behave as an implicit OR join, multiple outgoing paths behave as an implicit AND split. The diagram below illustrates implicit splits and joins, followed by the preferred explicit control.  13. Attended Nodes not in Lanes: The use of lanes greatly improves the readability and hence maintainability of process models. While it is acceptable for unattended nodes to be placed in a single “System” lane, attended nodes should all be in lanes which reflect their actual assignment. Any attended nodes that are not in lanes need to be flagged.
14. Attended Nodes without Escalation: Escalation prevents processes getting stalled due to a single inattentive user. All attended nodes should have escalations, and your BPM tool of choice should help enforce that.
15. Duplicate Node Names: All objects should have unique names. Duplicate node names can complicate interpretation of logs and other monitoring data. Identify and remove nodes with duplicate names. A partial output is shown below: Process analysis Quality Analysis
8/16/2008 Process Model NameApprovalDemo
Process Model Version 6.0 Process Metrics ApprovalDemo
The flow complexity = 7
The total number of nodes in the model = 11
The process model density = 0.3 Activity Analysis Results ManagerApproval
No problems found
DirectorApproval
Attended Activity does not have any Escalations
VPApproval
Activity has 2 incoming paths.
UpdateSystems
No problems found Summary
Implementing a static process model analyzer capable of enforcing the rules as indicated above will greatly increase the quality of your initial process models, their implementation, and the overall success of your BPM projects. Our experience in the field is that results following the quidelines above generally match the qualitative judgments of experienced process designers. This checklist, combined with a comprehensive BPM toolset, can be a highly valuable tool for helping new process designers accelerate their progression to being process experts. About the Author
Glenn Smith is a Principal Consultant with Appian. He has more than 20 years of software development experience including more than 10 years implementing enterprise BPM solutions. He can be contacted at glenn.smith@appian.com.
|
Subscribe to this comment's feed
