Documenting processes is something most business analysts have to do. The goal of documenting the process is to communicate requirements. By establishing a shared understanding of the process, you can establish the context for the requirements. Easy processes are easy to draw and understand. When documenting a more complex process, you need to provide the same clarity and consistency. In this article we show how to document asynchronous process steps to maximize the clarity of the documentation.
Speak in Your Reader’s Language
The diagrams you choose to use represent a graphical language for communication. It is really no different than choosing a language in which to write your textual requirements. You need to choose a graphical language that the consumers of your document understand.
You can use BPMN (business process modeling notation) to document your processes, and be quite precise in your description of the process. However, if the team you are communicating with does not know BPMN, it may not be the most effective way to communicate. You are faced with a trade-off. You have to either use a language (process flow charts) that is easily understood but hard to extend, or use a language that is precise in interpretation – but only to people who know the language.
Here’s a solution that uses diagrams that are better known than BPMN, leveraging process flow charts and UML sequence diagrams.
Asynchronous Process Definition
An synchronous process is one where two objects or systems talk to each other. The first system sends a message to the second system and waits for a response. An asynchronous process is one where two objects or systems talk to each other – but the first system does not wait for a response from the second.
Imagine making a bank deposit. If you go to the bank, hand your money to the cashier, and wait for a deposit slip, you have just participated in a synchronous process. You did something, and waited for the cashier before doing something else.
Now imagine driving through a toll booth. You drive up to the toll booth, roll down your window, and throw your money into the collection basket. You wait for the machine to count the money, the light turns green, and you drive on. This is also a synchronous process.
Now imagine that you are in a hurry. You roll down your window as you approach the toll booth. You slow down, and as you drive by, you throw the money into the collection basket, and accelerate. You don’t wait for the light to turn green – you trust that you had put enough money in the basket and you move on. The machine still counts the money, and the light still turns green – but you didn’t wait for it. You continued to do what you were doing – driving in a hurry. You just participated in an asynchronous process.
Drawing an Asynchronous Process
Consider a simple asynchronous process – ordering a hamburger at Wendy’s.
Wendy’s has an interesting process for serving “made to order” burgers quickly. They cook a small number of hamburgers in advance, and keep them warm for a short period of time. If someone orders a burger, they take one of the already cooked burgers, and assemble it with the custom toppings. They also put another raw burger on the grill to replace the one they just sold. The challenge for the grill cook at Wendy’s is to have enough burgers ready that no one has to wait – while not having so many burgers precooked that any of them dry out before you order.
The labels in the boxes above are generic, but it could be used to describe ordering a burger at Wendy’s. The box “calling process” represents you ordering a burger. The cashier processes the request, and then the flow splits into two parallel paths. The grill cook immediately prepares your hamburger, and simultaneously starts cooking a new hamburger to replace the one he just used.
After your burger is prepared, the process returns to you – you get your burger and go eat. You don’t wait for the new hamburger to finish cooking.
A process diagram doesn’t normally do a very good job of communicating that a process is asynchronous. We’ve had good success in using a modified box – with a small clock in the lower right corner – to indicate that a process is asynchronous. You could infer that the “delayed activity” is asynchronous because the flow moves directly from the “immediate response” to the “return” symbol. But in a good diagram, you don’t have to infer.
Sometimes, it helps to create an alternate view of the same process. This additional view can make it easier for the consumers of your diagram to understand the process.
An Asynchronous Sequence Diagram
Another way to diagram processes is with UML sequence diagrams. Scott Ambler has an excellent article explaining how to read a sequence diagram. The same burger ordering process could be drawn with the following sequence diagram.
The diagram above uses the same generic labels again, but still applies to our example of ordering a hamburger at Wendy’s. Inside the “par” bounding box, you get the immediate response (preparing your burger), and in parallel, the delayed activity (cooking a replacement hamburger). Note that, in the diagram, you don’t have to wait for the response from the delayed process. You get to eat your burger before the new one has completed cooking.
Summary
Asynchronous processes don’t come up often when learning about diagramming techniques. But you find them all the time in the real world. One of the easiest ways to speed up a process is to find steps that take a long time, and figure out how to do them asynchronously. You don’t wait for paperwork to be processed when signing up for an insurance policy – the coverage is effective immediately. You don’t wait for a loan application to be processed before driving off in your new car. Once the loan is approved, you get the keys. Many different software and manufacturing processes take advantage of queueing (like the Wendy’s example) to allow for faster “real time responses” to requests.
Being able to draw and discuss asynchronous processes is a good skill to have in your repertoire when documenting requirements in the real world.
