dsm

Mastering Complexity

Mastering Complexity is a new Dependency Structure Matrix (DSM) book by Stephen Denker. Steve is a management consultant who has worked with DSMs for many decades and his vast experience is reflected in the book.

This is easily one of the most approachable books that I have come across. The early chapters were easy to read, well-illustrated, and explained the concepts well. However, what comes as a surprise was when the simple concepts of the early chapters give way to much deeper material. The book covers advanced concepts such as reducing cycle time, scheduling reviews, risk management, partitioning and tearing. In keeping with the philosophy of the earlier chapters, these sections are also covered in a concise manner. In fact, they are so concise that you would be advised to read some of the chapters in conjunction with the original research they are based on; otherwise, you might feel short-changed by some of the later chapters.

For me, the most interesting aspects of the book are the links to practice. One of my favorite sections is the chapter on reviews. It shows very simply how the ordering of coupled activities ties into review tasks. I also found the sections that show organizational coupling based on tasks to be quite revealing. One of the later chapters even has an analysis of inner-city crime and violence using DSMs to identify the control dependencies - a nice example of the out-of-the-box thinking that is enabled by DSMs.

“Mastering Complexity” is a welcome addition to the swelling roster of DSM books. Without question, systems are becoming far more complex these days. They are becoming more varied with interactions that involve a large number of tasks, people, and other elements. Today, there is an urgent need to document current approaches and to push on the frontier of new approaches for managing complexity. Denker’s book is a fine start for that process.

Analyzing ArgoUML

Johan van den Muijsenberg just published (in Dutch) his analysis of ArgoUML in a magazine published by the Java User Group in Netherlands. The brilliance of Johan's analysis is in how logically straightforward it is and how that analysis yields clearly identifiable architectural issues and fixes. It is yet another example of how easily architecture erodes from its intended design. If more teams were to focus on fixing "bugs" in architecture, they would reap rich dividends in improved quality and productivity.

My main complaint is why Dutch readers should be the only ones to benefit from this interesting and useful article. Here is a Google translation into English.

What Star Trek Can Teach Us About Software Architecture

What Star Trek Can Teach Us About Software Architecture

The writers of Star Trek Voyager envisioned a game that was worthy of challenging the superior mind and intellect of a Vulcan. They called it Kal-toh. To the human eye, Kal-toh looks to be a high-tech fusion of Jenga and chess. Lieutenant Tuvok of the starship Voyager would be quick to tell you "Kal-toh is to chess as chess is to tic-tac-toe.”

In Kal-toh, the players are presented with rod like game pieces that are in total chaos. This could be compared to legacy code with no discernable architecture or documentation – spaghetti code or a big ball of mud. The object of Kal-toh is to move the pieces (systems and subsystems) until a perfect structure or architecture is formed. The challenge in Kal-toh, as in Software Architecture Design, is that if you move the wrong piece, the entire structure can collapse.

Kal-toh and Software Architecture are based on very similar principles. An experienced Kal-toh player has the ability to visualize the complexity in the Kal-toh puzzle. Without fully understanding how the Kal-toh pieces interact with each other there is no road map to create stability in the structure.

Visualizing software systems is hard because there are a very large number of elements with dependencies on each other. Therefore, the ability to scale is critical. Furthermore, the purpose of visualization is to reveal the architecture. This means that it is important to not just draw the dependencies but to show where dependencies are missing and to highlight the problematic dependencies.

Lattix has pioneered an award winning approach for large scale visualization based on a Dependency Structure Matrix (DSM). Lattix incorporates hierarchy in the display, while showing the architectural decomposition and the dependencies at the same time. Built-in algorithms help discover architecture. What-if capabilities allow users to modify the current structure to reflect the desired architecture. Users get a big picture view while still identifying problematic dependencies. Lattix also provides an intuitive Conceptual Architecture diagram that takes some of the lessons of a DSM and makes them accessible to a wider audience.

Let me leave you with a Star Trek quote. Lieutenant Tuvok said “Kal-toh is not about striving for balance. It is about finding the seeds of order, even in the midst of profound chaos." The same can be said about Lattix.

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.