The Amazing Race Metaphor

Article
01/14/2009

by Vignesh Swaminathan

Summary: Business Process Management (BPM) is buzzing in everyone's ears today, and many enterprises realize the business potential of automating their business processes. As the buzz settles down and BPM approaches the plateau of productivity, there are some practical offshoots. One of them is a need for better management of high-level business processes that are composed from simple, reusable business processes. The answer, interestingly, is not entirely through graphical modeling but is the management of high-level business processes through externalized, process-definition rules. We'll look at the definition, benefits, and implementation of process definition rules.

The Amazing Enterprise BPM Race
High-Level Business Processes
Applying the Rules
Externalized Condition
The End Game
About the Author
Resources

CBS's The Amazing Race is a reality television show aired in the U.S. in which participants compete to race around the globe by going from city to city. To reach one city from another they take a common means of travel such as a car, train, or plane. The participating teams have to find a clue in each city to figure out the next city to where they have to travel. The clues control the choice of the next route map to follow; neither the participant nor the map itself is aware of or contains these clues. That is, the clues are externalized from the process of getting from one city to another.

Using this analogy, the entire process of moving around the globe (let's call it the globe process) is achieved by combining smaller processes of getting from one city to another (let's call them the city processes), thus creating the game show. The city processes that make up a particular globe process in turn are determined by the clues. The participants also decide, for instance, to take a flight if the city is not approachable by road or rail. These are simple internal rules that are applied within the city process. The clues on the other hand are entirely external to the city process and control the globe process.

An interesting twist to the game would be if the clues determine the next city process based on the characteristics of the players, the city they were previously in, and other relevant parameters. This process would lead to a richer possibility of cities that the participants can travel to next, every time they have traveled successfully to one city. Though this scenario becomes interesting for the participants, it is not a pretty picture anymore for the game show's creators. They now have a whole array of possible city processes that can be combined into the globe process. The city processes that are combined are dynamic and not predetermined (see Figure 1). Since only the choices are predetermined and not the final city process, the more parameters that go into making the clue, the higher the complexity of choices in their hand to create a globe process.

The Amazing Enterprise BPM Race

Now what does The Amazing Race have to do with Business Process Management (BPM) in the enterprise? Enterprises have a much similar approach to business processes in their domain. Each enterprise has a rich repository of business processes that are applicable within a particular subdomain in the enterprise. These subdomain business processes are modeled to achieve a particular task or workflow within the context of that domain. In most of the cases in practice, enterprises start to realize that the business processes applicable in the subdomain are reusable in a higher context. The enterprises then end up creating enterprise-wide business processes (high level) by reusing the subdomain business processes (low level).

The maturity of the approach to creating a high-level business process relates back to the analogy of The Amazing Race. Enterprises realize the efficiency of combining their city processes into making one of their globe processes (see Figure 2). Then they start to combine their city processes in more innovative ways by using parameter-based rules. At this point they also face a dilemma similar to the one faced by the game show's creators, which is the dilemma of managing the complexity created by the rich possibilities of using parameter-based rules to control their globe process.

A further dilemma with the game show analogy is that the game show's creators have a whole maze of if-then choices to visualize one single globe process that would make up this season's episode. Using this maze they would be able to maintain the globe process for the current season.

Imagine a situation where because of certain unforeseeable circumstances such as natural calamities, an outbreak of war, terrorism, or something that is just outside of their control, the game's participants are unable to use a particular city process. In this case they would have to go back and alter the globe process to ensure that the problematic city process is removed from the globe process or has an alternative. As the globe process is now controlled by various parameters and rules based on these parameters, the entire globe process model has to be scanned manually to ensure that there is no possibility of reaching the problematic city process. In addition, the show is already on for the season, and the globe process is in execution. This example requires that even though the show is on, none of the participating teams end up in the midst of a war-torn city!

The dilemma is even more critical in the enterprise. The enterprise globe process (high level) will be influenced by changes in the enterprise city process (low level). The reasons for change can be similarly unforeseen as in the game show. The business might require that the enterprise is able to change dynamically in a high-level process to meet new and unforeseen business demands (see Figure 3). The enterprise globe process would also be in execution, and a change would be mandatory even when in execution so that the enterprise does not end up in the midst of its equivalent of a war-torn city. Unlike the game show, parts of the enterprise cannot be just cancelled. The show must go on!

High-Level Business Processes

As mentioned previously, the globe processes are high-level processes, and as such are managed entirely by nontechnical users. The game show's creators are more skilled in managing a show than they are experts in broadcast technology. This scenario is true also for the enterprise where the high-level business process is managed by executive managers who are familiar with the task of running their business and not experts in creating computer models of their business. Thus, the first and foremost aspect of managing a high-level business process is the need to abstract the user from technicalities.

