Blog

The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition: A task (for business process diagrams) or a process (for data flow diagrams) is atomic if every input relates to every output in the Decomposition Matrix. In other words, all cells in the matrix are checked. Each decomposition that is displayed on Results page at this site indicates whether any further decomposition is possible. That information appears at the bottom of the Results page. The Results page also sets up a sub-matrix for further decomposition should you want to see the next level of decomposition. One of the earlier Blog postings has an example.

I’m now going to modify and expand the Decomposition Matrix to more fully reflect the story in Web Services and Service-Oriented Architectures, The Savvy Manager’s Guide.

First, the input of travel dates and locations is changed to travel dates and customers. In the story, C. R. chooses the dates and customers, not locations. Locations for customers come from the external CRM service used by C. R.’s company. Inputs and outputs for the CRM service are added.

Second, a traveler identification input is added. This identification is used to obtain the traveler’s profile.

Third, requests to customers’ calendaring services for meeting availability are added. These follow the same pattern as airline, car, and hotel services. There is a request for meeting availability that is followed by a meeting reservation request. The meeting availability requests are sent once it is known that there are available flights, hotel rooms, and rental cars. Also, receipt of one or more meeting confirmations in meeting reservation responses is needed before making either a flight reservation or an air/car/hotel reservation. This is because such reservations may have restrictions in order to get the best rate.

Fourth, the output of GPS destinations is added for the rental car service. This appears after all of the reservations since all driving destinations are provided at the same time to the rental car service. Also, this raises the issue of granularity for the first time in this example. Because of the possible volume for a car rental service, that service might ask that GPS destinations be bundled in one service request. It is potentially more efficient to handle one larger request than many smaller requests. So, this example is set up to create single larger requests that provide GPS destinations for the rental car service.

Fifth, a correction is made to the matrix that goes back to Part 1 of this example. In that matrix, the input and output entries for driving directions were incomplete because the driving directions were not provided to the traveler. The revised matrix below has an additional output of traveler’s driving directions (number 16) that occurs concurrently with the “Driving directions response” input and after the inputs for the various reservations responses. The type of modification is likely to occur as you develop a matrix. It is possible to overlook a relationship or to leave out an input or an output. Nevertheless, what often happens is that as you study the matrix and the generated diagram, these errors or omissions come to light. In this case, I noticed the error when I was adding the output for GPS destinations.

Finally, a number of informational outputs are added to update C. R.’s calendar (C. R. is the Traveler in the matrix), C. R.’s spouse’s calendar, and C. R.’s manager’s calendar. Also, the travel plans are saved for possible future reference.

This matrix generates the following diagram. (You can click on this — or any of the other images — for a larger size.)

Starting at the left, further decomposition of the first process, “Obtain travel information,” is shown below. This further decomposition results from adding the inputs and outputs for CRM customer information and the traveler’s profile. (For simplicity, I am not showing the intermediate sub-matrix for each further decomposition shown in this part of the example. Setting up the sub-matrix was described in Part 2.)

The next process, “Check travel availability,” is similar to the process in Part 2 with the same name. Further decomposition of this process is shown below. The difference between this diagram and the one in Part 2 is that the task “Receive travel dates and customers,” in Part 2 was moved to the first process above and renamed “Receive travel information.” Again, this change was necessitated by the addition of the inputs and outputs for CRM customer information and the traveler’s profile.

The further decomposition of the next two processes is a bit confusing. They appear to break up the various aspects of making reservations. The “Reserve flight and/or pkg” process is shown below. The Decomposition Matrix specifies that only flight information is needed before the generation of the “Manager’s trip summary.” This results in this further decomposition.

Therefore, the remaining reservations are in the “Reserve car and hotel” process. That further decomposition is shown below.

