Simplifying Design of Complex Workflows

by Andrew Needleman

Summary: Several factors go into good workflow design. In simplifying the process it's important to focus on diagramming the necessary steps of a particular key transaction such as an e-commerce order or a medical consultation. In this discussion we'll look at representing workflow in a new type of diagram, called a "dots-and-lines process" diagram. We'll begin by diagramming the possible steps that can be taken at each point of the workflow, and then we'll indicate where that diagram takes us in this workflow process. We'll also ensure that we don't miss any of the potential steps or status points along the way.

Contents

Follow the Rules
Actions and Statuses for Workflows
Roles in the Purchasing Process
About the Author

Good workflow design requires business-process analysis, business-process redesign, usability analysis, and software design. These daunting, necessary skills make workflow a challenge for the most experienced software architects. How do you break down the problem into its smallest parts to get you started in the right direction? We'll look at how to simplify the design process of complex systems with multiple user types and hundreds of potential statuses. In simplifying the process you can think about the workflow solution rather than the workflow design process.

Each software project has a central process that is the main reason why the system exists or is being built. For example, the main goal of an e-commerce site is to make it easy for people to buy products. This main process is the one that needs the most attention during its design and implementation. We'll show you the dots-and-lines approach to modeling that will help you to communicate about complex processes with your business experts to determine available actions and statuses as you are creating the workflow.

Let's begin with an overview of the dots-and-lines approach to creating workflow diagrams. In the dots-and-lines approach each dot represents a particular status in the process, and each line corresponds to an action that can be taken from that dot. Dots and lines are labeled, and a key is made as the workflow is developed. Dots are labeled with letters, starting with A, and lines are labeled with numbers, starting with 1. That way dots and lines won't get mixed up.

The primary goals behind the dots-and-lines approach are to create a simple visualization tool on paper that can be used with business users, eliminate the perfectionism caused by diagramming on a computer, make the process as lightweight as possible to allow concentration on the tough task of designing the workflow, and separate the changes in description of actions and statuses from changes in the process flow (that is, similar to the idea of a lookup table).

Follow the Rules

In addition to these goals, there are five rules that must apply to a diagram using this approach. Let's look at the details of each rule.

The diagram always goes in one direction. One of the main ideas of the dots-and-lines approach is that the diagram always reads forward like a timeline. You may end up at a previous status, but your diagram doesn't have lines going in all four directions like a maze.

Statuses can be discovered as you are building the diagram. In a simple workflow you know all of the potential statuses before you start diagramming. However, in a more complex workflow, you may need to discover the potential statuses by building your diagram. Determine what actions you can take at each point in the process, and see where that takes you. As you discover the statuses, you can decide how to label each status for your use. Then, after the diagram is complete you can decide how to present the statuses to each user type and whether to combine them into more easily understood statuses.

The labels of statuses and actions are kept off the diagram. When you have descriptions of each action and status, it makes the diagram cluttered and hard to understand. By putting the labels for the statuses and actions in a key, you make it easier to see a larger process flow in a smaller space, which is almost like normalizing your diagram. You can change the labels of the points without having to change the diagram. This makes it easier to view and diagram complex processes.

Layout is simple and flexible, allowing everyone to focus on the content. Layout is a large problem in traditional process flows. A lot of effort goes into connecting and fitting in the different items within the diagram. If you leave out a potential action in a process flow, then the entire diagram might have to be rearranged. In the dots-and-lines approach you just have to fit in a line for the action and a dot for the status of the result. If you need to change an action or status, you can change its number or letter, respectively. If you want to change the name of a status or an action, you can just change the key rather than the diagram. The simplicity of adding, changing, and viewing dots and lines to your diagram makes it easy to stay focused on the process itself.

Statuses can be "torn off" the main diagram. Since you are always going forward with your diagram, you can tear off sections of the diagram without worrying about how they connect to previous statuses in the workflow. For example, A connects to B, and we want to tear off B onto its own diagram because it has too many children to fit on the existing diagram. We don't have to worry if B has an action that goes to C and C has an action that sends its status back to A. By labeling the status with A, they are connected, rather than having to get a line back to the original A status. Our diagram only moves forward, not backward, so we don't have to connect back with the original A dot. This rule allows for great flexibility when you are running out of room on a diagram.

Actions and Statuses for Workflows

Now that we've covered some of the advantages of the dots-and-lines approach, let's look at how you can determine if an action or status should be on your diagram. Statuses and actions have to be included if they are required to complete the process that is being studied. For example, even though logging on or registering on an e-commerce system does not change the status of an order object, it is required to complete a purchase. Therefore, it should be included as an action on the system, and the statuses that these actions create should be studied and differentiated if we are examining the ordering process.

