How do you measure the “architectural health” of a software project?
Since every software project is different, it is hard to come up with a single number that represents the architectural health of an entire project. Lattix Architect, therefore, provides a variety of architectural metrics. These metrics were chosen based on academic research on system architecture as well as the practical experience of the Lattix development team. We will look at one of these architecture metrics today: system stability.
Architectural metrics are different from traditional code metrics (i.e. bugs per line of code, cyclomatic complexity, etc.) that focus on understanding the quality and complexity of sections of code. Architectural metrics focus on the big picture (the system as a whole) and examine its organizational structure.
What is system stability?
System stability measures how sensitive the system is to change. When a change is made to the software, system stability will tell you how much of the rest of the software will be affected. In software with a layered architecture, the lowest layers tend to have the lowest system stability because any change to them affects the layers above. Therefore, the lower layers need much more testing.
Lower stability means the software is harder to maintain because every change affects a greater amount of the system and therefore requires more testing and validation. This is why less stable software tends to break easily (fragile) when even small changes are made. High stability means there is less change impact, so changes are localized. We consider this robust software. Also, because there are fewer unexpected consequences when making a change, developers have an easier time understanding the software.
How is it calculated?
System stability is measured by analyzing the impact of change in a software system for every element of the system. The overall stability number is the average stability number from all of the elements. The dependency information for every element is examined. Then the number of elements that are potentially affected (dependencies) when an element is changed is calculated. This is done through to transitive closure.
If the system stability is 70%, this means that 30% of the elements on average are affected when any element is changed and 70% are unaffected. Stability is computed as a percentage of the size of the system, so it doesn’t necessarily change simply because the software project gets larger or smaller.
How can you use it? And why?
The architecture of a software system has a profound impact on its stability. Therefore, by monitoring system stability you can measure the quality of your architecture. System stability can also be used to focus your testing efforts. As an example, if we create a set of applications on a common framework (see picture below) and then change the framework, we will affect all of the applications.
If we change just an application then the impact will be much lower. Therefore, it is essential to understand not just the stability of the entire system, but understand where the stability is coming from.
In the picture above, the total stability of Project is about 62%, but the Apps layer has a stability of 73%, while Frameworks and Util have lower stability. This means the Frameworks and Util layers have more dependencies on other components, which means that changes to these components have a much larger impact and a need for focused testing (i.e. changes to these layers are riskier).
There is also value in tracking the stability of the software over time.
We have talked in previous blog posts about architecture erosion and how that leads to software that is harder to maintain. The system stability metric gives you measurable and actionable insight into this phenomenon. If the stability goes down over time as in the picture above, there needs to be a corresponding increase in testing and verification.
Conclusion
System stability tends to decrease over time if not monitored. Every change to the software can erode the architecture and therefore the stability. This means the software becomes harder to maintain over time, resulting in longer testing cycles and reduced developer productivity.
Monitoring stability can help you maintain a clean and modular architecture. Lattix products makes architecture management part of your continuous integration and makes architecture management easy and actionable in your development lifecycle.