This confusing decomposition is an example of why I often describe the use of the Decomposition Matrix as similar to a working with another designer at a whiteboard. You, the designer, might have to make a decision as to what you think is best. For example, you might decide this decomposition is fine because it generates output at the earliest possible point. In this case, when the “Manager’s trip summary” is generated. On the other hand, you might decide you prefer to consolidate the reservation tasks in one process so that it looks like the further decomposition shown below. This merges the “Reserve flight and/or pkg” and “Reserve car and hotel” processes in the first business process diagram in this posting. The remainder of that diagram remains the same.

To force the Decomposition Matrix to generate this diagram, three check marks would need to be added: Input 5 for Outputs 19 and 20, and Input 7 for Output 20.

Previous: Business Process Decomposition, Part 2

The first bit of complexity that I am adding to C.R.’s business trip is the choice of travel options. In Part 1, there were inputs and outputs for flights, rental cars, and hotels. Now, I am adding the possibility of air/car/hotel packages from Travel Agencies that provide information on packages as a service. C. R. will then need to choose among the various possibilities. Columns 8 and 9 along with rows 9 and 10 in the matrix below show the inputs and outputs for the air/car/hotel packages.

This matrix generates the following business process diagram.

This diagram introduces processes. They are shown in a different color with a plus sign at the bottom of the process entity. Processes reduce the visual complexity of the diagram. The plus sign indicates that a process may be decomposed further.

A quick inspection of this diagram shows that it is missing one aspect of the description of C. R.’s business trip. It appears that all the travel availability activities flow directly into making reservations. The diagram is missing any decision process concerning travel options. The next matrix adds the travel decision among the various travel options. The highlighted column and row in the matrix below show those choices.

Adjusting the matrix based on visual feedback from the generated diagram is a common way to explore design decomposition using the matrix. By the way, the blue-shaded box to the right of the matrix is an aid for completing the matrix. It is not uncommon to have large matrices. As a result, the row and/or column heading might not appear on the screen. The blue-shaded box appears when your cursor hovers near a check box.

The travel decision response is shown as an input to the travel decision request. I have marked it this way for two reasons. First, it is possible that the person sending the travel decision response might require changes to the travel plans necessitating another travel decision request. Second, I as a designer may want this request/response sequence to occur in the same task. For the latter case, you can make this more likely to occur by having the related response also be an input for the related request.

The most recent matrix generates the diagram shown below. I have moved the elements around to make it easier to read and added the labels.

As mentioned earlier, the process show that further decomposition is possible. When you scroll down the Results page, you will see options for further decomposition that will look like:

Recall that I mentioned that the numbering was only for identification purposes. This is where the numbering is used. For example, “Process 1″ in the text box above relates to “Process 1″ in the generated diagram. As in the diagram, you can rename the label. Clicking on “Setup Matrix” will generate a sub-matrix for this process. It is shown below with the proper label for the matrix name.

You can submit this matrix as is or modify it. You might know, for example a data source that is used inside a process that is not visible outside the process. If that would be the case, you can add the necessary inputs, outputs, and check marks. In this example, I will use the matrix as is. The following diagram is generated from this matrix.

Note the numbering relates to the original process numbering. The numbering after the decimal point is also just for identification. The following is the same diagram with meaningful labels.

If you compare this diagram to the last one in Part 1, you will see that the “Obtain possible flights” task has moved to the second task on one of the flows. This is a result of adding the choice of air/car/hotel packages from Travel Agencies. The task to obtain possible flights is needed only in the “do it yourself” flow, if you will.

Note that obtaining possible flights appears before checking the availability of rental cars and hotel rooms. The assumption is that flight times might affect the requirements for rental cars and hotel rooms. You may not agree with this assumption or you might think I am missing something. And you could very well be right. This is why I say it is important to get all the domain experts together at the same time when developing your matrix. One possible way to do this would be to project the generated diagram on a wall and discuss the diagrams as you incrementally modify the matrix. Also see the Wiki entry on this site for hints on using the Decomposition Matrix.

I repeated the steps for further decomposition on “Process 2,” renamed “Make travel reservations.” The resulting diagram with meaningful labels is shown below.

Next: Business Process Decomposition, Part 3

Previous: Business Process Decomposition Example, Part 1