Different DSM Types
There is no pre-defined DSM that is helpful for any problem that is to be structured. Rather, DSM needs to be adapted to the kinds of elements and relations that prevail in the system in focus. Basically, the type of the elements and dependencies needs to be defined as precisely as possible to obtain the information structure for the DSM.
|Term in Systems Theory||entity||relation|
|Term in Graph Theory||node, vertex||edge, arc|
|Terms common for the use of DSM||element: especially in matrix-based methodologies, the term “element” is used to refer to an entity that is entered into a row or a column||dependency / interdependency: whereas “relation” refers to any kind of connection or association between two entities, may they be directed or not, a dependency often implies a direction as element A will depend on element B|
|Regrouped as||domain||relationship type|
From a structural point of view, a system can be disentangled down to a network-like model of entities and their relations. These entities can be of different kinds, e.g. some entities in a process can be documents, while others can be oral information, and other again can be work packages. However, if many such kinds are mixed, the network is incoherent.
Each kind of entities represents a specific view to the system, called “domain”. The purpose of a domain, which is comparable to a “class” of objects in object-oriented programming paradigms, is to create “homogeneous networks” that allow to compare elements during structural analysis. Compare Maurer, M.: Structural Awareness in Complex Product Design, PhD Thesis, Institute of Product Development, Munich, 2007
The term “domain” can therefore be defined as one specific view (among several) on one complex system at a time. It comprises one type of entity that can be analyzed by the same algorithm, providing a meaningful result. A DSM always only contains elements from one domain.
Similar to domains, the relationships within a domain need to be uniform to allow for a systematic modeling and a purposeful analysis. While a domain contains entities of a kind, a relationship type refers to a class of relations that are similar. The relationship type therefore defines the kind of dependency between two elements. It is described as “(an element of domain A) is related to (an element of domain B), where domains A and B refer to the two domains that are to be related; in a DSM, having only one domain, A and B are the same.
Specifying the DSM you need
To better specify the DSM type needed, first, the relevant elements should therefore be classified. Commonly, a mind map is helpful to do so. Similar elements should be regrouped and denominated respectively. If, e.g. modularization is the goal, requirements, functions, and components are relevant. To modularize the components better and to better understand their interfaces, the domain “components” can be selected, and a DSM can be set up that has the components of the system as elements in rows and columns.
Second, the relationship type is defined. Again, a mind map can be useful to come to a useful classification. It is important that a DSM contains only one relationship type, as only then the analyses will make sense.
Common classification of DSM
Four different common types of data that can be represented in a DSM have been identified, however, any other type of DSM is possible, too (Compare Browning, T.: Applying the Design Structure Matrix to System Decomposition and Integration Problems: A Review and New Directions. IEEE Transactions on Engineering Management 48 (3), 2001, pp. 292-306):
|DSM data types||Representation||Applications|
|Component-based (Product)||Component relationships||System architecting, engineering and design|
|People-based (Organization)||Organizational unit relationships||Organizational design, interface management, team integration|
|Activity-based (Process)||Activity input/output relationships||Process improvement, project scheduling, iteration management, information flow management|
|Parameter-based (low-level Process)||Design parameter relationships||Low level activity sequencing and process construction, sequencing design decisions|
A component-based DSM documents interactions between elements in a complex system architecture. Different types of interactions can be displayed in the DSM. Types of interactions will vary from project to project.
Some representative interaction types are shown in the table below (Compare Pimmler, T. U.; Eppinger, S. D.: Integration Analysis of Product Decompositions, Proceedings of the ASME Design Theory and Methodology Conference, Minneapolis, MN, September 1994).
|Spatial||needs for adjacency or orientation between two elements|
|Energy||needs for energy transfer/exchange between two elements|
|Information||needs for data or signal exchange between two elements|
|Material||needs for material exchange between two elements|
Other classifications are possible, too. Another comprehensive list for modeling dependencies in a product architecture is provided by Jarratt, T. A. W.: A Model-based Approach to Support the Management of Engineering Change, PhD Thesis, Cambridge University Engineering Department, 2004:
|Mechanical steady state||Components are in physical contact and they impose a steady state mechanical load on each other. This is a symmetrical relationship.|
|Mechanical dynamic||Components are in contact and interact through a fluctuating force or displacement. This can be a directional relationship.|
|Spatial||Components are touching or adjacency and orientation are important. This is a symmetrical relationship.|
|Thermal steady state||There is a steady state temperature difference between the two components. This can be a directional relationship.|
|Thermal dynamic||There is a fluctuating temperature difference between the two components. This can be a directional relationship.|
|Electrical signal||A signal passes from one component to the other. This can be a directional relationship.
|Electrical earth||There is an electrical earth connection between the two components. This can be a directional relationship.|
|Electrical dynamic||The physical design or logic driven behavior of one component is connected to the physical design or logic behavior of the other. This can be a directional relationship.|
As an example, consider the material interaction between components for an automobile Climate Control System. In this case, e.g. the engine fan (B) needs transfers material to the condenser (E), as there is an “X” in cell (B, E).
The matrix can now be rearranged in order to obtain clusters of highly interacting components while attempting to minimize inter-cluster interactions. This way, the data is not changed, but the matrix rows and columns are only swapped pairwise to obtain a different matrix layout. The obtained groupings represent a useful framework for reorganizing the product architecture and putting the focus on the interfaces among modules.
Clustering the "X" marks along the diagonal of the DSM resulted in the creation of three clusters for the Climate Control System. These clusters represent groups of components that are closely interconnected. They can be used to define modules that can, e.g. be ordered from different system suppliers or that can be used across a series of different refrigerators (small, medium, large volume, for example) as carry-over modules with well-defined interfaces to the other modules (=clusters).
|Cluster 1||Front End Air Chunk|
|Cluster 2||Refrigerant Chunk|
|Cluster 3||Interior Air Chunk|
This approach is used for organizational analysis and design based on information flow among various organizational entities. Individuals and groups participating in a project are the elements being analyzed (rows and columns in the matrix). A Team-based DSM is constructed by identifying the required communication flows and representing them as connections between organizational entities in the matrix. For the modeling exercise it is important to specify what is meant by information flow among teams. The table, below, presents several possible ways information flow can be characterized.
|Flow Type||Possible Metrics
|Level of Detail||Sparse (documents, e-mail) to rich (models, face-to-face)|
|Frequency||Low (batch, on-time) to high (on-line, real)|
|Direction||One-way to two-way|
|Timing||Early (preliminary, incomplete, partial) to late (final)|
Again, the matrix can be manipulated in order to obtain clusters of highly interacting teams and individuals while attempting to minimize inter-cluster interactions. The obtained groupings represent a useful framework for organizational design by focusing on the predicted communication needs of different players.
For an application example, compare McCord, K.; Eppinger, S. D.: Managing the Integration Problem in Concurrent Engineering, MIT Sloan School of Management Working Paper, no. 3594, 1993. They propose a team-based DSM to analyze the organizational structure necessary for an improved automobile engine development process.
Activity-Based (Task-Based) DSM
Consider a set of tasks in a process. These tasks must work together to fulfill the goal of the overall process. The exchange of information can thus be represented as a digraph or a DSM.
Three types of task interactions can be observed from the matrix. In the figure, below, tasks 1 and 2 are "independent" since no information is exchanged between them, the same is true for elements 4 and 8.These tasks can be each executed simultaneously (in parallel). Tasks 3, 4, and 5 are engaged in a sequential information transfer and are considered "dependent". These tasks would typically be performed in series. Tasks 7 and 8, however, are mutually dependent on information. These are "interdependent" or "coupled" tasks often requiring multiple iterations for completion. Ultimately, tasks 6, 7, and 9 are engaged in a cycle.
Marked cells below the diagonal represent potential rework loops or iterations in the process. This occurs when an activity is dependent on information from a task scheduled for a later execution. Such scenarios often lead to rework and are undesirable. A number of algorithms have been developed to minimize such instances of iteration (sub-diagonal marked cells) by re-arranging the sequence of tasks in the process. Methods are also available to handle iterations in the process that cannot be eliminated through re-sequencing. Commonly, the basic sequencing algorithms are referred to as “triangularization”, as the goal is to obtain an “upper triangular matrix” that has preferably no marks below the diagonal.
DSM models using simple binary representations display the existence of a dependency between two tasks without providing additional information on the nature of the interaction. Further studies have extended the basic DSM configuration by capturing additional facts on the development process. For example, the numerical DSM replaces marks with numbers in the off-diagonal cells to represent the degree of dependency between two tasks (see section on Numerical DSMs. This makes it possible to show, e.g., the probability of a feedback loop and thus prioritize important iterations in the process planning.
This type of modeling is used to analyze a design process at the level of parameter relationships. Black (1990) applied a parameter-based DSM to an automobile brake system design, using the DSM to describe the current practices of a brake system component supplier. The DSM shown below is extracted from the original DSM which was (103 by 103). After sequencing the parameters, in the resultant DSM (also shown below) two blocks (=clusters) of coupled, low-level parameter determinations become apparent. Compare Black, T. A.; Fine, C. H., Sachs, E. M.: A Method for Systems Design Using Precedence Relationships: An Application to Automotive Brake Systems, Cambridge, MA: MIT Sloan School of Management, 3208, 1990 (WP #3208-90-MS).
Parameter-Based DSM After Sequencing: