Design Rules to Manage Software Architecture

In Design Rules, The Power of Modularity, Carliss Y. Baldwin and Kim B. Clark argue the computer hardware industry has grown so quickly because of modularity, the building of complex products by breaking the functionality into smaller subsystems that are designed to work independently yet can be used as building blocks to create a whole product. The key to this modularity is the use of design rules that must be followed and that allow designers (and software developers) to creatively solve complex problems. Design rules are also key to the computer software industry.

What are design rules?

Design rules are a way to specify the allowed nature of the relationship between various subsystems. Design rules have two purposes:

Flag architectural errors that erode the architecture over time

Capture critical changes to the architecture that might necessitate further changes to the system as a whole or to how subsystems interact with each other

There are many benefits to design rules. Design rules are an easy way for the software architecture to be communicated to the entire development team. With clearly defined design rules, new developers can come up to speed quickly on how the software is supposed to work and how they should structure their code. When design rules are monitored, tight scheduling does not erode the architecture and, if it does, the consequences of time pressure can be tracked (architectural technical debt) and monitored.

Design rules make managing large, complex software systems easier because there are clear rules on how different elements can and cannot interact. Distributed teams (outsourcing, offshoring) can be counted on to produce higher quality code because they have rules to follow. Without design rules, it is impossible to manage the long-term health and maintainability of the software.

Consequences of not implementing design rules

Software architecture degrades over time with successive revisions. This is typically called architecture erosion. This happens because of the development team’s inability to communicate and enforce architectural intent in the software, i.e. not implementing design rules. Without clear rules, developers can and will change the software with unintended consequences.

Architecture erosion also leads to maintainability issues. Bad dependencies are introduced which leads to code that is hard to understand and change. This is typically referred to as brittle code. Some of the other consequences of a lack of design rules include lower reliability, less modularity, lower performance, and lower interoperability. Design rules give actionable insight into violations of the intended architecture that are a consequence of normal development.

How to implement design rules

The first step is finding an easy way to communicate the architecture to the entire team. Architecture diagrams communicate important aspects of the model. We recommend using a mixture of the dependency structure matrix (DSM, below left) and conceptual architecture diagrams (CAD, below right). The DSM is a simple, compact, and visual representation of a system or project in the form of a square matrix. This is a good way of getting an understanding of the the entire software project in one view. DSMs are also a powerful way of setting and visualizing design rules. They make it easy to pinpoint violations to design rules. The CAD is a good way of looking at a smaller, more manageable subsystems because it is a simple diagram which is easily understood by managers, users, and business stakeholders.

Once you understand your architecture, you need a way to enforce it with build-time checking and reporting. Here’s a white paper on how Lattix does this: “The Lattix Approach: Design Rules to Manage Software Architecture”.When you are creating design rules, the things that you want to enforce are: Placement of UI, business, and data logic

Use of infrastructure or util modules

Design standards

Layered architecture You need a process to evolve (update) the architecture when required. Sometimes you will be adjusting the architecture ahead of development and sometimes you will be changing the architecture during development as new information becomes available.

Conclusion

The goal of using design rules to manage software architecture is to keep the code clean and consistent. This will allow you to keep maintenance costs down over the entire lifecycle of the product. This is especially important because, as the product evolves, new team members will be introduced and new business requirements will be needed that were not thought of in the original architecture. With design rules, this product evolution can be handled efficiently. If you are interested in trying out the “Lattix Approach” to design rules, sign up for a trial.