Statuses and actions do not have to be included if they are not required to complete the process that is being studied and do not change the steps needed to complete the process that is being modeled. In other words, an action that sets you back a step in the process is something that should be modeled. On the other hand, an action that isn't related to your process does not have to be modeled.

Of course, there is definitely a lot of room for interpretation as to what should be placed on a process diagram; because turning on a computer is required to perform any computer process, it is probably a bit silly to include this action as part of a process diagram. Now we'll use an example to try to clear up what should and what should not be on your dots-and-lines diagram.

Let's look at a familiar example of a workflow to examine with this process—the purchase of item(s) through an e-commerce Web site. We're going to examine the necessary steps to take for purchasing a product.

When we're beginning to design a purchasing workflow, we'll ignore steps that don't change the status of the purchasing transaction. For example, the process of browsing for the product does not change the status of the order process in any way. It really doesn't matter to us how the user gets around the site unless they do one of three things that change their current status. These three steps that can move the status of purchasing the product forward are adding a product to the shopping cart, registering for the site, and logging on to the site.

For example, pretend you go to the "books" section and click back to the home page. Has this action changed your status in any way in terms of purchasing a product? No. Pretend you search the site for ".NET books," and you receive a list of them. Then you click back to the home page. You still haven't moved forward in the purchasing process.

Even if you pretend that you have an engine that matches product suggestions to your browsing history, it still doesn't move the purchasing process forward until you add a product to your shopping cart. It is very important to keep this step out of your diagram because it will unnecessarily complicate it. We can combine the browsing and then adding a product to the shopping cart into one action in the purchasing-process diagram, called "find and add product." If we wanted to diagram the process of finding a product, then we would be interested in how the user selected the products to view and add them to his or her shopping cart. For now, we'll focus on diagramming the purchasing process.

Roles in the Purchasing Process

First, we'll start with someone who has just gone to our e-commerce site's home page. We look to see what comes next in our process. The three possibilities in terms of behavior that moves the purchasing process forward are adding a product to the shopping cart, registering a user, and logging on to the site. You can view the dots-and-lines diagram for this entire process in Figure 1 and its key in Table 1.

Figure 1. A dots-and-lines diagram for an e-commerce, product-order process (see Table 1 for the key)

It is important to understand the impact multiple roles on the site has on our statuses and viewable permissions. For example, assume that our e-commerce site has roles for both shoppers and an administrator. The shoppers are the people who purchase the product, while the administrator makes sure that they get the product. Our dots-and-lines diagram helps us determine what to show the administrator by providing a comprehensive list of statuses that an order is in during the buying process. We can then take these statuses and run down the list to find out which orders should be seen by the administrator and which should not. For example, one potential business rule may be that the administrator can see order transactions that are abandoned at the billing prompt, to allow the administrator to follow up with those customers.

For more complex sites with hundreds of potential statuses for each transaction going through the site, we'll need to roll up multiple statuses into single-status descriptions. For example, statuses E–G can be grouped as an "incomplete" status for the administrator. It is unlikely the administrator will need to know more than that, except for aggregate statistics that would be provided in a report rather than the daily work screen. Plus, if the administrator goes into one of those orders, he or she can provide the status details at that point.

One of the easiest ways to roll up status for each user is to use the "who has the ball?" method. In other words, which user is supposed to do something to advance the workflow? The user(s) that fit this description should see this item grouped with other items that are waiting for their action. Then you can group the other open items in another category and finally the completed/canceled items in a third category.

One final recommendation regarding the dots-and-lines approach is to use a very large piece of paper and a pen to create the diagrams. Another large piece of paper should have the names of the statuses on it, and a final one should have the names of the actions. Using large, separate sheets of paper in this manner allows everyone to get a good bird's-eye view of the entire process rather than having it broken up on multiple screens.

Using paper also focuses everyone on the problem at hand, instead of making it look good. If you are using paper, there is no easy way to put a gradient on each dot or shuffle the items around to fit better. You should find the dots-and-lines approach as helpful as I have in discovering all of the potential actions and statuses with your business experts.

About the Author

Andrew Needleman is the managing partner of Claricode, developers of custom solutions exclusively for the health care industry. He has written articles focusing on software development for many publications in the IT and health care industries. His workflow design experience includes architecting an application with hundreds of distinct states, multiple actions at each state, and nine distinct user types. This application was recognized as an Intel Solution Blueprint for best practices in health care with Microsoft technologies. Contact Andrew at andrew@claricode.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.

© Microsoft Corporation. All rights reserved.