Blog

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

To illustrate the use of the Decomposition Matrix, I am using an example from my book, Web Services and Service-Oriented Architectures, The Savvy Manager’s Guide. The example is a high-level view of a service-oriented architecture that uses Web services. It is a story of a business trip in the not-too-distant future. In the story, C. R. is about to take a business trip. This trip involves flying to California from the Midwest, renting a car, and visiting customers in different cities over three or four days. The trip is initially described on pages five through eight of the book. It is re-visited near the end of the book in order to add details to the trip that are related to topics discussed in the book. This latter description appears on pages 185 through 188.

This decomposition will flesh out the details of this business trip in the form of a business process diagram illustrated with a subset of BPMN notation. In order to describe the use of the Decomposition Matrix, I will incrementally develop this decomposition. First, I am starting with the basics of a business trip that should be familiar to most readers: the process of finding available flights, a rental car, and hotel rooms for a given set of travel dates followed by the appropriate reservations and generating a set of driving instructions. The Decomposition Matrix at this point in the decomposition is shown below.

The various inputs are rows in the matrix with labels shown at the left and the outputs are columns with labels shown at the top. The first row is for travel dates and locations. The input of travel dates and locations occurs before or concurrent with all of the outputs. So, reading across, you can see all columns for this row are checked. For instance, you can phrase one of the relationships as “the input of travel dates and locations occurs before or concurrently with the output for a flight availability request.” The portion in italics is important to remember. You can either read across the rows or down a column using the italicized portion as part of your phrasing.

By using this matrix, you only need to consider a given row and a given column at any one time. The Decomposition Matrix allows you to focus literally on one input and one output rather than the entire decomposition. For larger decomposition problems, this is a major advantage since it is difficult, if not impossible, to juggle an entire decomposition in your head. For details on getting started with a matrix see the Decomposition Matrix entry in the Wiki on this site.

When arranging flights, the process involves first using the travel dates and locations to request the available flights. Sometimes as part of this same task, you need to either make multiple requests using different flight times or you might make requests to multiple airlines. This is shown in the matrix below with a check mark in Row 2, flight availability response, and column 1, flight availability request.

Note, however, that row 3, flight reservation response, is not checked. This essentially says you cannot have a response before a request. Yes, it is possible to have a list of available flights and not be able to get a reservation on any of them, necessitating another flight availability request. I will get to that issue later. For now, the normal process flow will be covered.

Continuing with the example, column 4 shows what inputs occur before or concurrently with the input to a car rental reservation request. See the matrix below.

Before such a request, you need to know what cars are available for your travel dates and locations. You also would like to know if there are flights and hotel rooms available. You do not, however, need to reserve a room before a car. On the other hand, car rental agencies like to know your flight number at the time of rental. So, there is a check mark in row 3, flight reservation response, for column 4, because this occurs before or concurrently with the output for a car rental reservation request.

Clicking on the Submit button generates the business process diagram shown below.

The Results page that contains this diagram also describes how you can move the entities around to make it easier to understand the diagram.

As I build on this example, I will regularly mention the importance of trying to label the tasks. Difficulty in coming up with a label is one hint that your inputs and outputs might not have the correct check marks. Another hint is that the generated diagram seems confusing. For example, you might see a response coming in before its related request or way too many interconnected lines that are hard to follow.

By the way, the numbering of the tasks does not have any meaning. It is used for identification and will be explained in a later posting.

For now, this generated diagram appears to be OK. Shown below is the same diagram as above. I have rearranged the diagram and added the labels.

The diamond-shaped gateways are left blank. The matrix does not provide the information needed to determine the type of gateway. This choice of gateway is left to the designer.

As you may have noticed elsewhere on this Web site, I compare generating these diagrams to working with other designers at a white board. This site provides a quick way for you to try out different decompositions or to see the effects of adding an input or an output or what might happen if your change the relationships between certain inputs and outputs. This site does not provide a complete design tool. I expect that at some point, you will want to transcribe a given diagram into your design tool and add other BPMN notation as needed – much like you would if you were working at a white board.

Finally, this example is obviously not a difficult decomposition. I will be adding complexity to the planning of C. R.’s business trip in future blog entries.

Next: Business Process Decomposition, Part 2