Book: Design Structure Matrix Methods and Applications

There is a major new book out: Design Structure Matrix Methods and Applications. The authors, Steven D. Eppinger and Tyson R. Browning, may not be household names, but they are rock stars in the world of DSMs. This book contains a clear and lucid introduction to DSMs. However, what makes this book so compelling is its rich collection of examples.

The book contains 44 real world examples as varied as NASA's Mars Pathfinder, BP’s LNG Terminal, LLBean’s Software Code Base, or Luftfahrt’s Airport Security System. These examples drive home the generality and simplicity of DSMs. I am also proud to note that the LLBean analysis was done using Lattix tools.

The book groups these examples into 4 categories:

  • Product Architecture
  • Organization Architecture
  • Process Architecture
  • Multidomain Architecture

While the first three applications have existed for some time, the application of DSMs to link and analyze multiple domains is relatively new. This is a natural progression; and, it raises interesting new possibilities. For instance, we know that different stake holders have different ways of looking at the architecture of a complex system. We often choose to think of them as separate views. Yet, these views are related. Can a system be designed without the designer being cognizant of how it will be deployed? The multi-domain DSMs may provide an effective mechanism to capture those relationships.

How good are our Mental Models?

I spent many years working with UML models in the 1990s. At that time, the hope was that software development, centered on a model, was the future of programming. It was thought that model and code were simply two views of the same system and that they could be kept synchronized. The actual progress of software development practices hasn't quite worked out this way. However, there are places where model driven development has been successful. And, there are modeling tools such as Rhapsody that are development environments for creating a complete application.

Most people think that Lattix is great for code; many know that it works with frameworks and database; however, only a few (including Peter Varhol) know that Lattix also allows you to work with UML models. Since UML is already a rich visual modeling language why would you want to look at UML models from within Lattix?

Just like code, large UML models are created by teams of developers; and, just like code, they can be hard to understand and maintain. Lattix allows me to capture the big picture view of these models, identify undesirable couplings, create new structure and measure the new model – all in a short time.

Furthermore, what is interesting about a UML model is that it frequently includes additional artifacts such as use case diagrams, sequence diagrams, requirements etc. Many of these abstractions reflect our mental model, but since many of them do not relate directly to code elements, we never really get to see how well defined they are.

This is a DSM for of a Rhapsody model that has been around for a long time. The coupling issues become readily apparent when you see it in Lattix.

Some could legitimately argue that if our mental model is not what is implemented then we shouldn’t really care. This is largely true – but the model that is expressed in UML is actually created for the purpose of development and has a strong influence on what is actually implemented. A sequence diagram may just be a picture initially but could end up as a specification for an implementation.

Having looked at hundreds of UML models, I must conclude that even if the code was an accurate reflection of our UML model, we would still have many of the same problems that we have today with software development.