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 Guide 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.
Copyright © Barry & Associates, Inc. All Rights Reserved. You may use this material for your work or classes. Copyright and Reprint Policy.