Architectural Technical Debt Identification based on Architecture Decisions and Change Scenarios Zengyang Li Department of Mathematics and Computing Science University of Groningen Groningen, The Netherlands zengyangli@gmail.com Peng Liang State Key Lab of Software Engineering, School of Computer Wuhan University Wuhan, China liangp@whu.edu.cn Paris Avgeriou Department of Mathematics and Computing Science University of Groningen Groningen, The Netherlands paris@cs.rug.nl Abstract 1 —Architectural technical debt (ATD) is incurred by design decisions that intentionally or unintentionally compromise system-wide quality attributes, particularly maintainability and evolvability. ATD is harmful to the system’s long-term health, thus it needs to be identified for further management. However, existing ATD identification approaches are mainly based on source code analysis and thus suffer from certain shortcomings: they can only identify issues at the system implementation; they can only be employed after the systems is implemented in code; they lack a mechanism to confirm whether the potential ATD identified is real ATD or not. To address these issues, we proposed an ATD identification approach based on architecture decisions and change scenarios. To evaluate the effectiveness and usability of this approach, we conducted a case study with an information system in a large telecommunications company. The results show that the proposed approach is useful and easy to use, and it supports release planning and ATD interest measurement. Keywords—Architectural technical debt, architectural technical debt identification, architecture decision, change scenario I. INTRODUCTION Architectural technical debt (ATD) is caused by architecture decisions (ADs) that consciously or unconsciously compromise system-wide quality attributes (QAs), especially maintainability and evolvability [1]. Typical ATD includes violations of best practices, consistency, and integrity of software architectures (SAs), such as breaking the principles of architectural patterns and introducing architecture smells (e.g., package dependency cycles). ATD needs to be well managed in order to maintain the long-term health of the system [1, 2]. If left unmanaged, the ATD will accumulate interest incrementally, potentially causing risks: making it challenging to conduct maintenance tasks, introduce new features, as well as meet system QAs, etc. The first step in an ATD management (ATDM) process is to identify the existing ATD in the software system [1]. ATD identification detects the locations of the ATD in the system, and identifies the causes of the ATD, the compromised QAs, and the impact on future development [1, 3, 4]. In our recent 1 This work is partially supported by AFR grant No. 895528, and NSFC grants No. 61170025 and 61472286. Thank the participants of the case study, as well as Christian Manteuffel and Daniel Feitosa for reviewing an early version of this paper. mapping study on technical debt [3], we found that existing approaches on identifying ATD are mainly based on source code analysis. However, such ATD identification approaches can only identify, as expected, source code-related issues, e.g., modularity violations. They cannot identify ATD caused by ADs that are not reflected in the code, such as inappropriate, immature or obsolete technologies used, and architecture nonconformance. Furthermore, those ATD identification approaches can only be applied after the system is implemented, which may lead to significant rework in order to repay the ATD. Finally, the source code analysis-based approaches can only provide indicators for ATD, i.e., identify the location of potential ATD, but provide no means to confirm whether it is actual ATD or not. To overcome the shortcomings of source code analysis- based ATD identification approaches, we propose to identify ATD based on ADs made during the architecting process and change scenarios for software maintenance and evolution. An AD is a design decision that affects the architecture design space for a target software system [5]. A change scenario is a maintenance or evolution task to be performed in the software system. The proposed approach takes ADs and change scenarios as input, and then comes up with ATD items that are caused by the ADs or negatively impact the change scenarios. To validate our proposed approach, we conducted an industrial case study which evaluates the effectiveness and usability of identifying ATD using this approach. The results show that the approach is useful and easy to use, and it supports release planning and ATD interest measurement. The rest of this paper is organized as follows. Section II discusses related work regarding ATD identification, while Section III and IV present, respectively, the proposed approach and its evaluation through a case study in an industrial environment. The results of the case study are discussed in Section V, followed by the conclusions of this work and discussion of future work in Section VI. II. RELATED WORK Not much work has been done on ATD identification according to our recent mapping study on technical debt [3]. Existing research focuses on identifying ATD based on source code analysis. In [6, 7], Curtis et al. used a tool (CAST's Software's Applications Intelligence Platform) to detect highly