DSM for understanding, documenting and optimizing systems architecture

DSM stands for Design Structure Matrix - or Dependency - and it's a modeling tool and graphical representation used to clearly convey the elements comprising a complex system and their relationships in a compact and visual way, where a complex system can be a process, a product or an organization. Although not the original focus of the tool, invented for optimizing product development processes, DSMs can be an especially useful for documenting software systems, where the elements can be modules, classes, functions, or files, and the relationships can be dependencies, interactions, or information flows. Similarly, it can be applied to model and represent the dependencies between physical components of a distributed system, to discover problems such as components or microservices that might need to evolve in lock-step (coupling) and the degree or intensity of the dependency. There are two main categories of DSMs: static and time-based. Static DSMs are more relevant to our purposes here since they represent system elements existing simultaneously, such as components of a product architecture or groups in an organization. But for a development process, we could similarly apply a temporal DSM.

An example DMS, taken from 1, looks like this

A DSM can be seen both as a directed graph or network or as a matrix. Let's focus on Component C. It has two arrows pointing out, so the out-degree of C is 2. It also has two arrows pointing in, showing that it depends on two other components. That means its in-degree is 2. (Note that its dependency on itself adds both to its in-degrees and its out-degrees). Every component is of course, tautologically depending on itself.

A more realistic and complicated DSM for a internal combustion engine is shown here.

Where we can see that changes in the Crankshaft for example, will force different degrees of change in the rest of the components in column F.

Even at a simple use level, An obvious first application would be to complement documentation or blueprints of a software system, especially a complex or distributed one. While many people use classic tools like 4+1 view models or Architecture Decision Records, those do not capture dependencies between modules in the same way we’ve seen with in- and out- degrees. If anything, this would be similar to the Development view in the 4+1 view models, but improves it. The mere exercise in creating a DSM is already valuable in improved system understanding by documenting this dimension of systems. A DSM would make it easier, for example, to detect in a complex system, which subsystems, modules or components are the biggest change propagators, "a subsystem that depends on a large number of subsystems and in turn has many subsystems depending on it. Change propagators make systems brittle because they increase the likelihood that the effect of a change will propagate to a disproportionately large portion of the system" [2]. It's easy to imagine the same applied to organization design, for example teams on which many other teams depend on, and therefore can become a bottleneck, or steps in a process.

Taxonomies for dependencies can be created. For example, in [1] we see Spatial, Information, Energy or Material, and those categories can have a scale of intensity of the dependency, helping us detect required or undesirable dependencies, or couplings in a system, and the degree of that coupling. More specifically for software systems, the most relevant taxonomy would be informational, which we could relate to the different types of Connascence, and perhaps "spatial" understood from the point of view of tiers and physical architecture. It's not the same that two components are in the same space (in-memory, in-process) or in a separate tier, different space requiring a network hop or some other sort of remote call. For a better understanding of Connascence, Meilir Page-Jones explores it in depth in his 1996 book What every programmer should know about object-oriented design.

By using a DSM then, insights into the architecture of a non-trivial software system can be obtained in order to identify potential problems or improvement opportunities. For example, you can:

• Understand and improve the layering of classes etc in a software system and the strength of the dependencies. Optimal layering being the adherence to the principle that any given layer depends only on layers underneath but not on the layers above, or at least to reduce that as much as possible or to the extent that it is practical.
• Detect feedback loops or circular dependencies that indicate coupling and reduce modularity
• Apply partitioning algorithms to rearrange the elements into a more optimal order that minimizes dependencies across modules and maximizes cohesion within modules. See [2] for illustrative real-life examples optimizing layering.
• Analyze the impact of changes by tracing the propagation of dependencies through the matrix
• Compare different architectures or design alternatives by using metrics such as density, modularity, or complexity

Ultimately, this goes back to the older ideas of information hiding and that the value of modular design and subsystems comes precisely from hiding implementation details as much as possible and adhering to well-defined interfaces, which facilitates decoupled lifecycles and maintenance or replacement of hidden subsystems. An interesting read for the advent of modularity applied to complex software systems is [6]

A DSM can also be used to facilitate communication and collaboration among software developers, architects, managers, and stakeholders. Sharing a common representation of the system structure is better than relying on knowledge in the heads of people.:

• Communicate design decisions and rationale more effectively
• Align expectations and assumptions among different roles and perspectives
• Coordinate tasks and responsibilities more efficiently
• Resolve conflicts and trade-offs more objectively

If you are interested in learning more about how to use a DSM for software architecture analysis and improvement, I recommend you to explore the resources below.

References

[1] - (PDF) Applying The Design Structure Matrix To System Decomposition And Integration Problems: A Review And New Directions (researchgate.net) - 2001

[2] - (PDF) Using Dependency Models to Manage Complex Software Architecture - 2005

[3] - A more detailed exploration of the use of DSM for Improving Software Architecture

[4] - The Design Structure Matrix (DSM) (dsmweb.org)

[5] - Optimizing Processes Using a Design Structure Matrix | Kevin Sookocheff, which explains how to use a DSM to analyze and improve the architecture of a Python project

[6] - Managing in the age of Modularity, which explores how the original developers of the IBM System/360 embraced the principle of modularity in design, and caring for what is visible and what is hidden in the design of the system.

[7] - Design structure matrix - Wikipedia