Software architecture erosion refers to the gap between the planned and actual architecture of a software system as observed in its implementation.1
Architecture erosion is a common and recurring problem faced by many agile development teams. Architecture erosion can result in lower quality, increased complexity, and harder-to-maintain software. At the beginning of a project, the source code is small and has limited dependencies. As the software grows, more dependencies between files and functions are added. This increases the impact of changing the code. As these changes happen, it becomes more and more difficult to understand the originally planned software architecture. This is particularly important in an agile environment where, according to the Agile Manifesto, working software is valued over comprehensive documentation, and responding to change is valued over following a plan. In reality, this means that the architecture is evolving as the software is evolving. Therefore, software changes need special attention (architectural assessment) from software architects. If this does not happen, the architecture could erode or become overly complex. Uncontrolled growth of a software system can lead to architectural issues that are difficult and expensive to fix.
Unfortunately, the process of solving this problem is usually ad hoc or very manual, without adequate visibility at the architecture level. One effective solution is the reflexion model technique. The technique is a lightweight way of comparing high-level architecture models with the actual source code implementation while also specifying and checking architectural constraints. The diagram below is an example of the reflexion model technique.
How to avoid architectural erosion
Architecture erosion can be avoided or corrected by continuously monitoring and improving the software. Continuous checking of the implemented architecture against the intended architecture is a good strategy for detecting software erosion. Once architectural issues have been found, refactoring should be used to fix them. In an agile environment, you should combine development activities with lightweight continuous architectural improvement to avoid or reverse architecture erosion. The process of continuous architectural improvement can be broken down into four steps:
- Architecture assessment
- Identify architectural smells and design problems
- Create a list of identified architectural issues
- Prioritization
- Decide the order in which the architectural issues will be tackled starting with strategic design issues or high-importance requirements first
- Selection
- Choose the appropriate refactoring pattern to fix the issue. If none exist create your own.
- Test
- Make sure the behaviors of the system did not change
- Update the architecture assessment to make sure you fixed the design problems and did not introduce new issues. Watch the Lattix Update Feature video for more information on this step.
This is particularly useful in agile development. In a scrum environment, architecture refactoring should be integrated into sprints by including time for refactoring both code and architecture. During the sprint, architects need to check their architecture, while testers and product owners should validate the system still meets requirements. Architecture refactoring should be done once during a sprint as opposed to code refactoring, which should be done daily. If it is done less often, fixing architectural issues involves more time and complexity as more code changes are added on top of design issues. If done more often, the architecture could change needlessly and add to software complexity. Architectural problems not solved in a current sprint should be saved and maintained in a backlog.
Summary
Architecture erosion can happen in any software project where the architectural assessments are not part of the development process. Architectural refactoring makes sure wrong or inappropriate decisions can be detected and eliminated early. One of the principles of agile development is “maintain simplicity.” Focus on simplicity in both the software being developed and in the development process. Whenever possible, actively work to eliminate complexity from the system. A clean architecture eliminates complexity from the software while a lightweight, reflexion technique-compliant tool like Lattix Architect makes the process of continuous architecture improvement simple.