The second need is to ensure that a globe process in execution can be altered within given boundaries. This flexibility is an important requirement for high-level business processes that are subject to more impact from business change than low-level processes.

Figure 1. Going global (Click on the picture for a larger image)

The third need is to provide a straightforward, easy, and simple interface for the user to manage the globe process. This management interface should provide for creating and maintaining a high-level business process. The same interface should allow the user to conveniently alter the globe processes in execution, and it should allow easy search of parameter-based rules that control the high-level business process. This search would allow the user to quickly locate the rules that they want to alter. The interface should be lightweight in nature to allow users to quickly update the high-level business process without effort.

The final requirement is to understand that the globe process is determined by combining a rich repository of city processes based on parameter-based rules. The number of parameters is in practice not limited, but it can exceed 30 parameters in many real-time enterprise scenarios. We first encountered this practical problem in one of our customer assignments. The customer, a large European bank based in The Netherlands, faced this issue in their retail banking arm. They had an average of 5 defined parameters to handle each step in a loan-application process. Each parameter had anywhere from 3 to 100 possible values that led to a complex business process, deemed unmanageable through conventional means.

Figure 2. The enterprise (Click on the picture for a larger image)

To show this complexity in action, assume that The Amazing Race always has five competing teams for each new race (globe process). Each team in any stage of the game would have traveled through a list of cities before they travel to the next city. For this example there are a total of ten cities through which the teams can race, which is ten different possibilities of the city in which the team is currently in. They would also have reached the current city using one of three primary modes of transport such as road, rail, or air.

Using this analogy, the job of the game show's creators would be to make up the globe process using these three parameters of team number, previous city list, and transport mode. For a unique combination of these three parameters a particular city process is to be combined in the globe process. The globe process should ensure that the participants do not use the same mode of transport more than once continuously, and also ensure that the participants end up finally in the city where they started to complete the race.

Applying the Rules

The game show's creators should also use the team number to determine certain special conditions randomly to ensure that the game show has richer content by making sure that the teams travel through different cities in different orders and in different modes of transport. Thus, the next city process to be used in the globe process at any stage is to be determined by the team involved, the current city, and the mode of transport last used.

This combination translates to roughly 150 different flow paths that can determine the next city process to be used in the globe process. The number of flow paths possible is determined this way: 5 teams × 10 possible current cities × 3 possible modes of transport just used = 150 unique choices to determine the next city process (see Figure 4). For example, team number three could have arrived in New York by rail and then given the next process as "to London by air."

This complexity translates into enterprises as well. Both the finance and insurance domains provide several scenarios that necessitate high-level business processes controlled by parameter-based rules. For example, an insurance claim to be investigated by a global insurance firm can necessitate an insurance claim, high-level business process that chooses a country-specific, claim-investigation process based on other additional parameters. Imagine that the insurance claim is categorized into 5 possible age groups from 10 different countries of operation and belongs to 3 groups defined by claim-amount ranges: 5 possible age groups × 10 possible countries of operation × 3 possible claim-amount ranges = 150 unique choices to determine which claim investigation process is to be used.

For example, if age group is B (30–45), country is India, and claim-amount range is greater than $150,000, then use the "High-Value C Group India claim investigation process."

If we go back to the previous financial example involving the Netherlands-based bank, the math works out this way: 5 possible customer interaction channels × 3 possible user types × 4 possible customer segments × 100 possible product offerings × 7 possible high-level process steps = 42,000 possible implementations in the process repository.

One additional item to consider: In The Amazing Race metaphor, the number of city processes available reduces at each iteration of the travel-to-city process step. However, in real-time enterprises, it is not just one process step that has a wide array of possible process implementations, but each and every step of the high-level business process can have multiple possible implementations. The metaphor has been deliberately simplified, and the increase in complexity for every new step that is dependent on parameter-based rules is shown in Figure 5.

How can we manage these scenarios? Do we still want to use graphical models to manage the high-level business process?

The first and immediate notion that strikes the user when we take a globe process and city processes example is to create the globe process with the city processes as subprocesses that are used inside of the globe process. This notion is not surprising as the use of subprocesses is the most common way to combine simple processes into more complex processes. Using subprocesses is a good choice when we are trying to break down a business process into submodules for better reuse. However, they are not applicable to high-level business processes that are controlled by parameter-based rules because when subprocesses are used the decisions that control the flow of the high-level business processes are embedded and internal to the process.

