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.

Here’s a quick example of how to use the Decomposition Matrix to create a data flow diagram (DFD) that shows the decomposition of services in a service-oriented architecture (SOA). I’ve chosen a generic example of legacy systems that will be accessed by services. This will create a decomposition for a services interface layer on top of the legacy systems.

The inputs from these legacy systems are shown below at the left in the Decomposition Matrix. These inputs could be from existing packaged software, custom legacy systems, legacy databases, or software as a service (SaaS) on the Internet, etc. The exact nature of the legacy sources for the inputs does not change this example.

The outputs shown from the services in the Decomposition Matrix are just some of the possibilities. The outputs needed would vary based the needs of the particular business. Since this is a generic example, I’ve chosen to show enough of the possible outputs to create a useful example.

The initial decomposition is shown below.

The same diagram is shown below after some minor rearranging along with labeling the processes and the data flows.

Note that the label on the data flow from a given process to another process is the same as the label on the external flow for that process. Also note that some top-level processes have multiple outputs. This indicates that the service input parameters will need the ability to specify sorting the XML output and/or selecting which XML tags should be included in the output. Such input parameters are not shown in DFDs, but they will be needed when you design the services. What is shown in this DFD –  and any DFD — is the flow of data, but not the control provided by input parameters.

I hope you found this Decomposition Matrix example useful. Also, I welcome any comments or suggestions that might improve it. Click on “Contact” in the menu bar at the top of the page to send me your comment or suggestion.

While correcting the defects noted earlier, I added an option for the display of data flow diagrams. This option displays data flow diagrams from bottom to top. This is the way many of us think of services in a service-oriented architecture (SOA). Previously, the only display option for data flow diagrams was from left to right. To get the bottom to top display, select the radio button next to “Data Flow Diagram for Services” on the Matrix page. Note: if you see rectangles instead of circles in the display, you will need to close and reload your browser.