Generate an Optimal Design Decomposition[image]

This site can help you with the design of your enterprise architecture. It provides a free service to help designers work through the design decomposition process. A feature of this service is the Decomposition Matrix on which you identify the relationships between inputs and outputs of the system being designed. The Decomposition Matrix then generates an optimal decomposition that is shown as either a business process or data flow diagram. This site also has supporting material and references to help advance the understanding of software decomposition. I hope you find the site useful.

The Decomposition Matrix is still being refined. So any feedback you can provide would be appreciated.

- Doug Barry

“Instead of starting out with a diagram (and drawing something you likely have seen before), the Decomposition Matrix forces you to think of only inputs and outputs and their relationships. This provides the designers and subject-matter experts with a way to think differently about the system they are about to design.” From the Wiki on this site.

Decomposition Matrix

The service to help designers starts with the Decomposition Matrix.
If you would like more background on using the Decomposition Matrix, see the "Get Started" section below, the decomposition example in the Blog, and the entry for the Decomposition Matrix in the Wiki on this site. If you need help in determining inputs and outputs, see the Blog entry for design context.

 

When you press Submit, you will go to the next page where you will complete the Decomposition Matrix. Also, on the next page, you can change the number of inputs and outputs, if needed.

Augment Your Methodology

The Decomposition Matrix is intended to augment your existing methodology. For example, it is an easy way to involve subject-matter experts early in development without requiring them to learn any notation. Here are some other examples:

Basic Business Process or Data Flow Modeling: This is the most obvious use of the Decomposition Matrix. You can use the Decomposition Matrix as part of whatever methodology you use for business process models or data flow diagrams. See the next section on ways to use the Decomposition Matrix.

SOA Service Modeling: Thomas Erl describes service modeling starting on page 397 in Service-Oriented Architecture: Concepts, Technology, and Design. The Decomposition Matrix could assist with two steps in this modeling process. First, business process diagrams generated using the Decomposition Matrix could assist with the "Decompose business process" step. Second, data flow diagrams generated using the Decomposition Matrix could assist with the "Create business service candidates" step. See the Data Flow Diagram Example for Services in the Blog.This is much like having another designer at a whiteboard

Model Driven Architecture (MDA): The business process diagrams generated using the Decomposition Matrix could assist with the development of models in the Business Process Modeling Notation (BPMN) used as input to the Business Process Definition Metamodel (BPDM) as part of the Computation Independent Metamodel (CIM) in the Model Driven Architecture (MDA).

Scrum: Scrum is intended for the management of software development projects, maintenance teams, and program management. Like the Decomposition Matrix, Scrum is agnostic about the software development methodology used. Scrum can be used with any methodology that may, at times, also use the Decomposition Matrix.

Agile Techniques: The Decomposition Matrix could be used at any point to work through a decomposition problem as part of agile software development.

Rational Unified Process (RUP): The Decomposition Matrix could assist with three disciplines in the Rational Unified Process. Business process diagrams generated using the Decomposition Matrix could assist with the requirements discipline and the business modeling discipline. Data flow diagrams generated using the Decomposition Matrix could assist with the analysis and design discipline. You would, of course, need to convert the data flow diagrams to Unified Modeling Language (UML) notation.

Can you suggest another methodology that can be augmented by the Decomposition Matrix? If so, please contact me.

Four Possible Ways to Use the Decomposition Matrix

Create a initial decomposition: Sometimes the first-level decomposition is the hardest. Use the Decomposition Matrix to draft your initial decomposition.

Work through a problematic portion of a decomposition: Everyone gets stuck at one time or another. Use the Decomposition Matrix to see if the diagram it generates offers any new ideas for your decomposition.Use this to get new ideas or to work through a problem

Help gather requirements: The Decomposition Matrix can be used to gather a portion of your project's requirements. It can document which inputs are related to which outputs. You can then check those requirements by generating a diagram based on the Decomposition Matrix. If the diagram does not appear to make sense, then there is likely something wrong with the Decomposition Matrix. Therefore, something is likely wrong either with the requirements related to the relationships between the inputs and outputs in the matrix or you are missing inputs or outputs.

Validate an existing decomposition: Use the inputs and outputs of an existing diagram to set up a Decomposition Matrix. Then have users, technical people, managers, and anyone else involved in the project add checkmarks to the matrix. Have the group agree on a merged matrix. Generate a diagram based on the matrix and compare this to your existing decomposition. Sometimes this process brings out important details that were previously overlooked.

Please contact me if you have suggestions for other ways to use the Decomposition Matrix.

Think of the Decomposition Matrix as a Helper

You should think of using the Decomposition Matrix as being much like having another designer help you work through a design issue at a whiteboard. The results may provide you with some new ideas or help you get past an issue that has you stuck. This service is not a design methodology. It is simply helps you with decomposition that you can, in turn, use with the methodology or development technique of your choice.

Get StartedDecomposition Process

To get started, you need to have some idea of the number of inputs and outputs for your design. This generally known as the design context. If you already know this, enter the number of inputs and outputs in the form near the top of this page.

The inputs and outputs for your context are used by the Decomposition Matrix. One aspect of the Decomposition Matrix is that it forces you to look at a problem differently. Instead of jumping to immediately drawing boxes or bubbles to describe a system, it requires that you to think about the inputs and outputs of a system and how those inputs and outputs relate to each other. This avoids the potential hazard of getting bogged down in drawing techniques or having to teach a visual vocabulary to users, managers, and other non-technical people involved in a design effort.

The Decomposition Matrix results are presented as either business process or data flow diagrams. The two presentations are representative of various diagramming techniques that show either sequencing of tasks or the flow of data:

Business process diagrams are representative of techniques to show the sequencing of tasks. Data flow diagrams are representative of techniques to show the flow of data between processes.

The two types of presentations are meant to provide designers a visual vocabulary with which they are accustomed. One limitation of the Decomposition Matrix is that the information provided in the matrix precludes generating all the diagramming artifacts that a designer might use. The results do not show data sinks and sources, types of gateways, etc. Yet, the presentations are complete enough to help designers work through design problems. For most designers, the missing artifacts should be easy to add. Also, these diagrams can readily be translated by designers to other visual vocabularies such as UML swimlanes.

Background

The  Decomposition Matrix is based on work done by Mike Adler in the late 1980s when we both worked in Corporate Research and Engineering at Control Data Corporation. Mike developed an algebra for design decomposition. I have implemented that algebra (with a few changes and enhancements) to analyze a Decomposition Matrix.

Finally, be advised that I am still tinkering with both the decomposition algebra and its implementation. Please let me know if you have any suggestions for improvement. You can either contact me or post a suggestion of the Forum.

Decomposition

In software design and modeling, decomposition is the separation of a system into simpler or basic sub-systems. As many experienced designers know, it is often a difficult task to create an optimal decomposition of a system. It is often as much a people problem as a technical problem. An optimal decomposition requires gathering all the necessary requirements from people and then using those requirements to design the appropriate decomposition of systems and sub-systems. It is also often difficult to know if you have all the requirements. And, given you actually have all the requirements, it is difficult to create an optimal decomposition. See the discussion of design decomposition in the Wiki on the site for more on how the Decomposition Matrix can help with design decomposition..

Community

To help advance the understanding of software design decomposition, this site has three other features:

Blog: There you will find my thoughts, observations, and ideas about design decomposition and commentary on the state of the industry. Wiki: This an ongoing effort to create a resource for using the Decomposition Matrix for design. In addition to my contributions, I am hoping other people in the design community will contribute to this Wiki. If you would like to contribute, contact me. Forum: This is for anyone to ask questions or provide comments on design decomposition or this site.