Wiki: DesignDecomposition

High-level decomposition is the emphasis of this website. For example, you could use the Decomposition Matrix on this site to generate data flow diagrams (DFDs) the could help determine the high-level optimal sub-systems for a business. You could then chose processes in that DFD to be represented as a business process diagrams, again generated from the Decomposition Matrix (which would be sub-matrix of the original Decomposition Matrix). Finally, if you are considering services, you could use the Decomposition Matrix to determine the properly granularity of the services∞.

The Decomposition Matrix can help you gather part of the requirements. It forces people to determine all the inputs and outputs along with how those inputs and outputs are related. This is quite detailed and requires people to think through those relationships. Also, early iterations of the generated diagrams based on the Decomposition Matrix often do not make sense to people who are the subject matter experts. This is usually because either inputs or outputs were missed -- or that the relationships between the inputs and outputs were not specified properly. This creates an opportunity to get the specifics correct on the relationships between the inputs and outputs.

High-level decomposition is the emphasis of this Web site. For example, you could use the Decomposition Matrix on this site to generate data flow diagrams (DFDs) the could help determine the high-level optimal sub-systems for a business. You could then chose processes in that DFD to be represented as a business process diagrams, again generated from the Decomposition Matrix (which would be sub-matrix of the original Decomposition Matrix). Finally, if you are considering services, you could use the Decomposition Matrix to determine the properly granularity of the services∞.
An optimal high-level decomposition often aids in simplifying both development and maintenance of a software system. A good high-level decomposition establishes boundaries between sub-systems that minimizes coupling.
The Decomposition Matrix can help you gather part of the requirements. It forces people to determine all the inputs and outputs along with how those inputs and outputs are related. This is quite detailed and requires people to think through those relationships. Also, early iterations of the generated diagrams based on the Decomposition Matrix often do not make sense to people who are the subject matter experts. This is usually because either inputs or outputs were missed -- or that the relationships between the inputs and outputs were not specified properly. These creates an opportunity to get the specifics correct on the relationships between the inputs and outputs.

Determining system boundaries can often be a difficult exercise. This asks you to determine what is inside a system and what is outside the system. You would think that would be easy, but it is my experience that it is not for most people. I wrote a Blog entry design context∞ that provided some thoughts on the process I often use to help determine system boundaries.

Determining system boundaries can often be a difficult exercise. This asks you to determine what is inside a system and what is outside the system. You would think that would be easy, but it is my experience that it is not for most people. I wrote a Blog entry∞ that provided some thoughts on the process I often use to help determine system boundaries.

High-level decomposition is the emphasis of this Web site. For example, you could use the Decomposition Matrix on this site to generate data flow diagrams (DFDs) the could help determine the high-level optimal subsystems for a business. You could then chose processes in that DFD to be represented as a business process diagrams, again generated from the Decomposition Matrix (which would be sub-matrix of the original Decomposition Matrix). Finally, if you are considering services, you could use the Decomposition Matrix to determine the properly granularity of the services∞.
The Decomposition Matrix can help you gather part of the requirements. It forces people to determine all the inputs and outputs and how those inputs and outputs are related. This is quite detailed and requires people to think through those relationships. Also, early iterations of the generated diagrams based on the Decomposition Matrix often do not make sense to people who are the subject matter experts. This is usually because either inputs or outputs were missed -- or that the relationships between the inputs and outputs were not specified properly. These creates an opportunity to get the specifics correct on the relationships between the inputs and outputs.

In software design and modeling, decomposition is the separation of a system into smaller or basic sub-systems. This effort is all about simplification. Simplification is meant to make it easier to make design decisions.
High-level decomposition is the emphasis of this Web site. For example, you could use Decomposition Matrix on this site to generate data flow diagrams (DFDs) the could help determine the high-level optimal subsystems for a business. You could then chose processes in that DFD to be represented as a business process diagrams, again generated from the Decomposition Matrix (which would be sub-matrix of the original Decomposition Matrix). Finally, if you are considering services, you could use the Decomposition Matrix to determine the properly granularity of the services∞.
Determining system boundaries can often be a difficult exercise. This asks you to determine what is inside a system and what is outside the system. You would think that would be easy, but it is my experience that it is not for most people. I wrote a blog entry∞ that provided some thoughts on the process I often use to help determine system boundaries.
Designers are no different than anyone else. We tend to repeat what has worked for us in the past. Many times, that is an effective approach. But, obviously, it can be the wrong approach since one "size" does not always fit all. Again, the Decomposition Matrix can help. 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.
This Wiki entry started out discussing the importance of simplification. The very nature of the Decomposition Matrix simplifies design decision making. Instead of trying to grapple with the entire design, the Decomposition Matrix only asks you to make a binary decision: Is a given input related to a given output. That is all. You might be surprised at the discussions that can ensue from such a simple decision. Nevertheless, it is a relatively simple decision -- and it is the accumulation of similar simple decisions about the other inputs and outputs that creates a Decomposition Matrix -- allowing you to generate a decomposition that might prove to be helpful in your design.

An optimal high-level decomposition often aids in simplifying both development and maintenance of a software system. A good high-level decomposition establishes boundaries between subsystems that minimizes coupling.
The Decomposition Matrix can help you gather part of the requirements. It forces people to determine all the inputs and outputs and how those inputs and outputs are related. This is quite detailed and forces people to think through those relationships. Also, early iterations of the generated diagrams based on the Decomposition Matrix often do not make sense to people who are the subject matter experts. This is usually because either inputs or outputs were missed -- or that the relationships between the inputs and outputs were not specified properly.

In software design and modeling, decomposition is the separation of a system into simpler or basic sub-systems. This effort is all about simplification. Simplification is meant to make it easier to make design decisions.

Types of Design Decomposition

There are two types of design decomposition: high-level and detailed.
High-level decomposition is the emphasis of this Web site. For example, you could use Decomposition Matrix on this site to generate data flow diagrams (DFDs) the could help determine the optimal subsystems for a business. You could then chose processes in that DFD to represent as a business process diagram, again generated from the Decomposition Matrix (which would be sub-matrix of the original Decomposition Matrix). Finally, if you are considering services, you could use the Decomposition Matrix to determine the properly granularity of the services.
Detailed decomposition techniques could be used to flesh out the high-level decomposition. Generally, detailed decomposition is found at the code level. Although DFDs have been suggested for this level of decomposition in the past, it is my opinion that any of the agile techniques are better suited to detailed decomposition.
An optimal high-level decomposition often aids in simplifying both development and maintenance of a software system.

How to Avoid Replicating Past Decompositions

Decomposition Should Reflect Current and Not Past Requirements

How the Decomposition Matrix Might Help You

This is under construction. Design decomposition 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.

Decomposition that Reflects Current and Not Past Requirements

In software design and modeling, decomposition is the separation of a system into simpler or basic sub-systems.

Reasons for Design Decomposition

An optimal decomposition often aids in simplifying both development and maintenance of a software system.

Design Decomposition as a People Problem

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.

Determining System Boundaries