This characteristic violates the need for flexibility as stated in the requirements of high-level business processes. It also does not solve the problem of managing decisions as the user is left with an inefficient choice of modeling 150 different flow paths into the high-level business process and loading the resulting huge graphical model every time there needs to be a change in the globe process. In addition, this approach is not in line with the service-oriented tenets of loose-coupling as processes would eventually be exposed as services.

Figure 3 .The complexity (Click on the picture for a larger image)

Any optimization effort to break down the decision points further into subprocesses would also be futile because the trade-off is visibility of the high-level business process, and the user now has the additional problem of having to drill down to make alterations. Even if the user goes through with the alterations, this approach does not guarantee that alterations can be made on a globe process in execution. Hence, using subprocesses in all aspects does not solve the problem of high-level BPM.

Externalized Condition

One of the primary disadvantages of the subprocess solution was that the decisions were embedded and static inside the high-level business process. Some smart BPM tools provide a solution that addresses this specific issue. They provide capabilities to model business processes that take up the decision rule from a lookup repository or refer to an incoming message during the execution for the decision rule.

Figure 4. Determining the number of flow paths (Click on the picture for a larger image)

The approach here is to have a database store of parameter-based business rules that control the flow of the high-level business process (see Figure 6). In the graphical model of the high-level business process a simple call is made to a service over the rule store to evaluate the data in the business process and determine the next logical step. This approach greatly reduces the complexity of the high-level business process in that now the graphical model does not have the flow paths but just the linear stepping of the high-level business process from one stage to another. The solution, however, is still not good enough to solve the primary problem of manageability.

The disadvantages of this solution are that the rule store abstracts the entire logic of the high-level business process, making the model less transparent to the business users. The rule store and the interaction possibilities over the data are nonstandard and do not guarantee that all technical details of conditions would be abstracted from the user. It fails to leverage existing standard tools and methods that are available. Thus, the question of a better solution remains.

Figure 5. One more step (Click on the picture for a larger image)

Let's take a look at another solution. Process definition rules (PDR) are managed externally from the graphical model, similar to the externalized-condition approach up until the point of keeping the rules outside the high-level business process. The difference is in how these external rules are managed and how the high-level business process is controlled. The PDR matrix solution promotes the rule engine as the control layer and shifts the process engine to an execution layer, making the high-level business process flow more visible in the rules rather than in a graphical model.

With this solution there is still a lack of a standard approach to model and maintain the PDR repository. The critical point here is that the technical abstractions provided by a graphical, business-process, modeling tool should be intact in the tool to model and maintain the PDR repository. Since the PDR repository is a rule repository, we need to look at the available standard tools in the business rule world. Prominent among them that stand out as a good fit for providing a simple, straightforward, and lightweight tool is the decision table.

Figure 6. An externalized condition (Click on the picture for a larger image)

The decision table is a standard tool to model and manage rule repositories and is an excellent abstraction to business users that is simple to use because it is text based. Text-based decision tables are also good candidates for searching the rule repository and quickly allowing the user to alter relevant process definition rules.

Using this tool we can create a solution that has a graphical, high-level business process that is simplified by externalizing the rules and providing a service layer on top of the PDR rule repository (see Figure7). The PDR rule repository is then modeled and managed through decision tables. We call this solution a PDR matrix, and the concept of globe process and city process can be shown as two tiers. The first tier is the high-level, enterprise-wide business process, and the second tier is a reused, low-level business process.

The End Game

We have worked through a very practical problem here with BPM in enterprises: the complexity in defining and managing high-level business processes. High-level business processes are created by combining several low-level business processes, thereby forming two tiers of BPM. The high-level business processes are marked by the need for parameter-based rules to dynamically choose a low-level business process.

Figure 7. A PDR matrix solution (Click on the picture for a larger image)

These parameter-based rules, when employed to manage a high-level business process, increase the complexity of the graphical model manifold with each new value for each parameter. This increase in complexity makes the graphical model of a high-level business process unmanageable and impractical. The solution to this problem is to use a rule-based approach to define and manage high-level business processes.

You can define and manage such an approach using a decision table-based PDR matrix. Decision tables are lightweight, nongraphical, business user-friendly tools to create and manage rules. The PDR matrix abstracts the complexity of managing a graphical, high-level business process model. Therefore, employ the PDR matrix to manage two-tier BPM and put the business user back in the driving seat in your enterprise.

About the Author

Vignesh Swaminathan is a product manager at Cordys R&D India (www.cordys.com), which provides a state-of-the-art application platform suite going beyond basic EAI and BPM to solve many practical aspects of the enterprise. He has been working with business-process orchestration, business rules, data transformation, and other related technologies for the past five years, and he specializes in data, process, and human integration. Contact Vignesh at vswamina@cordys.com and vigneshs@hotmail.com.

Resources

CBS.com

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.