Enterprises embarking on the business process management journey must ensure that they keep the gains that business processes provide by controlling the cost of their life cycle. Particularly, a process quality approach is essential to enable low-cost changes. This article should interest business architects, and IT managers and architects as it discusses an approach to controlling the development and maintenance efforts for business processes by limiting their complexity.
Business process management tools are intended to simplify the development of processes; however process flows, like other software components, can vary in quality and complexity. Some formal techniques, such as cyclomatic complexity, were introduced in the 1980’s to evaluate the test efforts related to software components by providing graph analysis of code. By using these complexity computation techniques, it is possible to evaluate the number of possible paths that are in the control logic, resulting in a quality and effort analysis. The U.S. National Institute of Standards and Technology (NIST) has created best practices defining maximum acceptable complexity of classical software components. When overly high complexity is detected, the processes must be fragmented into smaller independent elements that have their own life cycle. This article discusses the use of the process derivation tree technique to modularize processes by finding the boundaries of sub-processes that can be isolated by business services. This derivation tree technique was initially introduced by MIT Sloan School of Management to identify process differences, but is used here to help refactor the processes for better quality.
Introduction
Human or machine automation workflow languages and standards were introduced in the mid 90’s, with tools and standards such as Business Process Modeling Notation (BPMN), XML Process Definition Language (XPDL) and Business Process Execution Language (BPEL) introduced more recently, that looked at describing process graphs and their external touch points, which could be software components or human interactions. The focus has been on simplifying the tooling so that non-IT users could model and capture the dynamics of their business and, in subsequent phases, have the IT professionals transform these models into automated process components. However the evaluation of business process development and maintenance efforts and of their quality is still in its initial phases. Experience has shown that the cost of development, test and maintenance together with the impact of change can become unaffordable.
There is a need to control the process quality through complexity analysis, and to apply techniques that reduce that complexity so that process automation can still occur, but with the true business agility that processes are targeting.
Evaluating the complexity of business processes
A business process is a graph of human or machine activities connected by edges with some control nodes that provide decision support or flow logic. The business processes interact with other business processes or business services that are touch points to external graphs, as shown in Figure 1, which is the representation of a high-level order to bill process for telecommunication operators.
The complexity evaluation will compute all of the paths in the process graph and all of the external touch points, targeting a formal computation of the quality and effort.
Figure 1: Typical high-level process graph (Click to enlarge)
In the example graph there are 29 edges, 26 nodes, and 20 external connections to other services or processes.
Applying Cyclomatic Complexity to business processes
The cyclomatic complexity1 is an attempt to evaluate the number of paths in the process that will all require a test validation, and all external connections to other components. It was introduced by Thomas J. McCabe in 1976. This formula was initially targeting coding languages but, as its purpose it only to evaluate the flow of a particular piece of software, it is straightforward to apply the formula to business processes. The complexity formula applied to business processes becomes:
Applying this formula to the process in Figure 1 gives a complexity of 43 resulting from the computation of 29-26+2*20.
The next question that arises is whether that complexity is manageable. Chapter 2.5 of the NIST document2 “Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric” states that “The original limit of 10 as proposed by McCabe has significant supporting evidence, but limits as high as 15 have been used successfully as well." What this text implies is that complexities higher than 15 have a cost of maintenance that is too high, because any change or update of the process will imply a test effort that is statistically too long for an enterprise to be agile.
From my experience, the cyclomatic complexity provides a rough idea of the testing duration in days and also in person days given that it is difficult to have multiple testers on one single process at the same time.
Other complexity methods such as Control Flow Complexity
Cyclomatic complexity is sometimes perceived as too simple, as it will not compute the number of loops in a flow or the efforts when decision nodes are based on complex formulas. So more complete “Control Flow Complexity” approaches to evaluate business process quality and maintenance efforts have been proposed, but at this point are mostly in the research stages3 4.
Selecting the appropriate complexity evaluation
When an enterprise starts evaluating the complexity of its business processes, it is important to agree on what the purpose of that evaluation should be. If the intention is to make processes more agile and also have an evaluation that is simple enough to be understood by a business analyst and non-mathematician, then cyclomatic complexity is enough.
It should be supported by tooling included with process modeling tools that makes any complexity evaluation automatic, so that the analysts do not have the feeling that they need to undergo an additional effort just to get that quality analysis. In addition, knowing that the quality of a process is not good is not sufficient to help one improve that quality. An approach must also be created to propose the appropriate refactoring to make the processes maintainable at an affordable cost.
Reducing complexity means having smaller process components or modules connected together by flexible services that isolate these process modules, but still connect them together to realize the implicit end-to-end process that will provide the same business support as the not easily maintainable initial process.
The next question that arises is how to provide an automatic way of finding flexibility points in business processes that can be realized as business services to reduce the overall complexity.
Finding flexibility points and modularizing processes
While a business approach is necessary to identify the flexibility or articulation points, such as a change of business owner in a process, there exists a technique that can be automated to propose modularization to the process designer. This proposed modularization will then need to be matched with a more business-oriented analysis that will then confirm that it makes business sense to isolate a particular part of the process in modules connected by services.
The technique that I propose is based on the process derivation trees that were introduced by the MIT Sloan School of Management Working Paper 4637-075. To create a process derivation tree, the first step is to identify the various constructs in a business process, as represented in Figure 2.
Figure 2: Highlighting the structures in a process graph with colored rectangles (Click to enlarge)
The next step is to create a tree from these constructs and compute the complexity of the resulting constructs. Each new construct needs to be associated with a “name” that describes what the business purpose of this construct is.
Figure 3 shows this decomposition, together with the new complexity of each module, and the complexity of each process module. The horizontal blue dotted lines represent potential flexibility points, which are hints for creating services that isolate portions of business processes. Once a process module (in every blue rectangle) is isolated behind a business service façade, it can easily be replaced without affecting the calling process.
Figure 3: Creating the process derivation tree and identifying flexibility points (Click to enlarge)
Once this tree is created, which is something that tools can automate, the last decisions that need to be made are to validate the proposed modularization by asking business questions. At which level of the tree do these modules have a single business owner? It makes sense to have the variations handled by a single business owner, who has full responsibility for the organization of the process parts they own. However, if there are no expected changes, in some tree decompositions it makes more sense to regroup them at a higher level in the tree. The same logic applies if a portion of the tree is delivered by a packaged application.
Conclusion
This article introduced the notion of process flow complexity, and how it can be used in conjunction with derivation trees to provide a formal recommendation for modularizing processes and identifying services that helps process architects provide such isolation and articulations. Process modeling tools should include such complexity measures and derivation tree widgets in the future.
By Marc Fiammante. Marc is a Distinguished Engineer in the Office of the Vice President and CTO for Europe, IBM Software Group. You can reach Marc at marc.fiammante@fr.ibm.com.
1 Cyclomatic Complexity (link resides outside of ibm.com)
2 National institute of Standards and Technology, Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, Chapter 2 (link resides outside of ibm.com)
3 Evaluating the Process Control-Flow Complexity Measure, Jorge Cardoso (link resides outside of ibm.com)
4 Control-flow Complexity Measurement of Processes and Weyuker’s Properties, Jorge Cardoso (PDF, 600KB) (link resides outside of ibm.com)
5 A Coordination-Theoretic Approach to Understanding Process Differences, Mark Klein, Steven Poltrock and Mark Handel (PDF, 0.99MB) (link resides outside of ibm.com)
