Software systems undergo constant change causing the architecture of the system to degenerate over time. Redirecting development effort toward reversing system degeneration takes extra effort and delays the release of the next version. The value of an improved architecture is clear to technical staff, but it is often difficult to convince upper management that the extra effort is necessary. Improved architecture is intangible and does not translate into visible user features that can be marketed. Due to a lack of representative metrics, technical staff has problems arguing that stopping degeneration is indeed necessary and that the effort will result in an improved architecture that will pay off. We believe that architectural metrics would give technical staff better tools to argue their case. This paper defines and uses a set of architectural metrics and outlines a process for analyzing architecture to support such an argument.

The paper reports on a case study from a project where we restructured the architecture of an existing client-server system written in Java while adding new functionality. The modules of the existing version of the system were "library-oriented" and had a disorganized communication structure. The new architecture is based on components and utilizes the mediator design pattern. The goal of the study is to evaluate the new architecture from a maintainability perspective. The paper describes our evaluation process, the metrics used, and provides some preliminary results. The architectural evaluation shows that the components of the system are only loosely coupled to each other and that an architectural improvement has occurred from a maintenance perspective. The process used to evaluate the architecture is general and can be reused in other contexts.