Process design , whether practiced by a business analyst or a developer, requires the same high standards of code quality as programming. The following guidelines can help boost quality and maintainability:
For readability and comprehensibility, ensure that a process diagram fits on both a graphical editor screen (with no scrolling or zooming out required) and a letter-sized printed page. If it does not fit, break it into smaller subprocesses. This rule is reminiscent of the style convention in programming to keep source files to fewer than 1,000 lines, with each line restricted to 80 or fewer characters. Many development shops conduct code reviews to check for style compliance; this sense of discipline also belongs in process modeling.
Keep the process flow coarse-grained. Process design is "programming in the large"; the boxes in a process diagram are meant to represent the major steps of the process, not detailed processing instructions (e.g., parsing messages, calculating dates, and evaluating XOR conditions). Process diagrams drawn on a whiteboard in the early stages of a BPM project are always kept simple, whereas the final production cut of the process is pregnant with detail. The key insight is to factor out fine-grained processing to subprocesses or to external components (e.g., Java code, EJBs, or DLLs) called by the process.