A semi-automated framework for the identification and estimation of Architectural Technical Debt: A comparative case-study on the modularization of a software component

Context Research and industry\u27s attention has been focusing on developing systems that enable fast time to market in the short term, but would assure a sustainable delivery of business value and maintenance operations in the long run. A related phenomenon has been identified in Architectural Technical Debt: if the system architecture is sub-optimal for long-term business goals, it might need to be refactored. A key property of the system assuring long-term goals is its modularity, or else the degree to which components are decoupled: such property allows the product to be evolved without costly changes pervading the whole system. However, understanding the business benefits of refactoring to achieve modularity is not trivial, especially for large refactorings involving substantial architectural changes. Objective The aim of this study was to develop a technique to identify Architectural Technical Debt in the form of a non-modularized component and to quantify the convenience of its repayment. Method We have conducted a single, embedded case study in a large company, comparing a component before and after it was refactored to achieve modularity. We have developed a holistic framework for the semi-automated identification and estimation of Architectural Technical Debt in the form of non-modularized components. We then evaluate the technique reporting a comparative study of the difference in maintenance and development costs in two coexisting systems, one including the refactored component and one including the non-refactored one. Results The main contributions are a measurement system for the identification of the Architectural Technical Debt according to the stakeholders’ goals, a mathematical relationship for calculating and quantifying its interest in terms of extra-effort spent in additional development and maintenance, and an overall decision framework to assess the benefit of refactoring. We also report context-specific results that show the estimated benefits of refactoring the specific case of Architectural Technical Debt. Conclusion We found that it is possible to identify this kind of Architectural Technical Debt and to quantify its repayment convenience. Thanks to the developed framework, it was possible to estimate that the Architectural Technical Debt present in the component was causing substantial continuous extra-effort, and that the modularization would be repaid in several months of development and maintenance