Lightweight Prevention of Architectural Erosion Ciaran O’Reilly, Philip Morrow, and David Bustard School of Computing and Information Engineering University of Ulster Coleraine BT52 1SA, Northern Ireland {c.oreilly, pj.morrow, dw.bustard}@ulster.ac.uk Abstract Avoiding architectural erosion helps extend the lifetime of an evolving software system. Erosion can be reduced by ensuring that (i) developers share a good understanding of a system’s architecture; (ii) alignment is preserved between the architectural description and its implementation at all stages of system construction and maintenance; and (iii) architectural changes are treated with the same care and attention as the production of the initial design. Through the metaphor of ‘agile development’ this paper presents a lightweight approach to the control of architectural ero- sion. In particular, it covers the representation of an ar- chitectural description and the management of alignment between description and implementation during system evo- lution. A prototype support tool, ArchAngel, is introduced. This maintains an architectural design description, identi- fies when changes occur with respect to that description, and reports these changes for evaluation. 1 Introduction Architectural erosion (or drift) is here taken to mean any detrimental deviation over time of a software system’s ar- chitecture from its original design conception. This cov- ers any mismatch between design and implementation and any change to an architecture that results in a loss of de- sign quality. The assessment of quality is assumed to be a consensus view of the adequacy of an architectural descrip- tion, based on general criteria, such as conceptual clarity, interface simplicity, and the extent of component reuse. Architectural erosion can occur during initial system de- velopment or in subsequent maintenance. To clarify the na- ture of the erosion problem and so help explore how it might be avoided, consider the following development scenario. Scenario: A software architect creates and documents a high-level system design from an understanding of system requirements. That design is communicated to a group of software engineers responsible for its implementation. Dur- ing implementation, the engineers extend the design with lower level structure. Their work also explores the system requirements and architectural design in more detail, and in doing so identifies architectural errors and improvements. These are reported to the software architect for evaluation. Approved changes are notified to all developers who may be affected. Later, in the maintenance phase of the sys- tem, change requests are processed. These will involve sys- tem changes across requirements, architectural design, de- tailed design and code. If there are parallel changes, the software engineers are kept informed of modifications that affect them. The software architect again oversees architec- tural changes. With respect to this scenario, architectural erosion can occur if: 1. The software engineers have a way of violating the design description—knowingly or inadvertently— without detection. This creates a mismatch be- tween the implementation and the design description, severely undermining the value of the description. 2. Changes are made to a design description without sufficient appreciation or consideration of the conse- quences. This can compromise the integrity of the de- sign, weakening the resulting implementation. An ex- perienced software architect should be responsible for making (or approving) all design changes. 3. There is a delay in detecting and/or reporting design violations to the engineers at fault. This means that they may waste time on implementation work that has to be changed subsequently. Note that software engi- neers typically use workspaces during development so, to avoid delay, workspace activity must be monitored. Proceedings of the Sixth International Workshop on Principles of Software Evolution (IWPSE’03) 0-7695-1903-2/02 $17.00 © 2002 IEEE