The Design Structure Matrix (DSM) or Dependency Source Matrix is a design modeling method used by engineers to understand and improve the practice of developing complex systems. Performs system analysis, process planning, and organization planning. It is an extremely flexible method of network modeling with extensive applications in engineering management. The DSM model can help engineers master the vast amount of information needed to understand, design, and improve engineering systems. Because no individual knows enough to design today’s complex systems, useful information management techniques need to draw on individuals’ knowledge and present it in a way that allows an interdisciplinary team to review and evaluate it. Compared to other network modeling methods, the main advantage of DSM is the graphical nature of the matrix display format. The matrix provides an extremely compact visualization and a clear understanding of information flow patterns among its activities. For example, a system development project fundamentally differs from construction project in two major aspects. A product development project is based on information content and their accompanying information-dominated design and manufacturing methods. And a typical system development project is characterized by its highly coupled and interdependent activities, which must converge iteratively to an acceptable design solution. The most common causes for such repetition are due to activities beginning work without the necessary information, the arrival of new information, change of that information causing rework, or reevaluated assumptions in previous activities. Since they do not tolerate feedback relationships, the well-known Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM) succeed only if activities are sequential and/or parallel and fail significantly where iterative relationships exist. The idea of representing the system architectural components and relationships in the form of a matrix is not new, but the term “Design Structure Matrix” (DSM) was coined by Don Steward in 1981 to denote a generic matrix-based model for project information flow analysis. Since then, the DSM has become a popular representation and analysis tool for system modeling, especially for purpose of decomposition and integration.

DSM can help us perform decomposition analysis on complex systems into subsystems and components, on complex processes into subprocesses and tasks, and on large organizations into teams and individuals. Specifically, the goal of decomposition of a complex system into a set of subsystems and subsystems into a set of components is to achieve a multilayer decomposition that will create a network. The idea of a simple tree structure can also describe such a network. The same tree structure would also describe the decomposition of the process. There are so many things to do, and it is critical to know how we organize all this information. The setup of different phases can help us to find the parallel workstreams for the different types of work that we must do. Thus, we decompose just to get our head around the complexity of the thousands of things. In a similar way, we decompose an organization. The structure of an organization can be traditionally decomposed in terms of reporting relationships and the way we avoid and manage all the people involved in the organization. When we study the architecture of the systems, processes, and organizations we must understand their structure and find their decomposition. When we decompose the components in a system, these components have interfaces and connections. This network of interfaces and connections may be a simple network, or it could be very complex. A simple set of connections would be what we ideally call modular decomposition. That is each component interfaces with a neighboring component in its subsystem or module but has no connections to the entire network. In a similar way, we decompose the process. When we have input-output relationships links between elements of the process, tasks, and activities have ways in which they must work together and it is not that everything is connected to everything, but there is a pattern there and finally in the organization. In a very simple organizational network, somebody would say that everyone works with their teammates, but they don’t work with anyone else right now. These networks are never that simple. So, in any real or complex structure would say somebody that there are connections across the network, people are interfacing to people across other parts of the organization, components have interfaces with components in other modules or subsystems, tasks have input and output relationships perhaps across the whole network. Therefore, on one hand, it is not that everything connects to everything, and on the other hand, the architectures are never ideally decomposed and simple. So that’s one domain. The systems or product domain.

In the process domain, we can basically do the same thing although networks will look different because they are a process model, and process models have a directional flow toward them. That is, activities have inputs and outputs, and so forth. A process model will represent the network of tasks or activities. We write the tasks or activities on the side and along the top of the matrix, we order them in a certain way and then we can reveal the process flow. At this point, we can identify why the process takes so long and why it is so frustratingly iterative and repetitive, and slow, or what happens when the process fails?

In the third domain, the organizational domain we can also do the same thing. We can decompose the organization into people or teams or workgroups or departments and some other organizational elements and then we could look at the network of connections across the organizational elements. How do people work together? To what extent do they communicate or work closely together or not.

Hence, in the question, how can we put our hands around a complex architecture or structure? I can say that there are many ways to answer this question along with a whole field of network analysis that defines complex networks. However, a specific approach has been found that is very useful and it is called DSM or the Design Structure Matrix. A DSM is a binary square matrix that is mainly known as an nXn matrix that contains an equal number of rows and columns. Using the nXn square table in the system architecture domain represents the network of components in a system that can map the connections between components, between activities, or between people. Thus, if we have an nXn matrix of components, the resulting diagram will be a mapping of the interfaces between the components. It will not be an interface between components to people, components to tasks, or components to suppliers. Remember that the components of nXn components matrix are not randomly connected. They have a pattern and if we can understand their network of connections then we can reveal the patterns and learn how a system is correctly architected or how to improve it. Specifically, a DSM is a simple square binary matrix with nonempty elements. A cell, thus, can assume one of only two values (0, 1), or (an empty cell, or “X” mark). An example of DSM is shown in Figure 15.

Activity names are placed on the left-hand side of the matrix as row headings and across the top row as column headings in the same order (order of their execution), a main DSM assumption is that activities are undertaken in the order listed from top to bottom. An off-diagonal mark (X) represents a coupling (an information flow, or a dependency) between two activities. If an activity receives information from activity, then the matrix element (row-column) contains an off-diagonal mark (x), otherwise, the cell is empty. Marks below the diagonal (sub-diagonal marks) are indicative of feedforward couplings (i.e., from upstream activities to downstream activities), while those above the diagonal (super-diagonal) represent feedback couplings (i.e., from downstream activities to upstream activities).

As they involve iterations, the latter type of couplings should be eliminated if possible or reduced to the maximum extent. If certain feedback couplings cannot be eliminated, the activities are grouped into iterative sub-cycles. For example, in Figure 13, activities (1, 2, and 3) and activities (6, 7, 8, 9, and 10) are grouped into two iterative sub-cycles.

A primary goal in basic DSM analysis is to minimize the number of feedback and their scope by restructuring or rearchitecting the process. In other words, by resequencing the execution of the activities to get the DSM into a lower-triangular form as possible. To achieve this goal, Don Steward proposed a two-phase approach to partitioning and tearing. Partitioning is based on system structure and involves resequencing the DSM activities in order to eliminate feedback couplings as much as possible. Pull the rest of the feedback close to the diagonal as possible. And group the activities into blocks such that each block represents an iterative sub-cycle. In the second phase, tearing, each block results from phase one being considered individually. Tearing is based on the semantics of the systems and aims to relatively order the activities within each block to achieve the same previous objectives.

As I stated earlier, the success of the DSM method is determined by an appropriate system decomposition and by the accuracy of the dependence relationships. Therefore, it is vital to decompose the system under study carefully into a comprehensive set of meaningful system elements. An appropriate decomposition can be established by gathering a group of managers/experts from different functional groups of an organization and asking them to collectively list the different subsystems that comprise the system as a whole. The decomposition can be hierarchical or non-hierarchical (sometimes called network decomposition).

About the DSM method you can find further information from my book “Engineering Excellence DNA in Applied Systems” by Georgios Ardavanis.