ArticlePDF Available

Abstract and Figures

Large Software Companies need to support the continuous and fast delivery of customer value in both the short and long term. However, this can be impeded if the evolution and maintenance of existing systems is hampered by what has been recently termed Technical Debt (TD). Specifically, Architectural TD has received increased attention in the last few years due to its significant impact on system success and, left unchecked, it can cause expensive repercussions. It is therefore important to understand the underlying factors of architectural TD. With this as background, there is a need for a descriptive model to illustrate and explain different architectural TD issues. The aim of this study is to synthesize and compile research efforts with the goal of creating new knowledge with a specific interest in the architectural TD field. The contribution of this paper is the presentation of a novel descriptive model, providing a comprehensive interpretation of the architectural TD phenomenon. This model categorizes the main characteristics of architectural TD and reveals their relations. The results show that, by using this model, different stakeholders could increase the system’s success rate, and lower the rate of negative consequences, by raising awareness about architectural TD.
Content may be subject to copyright.
A systematic literature review and a unified model of
Terese Besker
Computer Science and Engineering,
Software Engineering
Chalmers University of Technology
Göteborg, Sweden
Antonio Martini
Computer Science and Engineering,
Software Engineering
Chalmers University of Technology
Göteborg, Sweden
Jan Bosch
Computer Science and Engineering,
Software Engineering
Chalmers University of Technology
Göteborg, Sweden
Abstract Fast software deliveries are hindered by high
maintenance efforts due to internal quality issues and Technical
Debt (TD) and specifically, Architectural Technical Debt (ATD)
has received increased attention in the last few years. ATD has a
significant influence and impact on system success and, left
unchecked, it can cause expensive repercussions; it is, therefore,
of maintenance and evolutionary importance to understand the
basic underlying factors of ATD. Thus, with this as background,
there is a need for a descriptive model to illustrate and explain the
different ATD issues. The aim of this study is to synthesize and
compile research efforts with the goal of creating new knowledge
with a specific interest in the ATD field. The contribution of this
paper is the presentation of a novel descriptive model, providing a
comprehensive interpretation of the ATD phenomenon. This
model categorizes the main characteristics of ATD and reveals
their corresponding relations. The model is based on a systematic
literature review (SLR) of currently recognized knowledge
concerning ATD.
Keywords Systematic literature review; Architectural
Technical Debt; Software Maintenance; Software Architecture
Large scale software companies strive to increase their
efficiency in each life-cycle phase, by reducing time and
resources deployed by the development teams. To achieve this
goal of delivering high-quality systems, the software
architecture is essentially important, and should contribute to a
minimal maintenance effort. Van Vliet [1] states that
maintenance activities consume 50-70% of the total effort spent
during a typical software project. Left unchecked, these
maintenance activities can make the architecture diverging
towards a suboptimal state, and possibly towards system
obsolescence or failure.
Ward Cunningham [2] introduced the financial metaphor of
Technical Debt (TD) to describe the need for recognizing the
potential long-term and far-reaching negative effects of
immature code, made during the software development life-
cycle, which has to be repaid with interests in the long term.
The reason for taking on TD can be described as an
unintentional consequence of accumulations of decision over
natural software aging in
order to get new functionality running quickly.
During development of large scale systems, software
architecture plays a significant important role [3] and
consequently a vital part of the overall TD relates to sub-
optimal architectural decisions and is regarded as Architecture
Technical Debt (ATD) [4]. ATD is primarily incurred by
architectural decisions with the consequence of immature
architectural artifacts. ATD commonly refers to violations of
best practices [5], or consistency and integrity constraints of the
architectures, or implementation of immature architecture
This study focuses on different ATD categories, and their
related effects, and thereby, become highly relevant when
providing a platform for analyzing different architectural
management strategies, solutions, and challenges. So far, we
have not found any studies describing this issue in a unified
way, which could facilitate the challenges of understanding and
manage ATD in an overall context. To explore and understand
these concerns in a more comprehensive context, a systematic
literature review is conducted in the area of ATD with research
questions focusing on the current knowledge regarding debt,
interest, principal and existing challenges, and solutions in
managing ATD.
The main contribution of this paper consists of two parts:
First, it shows that there is not one unified, and overarching
description or interpretation for ATD and, therefore, -of-
the- review of significant issues is provided, concerning
various ATD issues.
The second contribution of this article is a novel descriptive
model that provides an overall understanding concerning
knowledge currently of interest in the research area of ATD.
The objective of this study has been achieved through
employing a thorough Systematic Literature Review research
method (SLR) [6].
The remainder of this paper is structured in seven sections,
where the first section is a brief introduction and incentive for
this paper. The second section introduces background
information that is used during a discussion of the results. In the
third section, the research method is described. The fourth
section presents the result that is discussed in section five.
Finally, in section six, threats to validity are presented, and the
last section, seven, concludes the paper.
In order to provide the reader with necessary information
that is needed to better understand the remainder of the paper,
this section provides a background
to the ATD domain. In this
broad view, we examine what constitutes ATD (debt, interest,
and principal) and how it is managed (management processes,
current challenges and analyzing support). This section also
describes related work in the research area of ATD.
A. Background
ATD is a metaphor representing architectural technical
issues, including the corresponding financial term debt, interest,
and principal.
Interest is the most commonly used financial glossary used
in TD research and Ampatzoglou et al. [7] define interest as:
The additional effort that is needed to be spent on maintaining
the software, because of its decayed design-time quality.
Interest is the negative effect of the extra effort that has to be
paid, due to the accumulated amount of debt in the system, such
as executing manual processes that potentially could be
automated or excessive effort spent on modifying unnecessarily
complex code, performance problems due to lower resource
usage by inefficient code [8], [9].
The principal is the cost of remediating planned software
violations concerning TD. The aggregate of the principal can be
computed as a combination of the number of violations, the
hours to correct each violation, and the cost of labor [10].
The objectives of different software management activities
performed during the ATD Management (ATDM) process
include several different activities such as identification,
measurement, prioritization, repayment, and monitoring [11].
Despite the significant need for supporting tools and
methods for analyzing ATD, most of the available tools for
analyzing TD focus on code level instead of architectural
aspects [12]. These code focusing tools usually cannot provide
indicative for architectural trade-off since they can cause
misleading results [13].
One of the most challenging tasks encountered in the
synthesis of ATD, is how to translate architectural
complications or debt into economic consequences, in means of
predicting financial implications based on estimated values. A
second key challenge is an estimation that arrives at a strict
probability without evidence-based historical data that can
provide an accurate estimate at the outset.
B. Related work
Architecture plays a significant role in the development of
large software systems and despite that ATD is commonly
recognized as a major dimension of TD [8], there are no
literature reviews, summarizing the research state of the art on
the architectural aspect of TD, to the best of our knowledge. By
studying the type of available literature reviews, four reviews
(written in English) were found within the shared research area
as this study. These studies differ, however, on the research
questions, method, searching interval and primary focus, and
the studies have different research goals. The most recent study
was a systematic mapping review performed by Alves et al.
[14], focusing, among other things, different types and useful
indicators for detecting TD. Another significant related work in
this research area is conducted by Ampatzoglou et al. [7] based
on a comprehensive, systematic literature review with a primary
focus on financial aspects of managing TD. This review also
comprises a formation of a glossary of terms and a
management. Li et
al. [15] published recently a mapping study (MS) with the
primary focus on and thematic analysis
on collected studies within the TD and TD management area.
Finally, Tom et al. [8] published in 2013 a multivocal literature
review (MLR) with the focus on the nature of TD and its
implications for software development.
The following section describes the method used for
conducting this SLR.
C. Systematic literature review method
The review procedure is based on guidelines by an
established SLR method, described by Kitchenham [16]. The
main rationale for undertaking a systematic review is to
synthesize existing work, and that the review should be carried
out in accordance with a predefined search strategy, which
allows the search to be evaluated. The major advantage of using
this method is that the result is provided by evidence, which is
robust and transferable and that sources of variation can be
studied further [16]. The method includes a review protocol
(Fig. 1), which involves the phases: a) define research
questions, b) define search process, c) define inclusion and
exclusion criteria, d) define quality assessments, e) define data
collection, f) define data analysis, and g) define deviations from
Fig. 1. Visualization of the overall review protocol
D. Research question
As mentioned in Section I, the goal of this review is to gain
further knowledge on ATD regarding its constituents (principal,
interest and debt) and its management (challenges and
solutions). We, therefore, define the following two main
Research Questions (RQs) and related six sub-questions. Each
sub-question is related to an aspect of ATD, defined in Section
RQ1: What is the existing knowledge concerning ATD in
terms of debt, interest and principal?
RQ1.1: What are the categories of ATD?
RQ1.2: What are the major negative effects caused by
RQ1.3: What refactoring strategies are mentioned for
managing ATD?
RQ2: What are the existing challenges and solutions for
managing ATD?
RQ2.1: Which ATDM activities are mentioned?
RQ2.2: Are there any specific challenges with ATD?
RQ2.3: Are there any analysis methods for detecting
and/or evaluating ATD?
The first sub-question RQ1.1 focuses on different
categories of ATD that will provide information about how
debt is described in the publications. Studying, the outlined
positive and negative effects caused by ATD in RQ1.2 will
provide an understanding of the effects related to different
quality attributes (QA), which will be synthesized as interest.
Question RQ1.3 focus on the refactoring strategies revealed in
publications, and this will be linked to the principal. The result
obtained from studying which different ATD Management
activities that are stated in the reviewed publication by
utilization of results of RQ2.1 will answer which activities are
used as notions in the publications. RQ2.2 focus on different
kinds of challenges to the management of ATD, and RQ2.3
concentrates on supporting activities for detecting and
evaluating the software architecture.
E. Search process
A searching strategy process should include: (1) defining a
searching term (query), (2) defining the target for the searching
term, and (3) select different data sources with the aim of
identifying candidate publications [16].
Since is not a common
expression in the title or the abstract as a concatenated word
sequence, publications that both contain
architec* were studied.
The search term (query) contains the following keywords:
The searching terms were combined using a Boolean AND
operator, which entails that publication needs to include both of
the terms. To catch terms and/or
, the asterisk character * is used, known as a
wildcard, to match one or more inflected form of the searching
To increase the likelihood to find publications addressing
architectural aspects of TD, the target of the searching term is
defined to search in both title and abstract.
The selection of data sources involved automatic searching
in six well-known digital libraries: the ACM Digital Library,
IEEExplore, ScienceDirect, SpringerLink, Scopus, and Web of
Additionally, in order to avoid overlooking important
publications, we performed a hand-search in all the proceedings
of a key conference on the subject: the International Workshop
on Managing Technical Debt (MTD Workshop). The search
was conducted in December 2015.
F. Inclusion and exclusion criteria
SLRs require explicit inclusion and exclusion criteria to
assess the fitness of the content in each possible primary study
with respect to the RQs.
The criteria should be based on the research questions, and
be applied after the full text have been retrieved [16]. The
inclusion and exclusion criteria that have been used in this
study are listed in Table I:
Criteria Assessment criteria
Inclusion Publication should d
context of TD.
Inclusion Publications published in journals, in conference
proceedings, book chapters, and workshop proceedings
were decided to be included.
Inclusion Only publications written in English were included.
Exclusion A publication that only mentions TD in an introductory
statement and does not fully or partly focus on its architectural
Exclusion .
Exclusion Publication where the full paper is not possible to locate.
Exclusion For conferences and workshop proceedings, publications
earlier than the year 2005 were excluded.
G. Quality assessment
To ensure that the selected publications comply with a
certain quality, all publications went through a quality
assessment process, to evaluate if they were of an adequate
standard. In order to make this assessment, each publication´s
content was evaluated using a set of questions in a checklist
(Table II), where the answers were mapped according to the
options on a ranking scale.
The questions (QA1-3) in the checklist, representing different
assessment criteria with a focus on three diverse quality
assessments pertaining the quality that needs to be considered
assessment criteria strive to appraise the quality of the
publication (QA1), quality according to the findings and
results (QA2), and relevant to an ATD aspect (QA3).
Question Assessment criteria Response
option scale
QA1 Where was the research published? Journal = 4
Conference = 3
Book = 2
Workshop =1
QA2 Did the publication provide clearly stated
Excellent = 3
Good = 2
Fair= 1
Poor = 0
QA3 Did the publication provide a valuable
contribution to the review, in terms of the
relevance of discussing ATD?
Excellent = 3
Good = 2
Fair= 1
Poor = 0
The scale of QA1 refers to a well-established standard
where the Journals are ranked as having the highest reliability,
followed by Conferences, Books, and Workshops. QA3
involves comparable requirements, which previously referred to
an exclusion criteria, but this examination focuses on scaling
the content of the remaining publications. The quality
assessment scores are a heuristic only - to be used as a guide,
where no publication is rejected on the basis of the quality
assessment output.
H. Data collection
Data was collected using the form in Table III, including
predefined Data Collection Variables. This enabled recording
and tracking of full details of each surveyed publication.
Variable Collected Information Purpose
[DC1] Author
[DC2] Title
[DC3] Year
[DC4] Venue
[DC5] Quality assessment score Data assessment
[DC6] Categories of ATD RQ1.1
[DC7] Quality attributes/negative effects RQ1.2
[DC8] Refactoring Strategies RQ1.3
[DC9] Architectural TDM activities RQ2.1
[DC10] Challenges RQ2.2
[DC11] Analysis method RQ2.3
The first data collection variables [DC1] [DC4] are
primarily due to the demographic characterization of the study.
Variable [DC5] synthesizes the quality of the publications. The
stated ATD categories in the research presented by variable
[DC6] provides information when processing RQ1.1, likewise
[DC7] reports the quality attributes and possible adverse effects
when answering RQ1.2. To scrutinize different refactoring
strategies mentioned in the research, the variable [DC8] is
added to the data collection. Finally, to answer RQ2 and its
sub-queries RQ2.1, RQ2.2 and RQ2.3 variables [DC9],
[DC10] and [DC11] with a focus on different types of
mentioned ATDM activities together with various challenges
and monitoring/detecting methods are stated.
I. Data analysis
For an exploratory data analysis, the software tool Atlas.ti is
used, allowing coding and visualization of qualitative
information. Fig. 2 shows the outcome of the analysis process,
described below: the graph is part of the overall analysis model
(not completely displayed here for space reasons).
Fig. 2. The outcome of the analysis process
First, as reported in the data collection Section (III-H), the
RQs generated DC variables (DC6-11 in Table III), which were
used as an inductive coding scheme for the high-level
categorization of the data (second level of codes in the Fig. 2).
Then the data were inductively analyzed identifying several
aspects: these aspects are visible as the bottom-level boxes in
Fig. 2. In order to explain how this critical coding step was
conducted, an example of a quotation from a paper mapped to a
novel aspect and therefore to an RQ is reported.
The quote from [17]: Not being able to detect or address
architectural decay in time incurs architecture debt that may
result in a higher penalty was coded as Time Perspective,
which is part of the challenges related to ATD management
During the analysis, we were explicitly observing cause and
effect relations between the revealed aspects, which was
introduced as relationships between the aspects. The complete
result of this process is the Unified Model in Fig. 4, where all
the aspects and their relationships are shown in a
comprehensive way.
The presentation of the results will initially focus on the
overall results concerning the retrieval of the primary
publications. Then, the result will concentrate on the selected
publications, presenting the outcome of the data collection
analysis, with respect to the investigated research questions.
A. Screening of retrieved publications
To screen out the most interesting and relevant publications
for this review, a filtering technique based on five different
stages has been used. Fig. 3 shows the filtering stages included
in the searching process and the returned number of
after each filtering stage.
Fig. 3. Stages included in the selection process.
In the first stage, all publications (n = 146) from the
different data sources, were retrieved and merged. The software
Endnote facilitates of finding and removing duplicates, which
resulted in a reduced number of publications (n = 59). Stage
three was applied after the full text was retrieved, and the
publication was checked using the inclusion and the exclusion
criteria in Table I. As a result of this action, another 33
publications were excluded. In a fourth stage, the publication
went through an assessment process, with the mission of
assessing the quality of the publication. This process did not
reduce the number of publication further; this stage serves
mainly as a ranking of the publications. During the fifth stage,
data was extracted from each of the 26 primary publications
included in this SLR, according to the predefined data
collection forms, in Table III. The examination of the selected
primary publications showed that the most predominant type is
a conference paper (88%) and only one (4%) publication was a
journal. Two chapters from two books were included, and the
most popular venue is the Managing Technical Debt Workshop.
B. Existing knowledge concerning ATD in terms of debt,
interest and principal (RQ1)
RQ1 investigates how existing knowledge defines debt,
interest, and principal, which are respectively represented by
the three following aspects: (1) categories of ATD, (2) the
negative effects caused by ATD, and (3) strategies for
refactoring ATD.
1) Categories of ATD (RQ 1.1)
Architectural choices and design decisions have a great
impact on the amount of ATD [18], [19], and can be incurred
by either explicit or implicit architecture decisions [11] and be
made either consciously or unconsciously [20]. These
decisions affect several different categories of debt, and one of
the main categories of ATD are architectural dependencies [4],
[21] including module dependencies, external dependencies,
external team dependencies [22]. Another category of ATD
involves non-uniformity of patterns and policies where an i.e.
violation of naming conventions and non-uniform design or
architectural patterns are implemented [4]. Some authors add
code related issues as ATD variables, where lack of code
documentation [22], code duplication [4] and overly complex
code [23], [24], [25] are additional reasons for the emergence
of ATD. Further, non-uniform management of integration with
subsystem and resource [4] and different architectural decay
instances [17] are also revealed as ATD categories. The lack of
implementation or test of Quality Attributes (QA) or non-
functional requirements are shown by [4] as a classification of
ATD and [26] illustrates the problems with conflicting QA
synergies as an important source of ATD.
2) Negative effects caused by ATD (RQ 1.2)
Fernández-Sánchez et al. [27] acknowledge that "interest is
the recurring cost of not eliminating a technical debt item over
some period of time" with the result of the negative effects and
adverse impact on QAs. There is wide agreement in academic
literature that some of the negative consequences of ATD can
be linked to the effect it has on maintenance complications
Not being able to detect or address architectural decay in time
incurs architecture debt that may result in a higher penalty in
terms of quality and maintainability (interest) over time [17].
Li et al. [11], [28] mention particularly the QAs maintainability
and evolvability, as immature architecture design artifacts. A
system suffering from architectural drift or erosion will
eventually develop some decay instances that negatively impact
the system life-cycle properties, such as understandability,
testability, extensibility, and reusability [17]. On the other hand,
to proactively assume that changes will happen and in advance
design for flexibility, often entails high costs and risk [27].
3) Refactoring strategies for managing ATD (RQ 1.3)
The concept of different refactoring strategies refers to, how
to (i.e. if one refactoring must be done before another [29]), and
if repaying the debt. A refactoring strategy typically involves
decisions regarding continuing paying interest or by paying the
principal by re-architecting and refactoring to reduce future
interest payments [30]. In our previous paper, by Martini and
Bosch [31], a description of a strategy with respect to
minimizing risk for a development crisis is recommended -
Partial refactoring is the best option for the maximization of
refactoring. Thorough refactoring is not realistic. Drastic
minimization of refactorings (No refactoring) leads to
development crises often in the long run. Based on economic
considerations, it could be more profitable to delay the
refactoring i.e. continue paying interest than to invest in
refactoring to manage the debt
capacity to perform the refactoring could be considered [27].
Fernández-Sánchez et al. [32] echo the notion stating, The
basic way to perform a cost-
obtained. Several authors mention this decision-making as the
main refactoring strategy and [33] reveal important aspects
during this prioritization regarding lead time, maintenance
costs, and risks. The refactoring decision making is enclosed by
the problem of that costs are concrete and immediate whereas
-term [34], and the
architects to quantify or justify [34].
C. Existing challenges and solutions in managing ATD (RQ2)
The question RQ2 is separated into three top-level
precedents, examining ATDM activities, related challenges, and
analysis method for detecting or evaluating ATD.
1) Architectural TDM activities (RQ 2.1)
Nord et al. [35] describes the importance of this process as
Development decisions, especially architectural ones, require
active management and continuous quantitative analysis, as
they incur implementation and rework cost to produce value .
To fully manage and control a complete ATDM process, Li et
al. [11] advocate the five different activities:
measurement, prioritization, repayment, and monitoring.
However, while the concept of ATDM as an overall process is
uncommonly described in the academic literature, several
authors mention or focus on individual activities within an
overarching process of ATDM. The initial activity within the
ATDM process is to identify current ATD items within the
software system [11], whereas this activity is crucial for a
forthcoming successful management process. The following
ATD measurement activity examines and estimates the cost and
benefit, including the prediction of change scenarios
influencing ATD items for interest [11]. The output of this
activity is used as an input to the prioritization activity since
prioritizing refactoring ATD items is an essential element when
balancing the short-term value delivery and the long-term
responsiveness where lead time, maintenance costs and risk are
the variables that most influence the ATD effects [36]. The
repayment activities involve refactoring, and can either be
partly or fully resolved by making new or modifying existing
architecture decisions [11] to reduce or mitigate the undesirable
effects of ATD. The monitoring activity tracks ATD changes
explicitly and consequently keeps all the ATD items of the
system under control [11]. This activity is a complex process
that endures over time, and [35] enforce that the repayment and
the monitoring activities are a quite uncommon practice where
existing techniques are lacking.
2) Challenges with ATD (RQ 2.2)
To get a rich picture and to reveal issues and risks early
[12], it is of vital importance to understand the background of
ATD problems. This highlights the need to understand the
challenges to fully manage ATD in a more conscious and
informed way. Among others, [17] discussed the challenges and
were putting the time in perspective to ATD. [22] explain that
architectural decisions take many years to evolve and are
commonly made early in the software life-cycle and it is often
invisible until very late in the life-cycle [37]. From a more
technical perspective, critical issues relate to challenges of
detection through standard testing [23] and ATD seldom yield
observable behaviors to end users [20] whereas a higher
number of dependencies decrease the comprehensibility of the
system [38]. Yet another purported emergence of ATD is
associated with architectural decision-making, where the
decisions cross every possible communication link across the
development and operations network, and loss of essential
information is practically inevitable [39].
3) Analysis method for detecting or evaluating (RQ 2.3)
Using an analysis method may facilitate the evaluation and
decision-making process, helping the prioritization of resources
and efforts concerning refactoring strategies. The need of
supporting tools for system monitoring and evaluating ATD
using accurate metrics is a key issue and is not fully supported
by any today available tools [22], [4]. The main goal of a
continuous and iterative system monitoring of ATD is to
capture and track the presence of ATD within a system [4], to
provide early warnings to detect costs and risks [35], and to
map architectural dependencies or pattern drift to decay [22].
Fig. 4. The Unified Model of ATD
Ozkaya et al. [12] state further that most available metrics
are at the code level and [35] describe that existing metrics for
system quality visibility are insufficient and unproven.
D. Importance of ATD and a need for a unified model
There is wide agreement in the reviewed academic literature
that ATD is of primary importance. Examples of such
statements include
most encountered instances of technical debt are caused by
[30], and
has such leverage within the overall development life cycle,
strategic management of architectural debt is of primary
It is observed from the result that ATD is described in a
scattered and inconsistent way. Consequently, we conclude that
to derive more value from the results concerning ATD and its
effects, a holistic model depicting different views and their
implications at hand is required. Therefore, we propose a novel
descriptive model that provides an overall understanding of
existing knowledge in the research area of ATD with the aim to
provide a comprehensive interpretation of the ATD
E. A unified model for ATD management
The model in Fig. 4 graphically illustrates and synthesize
the findings and their causal relationships. The structure of the
model is inspired by Nickerson et al. [40] who recommend that
a taxonomy of a model includes the criteria of conciseness,
inclusiveness, comprehensiveness, and extendibility. The model
furthermore, clarifies the different aspects of each research
question and assembles relationships between them. As a help
to get to deeper levels of observation, the model is divided into
the vertical groups ATD Identification Checklist, ATD
Impediments, and ATD Management and the horizontal cross-
sections representing corresponding Focus area, Research
question and Aspects. Within every aspect in Fig.4, there is a
box with a number indicating how many papers that fit into
each aspect. The references for each aspect are presented in
Table IV. This information highlights the popularity of each
categorization and contributes to the reader s knowledge base
with useful and important information when creating a platform
for understanding ATD.
scaffolding allows practitioners to more easily
leverage this study's outcome when analyzing the result derived
from the RQs. are based on the
systematic analysis of all surveyed publications, in which we
have interpreted the result into the unified model illustrated by
different types of arrows. Relationships between aspects are
illustrated by different colored arrows.
The model highlights that Maintainance and Evolvability
are vital challenges within ATD, due to all of the ATD
challenges (green dotted arrows) are related to this negative
effect, and furthermore, all of the ATD categories have an
effect on Complexity (orange dashed arrows).
V. D
This section discusses the findings and the implications for
practitioners and academia. The result from the SLR indicates
that there is an absence of a comprehensive descriptive model
of ATD in the academic literature. For the academic and
practitioner community, this descriptive model can support the
process of more informed management of the software
development life-cycle,
success rate and lower the rate of negative consequences.
Aspect Reference
Dependency violations [22],[32],[38],[34],[28],[41],[20],[33],[4],[31],[35]
Non-Uniformity of
patterns and policies
[27], [38], [11], [20], [5],[24]
Code issue [23], [32], [33], [4],[35],[24]
[31], [26], [4], [17]
Lack of mechanisms
for addressing None
[26], [4], [41]
Detection [17],[24],[25],[28],[41],[20],[21]
Time perspective [32],[28],[41],[4],[5],[31],[35]
Flexibility [27],[26],[32],[17]
Maintenance and
Innovation and system
Reliability [23],[26],[17]
ATDM Process [41],[28],[11]
Measuring [22],[24],[38],[34],[11],[41],[31]
Tracking [22],[32],[34],[11],[28],[41],[4],[31]
Evaluating [22],[34],[11],[31]
Extent none/
Timing [24],[33],[4],[5],[31],[35]
Resources [34],[31]
Cost- Benefit analysis [34],[33],[5],[31],[35],[29]
A. ATD identification checklist (RQ1.1)
The research question RQ1.1 is addressed with an ATD
identification checklist, in the form of a unified model (Fig.4).
The current description in the literature of ATD is inconsistent
and creates confusion both for practitioners and within
academia. Therefore, we provide a comprehensive checklist of
all aspects of ATD, reported in the literature. Researchers and
practitioners can use this checklist as a universal reference for
recognizing ATD. ATD can be categorized into different
categories of debt (RQ1.1): dependency violation, code related
issues, non-uniform usage of architectural policies, the lack of
handling interdependent resources and lack of addressing non-
functional requirements.
B. ATD impediments (RQ2.2 and RQ1.2)
In Fig. 4, we present all the ATD Impediments; both the
challenges related to ATD and their associated negative effects.
Researchers and practitioners can use this picture to evaluate
and understand what problems might occur while dealing with
ATD and the consequences if these challenges are left
unattended. Major challenges (RQ2.2) include difficulty in
ATD detection, challenges related to the time perspective and
unmanageable architectural complexity. Often the mentioned
complexity is related to code level (
complexity) but this metric is not related to architectural aspects
of complexity, and therefore, we stress the need for further
focus on this specific aspect.
These overall challenges can lead to severe and costly
maintenance overhead that in the long run, can diminish the
ATD can also
result in restricted flexibility, decreased reliability and
performance degradation (RQ1.2). Our findings show that
challenges and effects are currently presented in a scattered way
in literature, and, therefore, we provide a comprehensive
presentation of ATD related challenges and effects in Fig. 4.
C. ATD management (RQ2.1, RQ2.3, and RQ1.3).
Although current literature stresses the importance of
understanding ATD and its related consequences, we report the
lack of guidelines on how to manage ATD successfully in
We confirm that the generic activities recognized by [11]
apply to ATD management. However, we report a lack of an
overall process where these activities are fully integrated with
each other. At the moment, they are mostly reported as single
isolated activities. Two book chapters mention these activities
within an overall process, but there is a need for further and
stronger empirical evidence supporting a suitable and practical
solution (RQ2.1).
The findings show that there is a compelling need for
supporting tools and methods for system monitoring and
evaluating ATD, but also shows that no software tools,
covering the full spectrum of ATD are yet available (RQ2.3).
For example, [11] propose an ATD identification method, but it
is not clear to us how this method could be integrated with
other methods and tools.
A refactoring strategy for paying the principal must be
developed and implemented to successfully managing ATD and
not allowing it to grow unbounded. Practitioners do in general
lack strategies for refactoring, and, therefore, such activity
might result in an ad-hoc process where the result is inadequate.
We provide in this paper, the key dimensions that need to be
taken into consideration when defining a refactoring strategy.
Fig. 4 includes these dimensions and can assist practitioners
and researchers when creating and studying refactoring
strategies. A strategy needs to be flexible to adapt to changing
requirements and take into account resources constraints, and
forthcoming new features. An important aspect to consider
while setting up a strategy is the amount of refactoring that
should take place. If refactoring is overlooked, it can lead to a
development crisis in the long run, and there are benefits of
performing a partial refactoring (RQ1.3).
D. The unified model for ATD
As discussed earlier in the previous section, we found that
the information about ATD is currently scattered in different
publications and sometimes inconsistent. It is, therefore,
difficult for researchers and practitioners to get a clear overview
of ATD. This study provides a novel and comprehensive model
that includes all the important aspects of the ATD phenomenon
and their relationships (Fig. 4). The model will help academic
and practitioner in interpreting ATD, recognizing its issues and
understanding how to manage it.
The model presents different aspects of ATD and their
relationships: this helps the practitioners in understanding how
the aspects impact each other and assists the researchers in
studying the connecting aspects together. For example, the
orange dashed arrows in the model show that all revealed
categories of ATD have a relation to the aspect of Complexity
meaning that all instances of ATD increase the needed effort
for software and system engineers to understand and manage
the system interfaces and interconnections.
The green dotted arrows in the model show that all the
Challenges of ATD have effects on system Maintenance and
Evolvability meaning that every ATD item will have a negative
impact on Maintenance and Evolvability.
E. Roadmap for future research on ATD
This roadmap provides clear targets for future research and
concludes that future research roadmap should focus on:
The findings show that there is a compelling need for
supporting tools and methods for system monitoring and
evaluating ATD. There is also a need for more studies
about efficient refactoring strategies, taking different
aspects into consideration.
This result underlines the lack of guidelines on
how to manage ATD successfully in practice, which
needs to be addressed in future research.
The indication of how many papers are fitting each
aspect clearly shows which area that is covered by
research and what aspects that need more investigation.
The result of this SLR may be affected by some threats to
validity, such as:
A. Number of retrieved publications
A relatively limited number of publications were retrieved,
with the logical consequences of that, the result of this review
had limited publications to derive results from. This result could
potentially have introduced subjective conclusions into the
analysis or incorrect or missing relationships into the results.
B. Search string
During the search process, publications that did not include
both the searching terms architec* in the
title or abstract of the publication was excluded from the
review. This could imply that some publications could have
been incorrectly excluded. We reason, nevertheless, that if a
publication should mainly focus on the architectural aspects of
TD, the word architec* should be explicitly mentioned.
However, we are aware of that there are related terms that in
many respects resemble the architectural aspects of TD.
C. Data extraction
To reduce the risk of subjectivity, during the classification
and extraction phase, made by only one researcher, some
publication was examined by at least two researchers to ensure
that the returned publications were suitable, and equivalent
D. The model of ATD
In the Model of ATD in Fig.4, other aspects, relationships,
and associated impacts may exist but are omitted in this model,
since they were not explicitly revealed in the review process
and thus have not been further analyzed.
In a software life-cycle perspective, it is of vital importance
to understand and proactively manage ATD. Left unchecked,
ATD can potentially stifle implementing new features and
organizations may face expensive repercussions due to costly
architectural maintenance complication. In order to synthesize
and compile th -of-the- the ATD field, we
conducted a systematic literature review focusing on the
research areas: ATD in terms of principal, interest, debt and
related challenges and solutions for managing ATD.
In this study we have provided a new and comprehensive
understanding and raised awareness about what challenges
ATD are surrounded by and finally how ATD can be
successfully managed. The findings showed that there is wide
agreement in the reviewed literature that ATD is of primary
importance. ATD is, however, surrounded by several
challenges, and while numerous publications mention different
isolated ATD management activities, there is an absence of, and
a need for a thorough indicative ATDM process for the
practitioner and academic communities, covering all these
separate activities. Different ATD categories (as debt) can
result in various negative consequences (as interest), requesting
effective refactoring strategies (as principal). A refactoring
strategy mainly refers to, how to, and if, and to what extend
repaying the debt, should be formulated.
This research contributes to knowledge that addresses a
current gap in understanding, where knowledge and research of
ATD are non-unified and fragmented. One key contribution of
this paper is our novel model of ATD. This model summarizes
our findings and allows improved identification of ATD and
associated negative consequences and corresponding ATDM
activities. The model illustrates ATD, in a unified and
comprehensive way by exploring different aspects and
relationships, which are considered particularly valuable for
managing and raising awareness about ATD.
The model reveals that all categories of ATD (as debt) are
related to the challenge of Complexity and furthermore that all
challenges are related to Maintenance and evolvability. This
model can help several different stakeholders within the
software life-cycle process to better and more informed,
manage the software, with the goal of raising the
success rate and lower the rate of negative consequences.
As future work, we plan to investigate this area further by
means of expanding this review to include additional closely
related research publications and by applying backward and
forward snowballing methods. Also, it would be interesting to
validate our model in an empirical context.
To further study the impact and the influence of the
different aspects of the unified model of ATD, we are currently
conducting empirical research with the aim of finding which
aspects are the most hurtful for the software development life-
Many thanks to all the participants in our survey and
interviews, as well as to our Software Center industrial partners.
[1] H. Van Vliet, Software Engineering: Principles and Practice: John Wiley
& Sons, 2008.
[2] W. Cunningham, "The WyCash portfolio management system, in: 7th
International Conference on Object-Oriented Programming, Systems,
[3] P
Metaphor to Theory and Practice, EEE, vol. 29, no. 6, 2012,
pp. 18-21.
[4] A. Martini and J. Bosch, "The Danger of Architectural Technical Debt:
Contagious Debt and Vicious Circles," in Proceedings - 12th Working
IEEE/IFIP Conference on Software Architecture, WICSA 2015, 2015,
pp. 1-10.
[5] A. Martini, J. Bosch, and M. Chaudron, "Architecture Technical Debt:
Understanding Causes and a Qualitative Model," in Software
Engineering and Advanced Applications (SEAA), 2014 40th
EUROMICRO Conference on, 2014, pp. 85-92.
[6] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey, and
Systematic literature reviews in software engineering A
systematic literature review,
51, no. 1, 2009, pp. 7-15.
[7] A. Ampatzoglou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou,
2015, pp. 52.
Journal of Systems and Software, vol. 86, no. 6, 2013, pp. 1498-1516.
[9] B. Curtis, J. Sappidi, and A. Szynkarski, "Estimating the size, cost, and
types of Technical Debt," in Managing Technical Debt (MTD), 2012
Third International Workshop on, 2012, pp. 49-53.
[10] B. Curtis, J. Sappidi,
[11] Z. Li, P. Liang, and P. Avgeriou, "Architectural Debt Management in
Value-Oriented Architecting," in Economics-Driven Software
Architecture, ed, 2014, pp. 183-204.
[12] I. Ozkaya, R. L. Nord, H. Koziolek, and P. Avgeriou, "Second
International Workshop on Software Architecture and Metrics (SAM
2015)," in Software Engineering (ICSE), 2015 IEEE/ACM 37th IEEE
International Conference on, 2015, pp. 999-1000.
[13] I. Macia, J. Garcia, D. Popescu, A. Garcia, N. Medvidovic, and A. v.
Staa, "Are automatically-detected code anomalies relevant to
architectural modularity?: an exploratory analysis of evolving systems,"
presented at the Proceedings of the 11th annual international conference
on Aspect-oriented Software Development, Potsdam, Germany, 2012.
[14] N. S. R. Alves, T. S. Mendes, M. G. de Mendonça, R. O. Spínola, F.
Debt: A Systema
Technology, 2015.
vol. 101, 2015, pp. 193-220.
UK, Keele University, vol. 33, no. 2004, 2004, pp. 1-26.
[17] M. Ran, J. Garcia, C. Yuanfang, and N. Medvidovic, "Mapping
architectural decay instances to dependency models," in Managing
Technical Debt (MTD), 2013 4th International Workshop on, 2013, pp.
[18] N. A. Ernst, "On the role of requirements in understanding and managing
technical debt," in Managing Technical Debt (MTD), 2012 Third
International Workshop on, 2012, pp. 61-64.
[19] S. Bellomo, N. Ernst, R. Nord, and R. Kazman, "Toward design
decisions to enable deployability: Empirical study of three projects
reaching for the continuous delivery holy grail," in Proceedings - 44th
Annual IEEE/IFIP International Conference on Dependable Systems and
Networks, DSN 2014, 2014, pp. 702-707.
[20] Z. Li, P. Liang, P. Avgeriou, N. Guelfi, and A. Ampatzoglou, "An
empirical investigation of modularity metrics for indicating architectural
technical debt," presented at the Proceedings of the 10th international
ACM Sigsoft conference on Quality of software architectures, Marcq-en-
Bareul, France, 2014.
[21] J. Brondum and L. Zhu, "Visualising architectural dependencies,"
presented at the Proceedings of the Third International Workshop on
Managing Technical Debt, Zurich, Switzerland, 2012.
[22] N. A. Ernst, S. Bellomo, I. Ozkaya, R. L. Nord, and I. Gorton, "Measure
it? Manage it? Ignore it? software practitioners and technical debt,"
presented at the Proceedings of the 2015 10th Joint Meeting on
Foundations of Software Engineering, Bergamo, Italy, 2015.
[23] B. Curtis, J. Sappidi, and A. Szynkarski, "Estimating the size, cost, and
types of technical debt," in 2012 3rd International Workshop on
Managing Technical Debt, MTD 2012 - Proceedings, 2012, pp. 49-53.
[24] F. A. Fontana, V. Ferme, and M. Zanoni, "Towards Assessing Software
Architecture Quality by Exploiting Code Smell Relations," in
Proceedings - 2nd International Workshop on Software Architecture and
Metrics, SAM 2015, 2015, pp. 1-7.
[25] E. Ligu, A. Chatzigeorgiou, T. Chaikalis, and N. Ygeionomakis,
"Identification of refused bequest code smells," in IEEE International
Conference on Software Maintenance, ICSM, 2013, pp. 392-395.
[26] B. Boehm, "Architecture-Based Quality Attribute Synergies and
Conflicts," in Proceedings - 2nd International Workshop on Software
Architecture and Metrics, SAM 2015, 2015, pp. 29-34.
[27] C. Fernández-Sánchez, J. Díaz, J. Pérez, and J. Garbajosa, "Guiding
flexibility investment in agile architecting," in Proceedings of the Annual
Hawaii International Conference on System Sciences, 2014, pp. 4807-
[28] Z. Li, P. Liang, and P. Avgeriou, "Architectural Technical Debt
Identification Based on Architecture Decisions and Change Scenarios,"
in Proceedings - 12th Working IEEE/IFIP Conference on Software
Architecture, WICSA 2015, 2015, pp. 65-74.
[29] K. Schmid, "A formal approach to technical debt decision making,"
presented at the Proceedings of the 9th international ACM Sigsoft
conference on Quality of software architectures, Vancouver, British
Columbia, Canada, 2013.
[30] J. Holvitie, V. Leppanen, and S. Hyrynsalmi, "Technical Debt and the
Effect of Agile Software Development Practices on It - An Industry
Practitioner Survey," in Managing Technical Debt (MTD), 2014 Sixth
International Workshop on, 2014, pp. 35-42.
[31] ating Architectural
Technical Debt accumulation and refactoring over time: A multiple-case
[32] C. Fernández-Sánchez, J. Garbajosa, C. Vidal, and A. Yagüe, "An
Analysis of Techniques and Methods for Technical Debt Management: A
Reflection from the Architecture Perspective," in Proceedings - 2nd
International Workshop on Software Architecture and Metrics, SAM
2015, 2015, pp. 22-28.
[33] A. Martini and J. Bosch, "Towards Prioritizing Architecture Technical
Debt: Information Needs of Architects and Product Owners," in Software
Engineering and Advanced Applications (SEAA), 2015 41st Euromicro
Conference on, 2015, pp. 422-429.
[34] R. Kazman, C. Yuanfang, M. Ran, F. Qiong, X. Lu, S. Haziyev, et al., "A
Case Study in Locating the Architectural Roots of Technical Debt," in
Software Engineering (ICSE), 2015 IEEE/ACM 37th IEEE International
Conference on, 2015, pp. 179-188.
[35] R. L. Nord, I. Ozkaya, P. Kruchten, and M. Gonzalez-Rojas, "In search
of a metric for managing architectural technical debt," in Proceedings of
the 2012 Joint Working Conference on Software Architecture and 6th
European Conference on Software Architecture, WICSA/ECSA 2012,
2012, pp. 91-100.
[36] A. Martini, L. Pareto, and J. Bosch, "Towards Introducing Agile
Architecting in Large Companies: The CAFFEA Framework," in Agile
Processes, in Software Engineering, and Extreme Programming. vol.
212, C. Lassenius, T. Dingsøyr, and M. Paasivaara, Eds., ed: Springer
International Publishing, 2015, pp. 218-223.
[37] P. Kruchten, "Strategic management of technical debt: Tutorial
synopsis," in Proceedings - International Conference on Quality
Software, 2012, pp. 282-284.
[38] C. Izurieta, G. Rojas, and I. Griffith, "Preemptive Management of Model
Driven Technical Debt for Improving Software Quality," presented at the
Proceedings of the 11th International ACM SIGSOFT Conference on
Quality of Software Architectures, Montréal, QC, Canada, 2015.
[39] D. A. Tamburri and E. D. Nitto, "When Software Architecture Leads to
Social Debt," in Proceedings - 12th Working IEEE/IFIP Conference on
Software Architecture, WICSA 2015, 2015, pp. 61-64.
[40] R. Nickerson, J. Muntermann, U. Varshney, and H. Isaac, "Taxonomy
development in information systems: developing a taxonomy of mobile
applications, in: 17th European Conference in Information Systems
[41] Z. Li, P. Liang, and P. Avgeriou, "Chapter 5 - Architecture viewpoints
for documenting architectural technical debt," in Software Quality
Assurance, I. M. S. A. G. Tekinerdogan, Ed., ed Boston: Morgan
Kaufmann, 2016, pp. 85-132.
... • TD occurs due to decisions made for short-term benefit that have long-term negative consequences [32]- [37]. • Taking on TD involves making a compromise in one area to achieve a benefit in another area (e.g., reducing the quality of testing to save schedule) [35], [38]- [42] • The effect of taking on TD is an increased amount of work in the future [38], [43], [44]. ...
... Interest on TD is traditionally defined as the extra effort required to modify the system due to the presence of deficiencies [5], [32], [36], [40], [54]. TD interest has also been defined as the work to correct a deficiency [58], the additional work to implement new functionality [49], and the additional work to maintain the system due to the presence of the deficiency [55], [59]. ...
Full-text available
The technical debt metaphor is used to describe the long-term consequences of engineering decisions made to achieve a short-term benefit. The metaphor originated in the field of software engineering and has begun to migrate to other fields, including systems engineering. The usage of the metaphor, its associated terminology, and basic definitions vary both within the software field and within the greater engineering community. The lack of consistent definitions inhibits the ability of system developers to understand and control technical debt within their system developments. This paper presents an ontology for technical debt, focusing on the field of systems engineering. By providing a set of concise and consolidated definitions, this ontology enables precise discussion of technical debt and associated techniques for mitigating its impact within systems engineering.
... Technical debts are constructs in software systems that are beneficial in the short term but hinder changes in the long term [2]. Technical debt in SA was identified as one of the most dangerous types [13] because there is a lack of refactoring strategies [3]. ...
... Less research has been done on how to deal with bad decisions after they have been made. Some of these aspects are discussed in the research field of architectural technical debt, e.g., [3]. For example, Kruchten et al. present a guideline on how asking about SAMs might lead to the root causes for some architectural technical debts [12]. ...
Full-text available
Context. Own experiences and faulty decisions can be an important source of information for software architects. The experiences and mistakes of other architects can also be valuable information sources. Goal. Under the assumption that the knowledge about faulty decisions, i.e., mistakes, regarding software architecture is not shared adequately in practice, this work qualitatively investigates the handling and particularly communication of those mistakes by software architects. Method. We conducted a grounded-theory study in which we interviewed ten German software architects from various domains. Results. We identified software architects' definitions of architectural mistakes, their handling of these mistakes, and their preferred communication strategies regarding these mistakes. We found that architects communicate mistakes mainly within their project teams and seldom within or across companies. Conclusions. We derived strategies to make learning and prevention of mistakes more effective. To share experiences and knowledge beyond architects' peer groups, companies should invest more effort in discussing mistakes more consciously and create an environment where mistakes can be discussed openly.
... Identification and Management of Technical Debt: A Systematic Mapping Study [2] x P6 Managing Architectural Technical Debt: A Unified Model and Systematic Literature Review [11] x P7 A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners [57] x P8 A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools [45] x P9 Investigate, identify and estimate the technical debt: a systematic mapping study [8] x that P7 has fewer categories since the study is on the specific topic of Architectural Technical Debt. ...
Context. Own experiences and faulty decisions can be an important source of information for software architects. The experiences and mistakes of other architects can also be valuable information sources. Goal. Under the assumption that the knowledge about faulty decisions, i.e., mistakes, regarding software architecture is not shared adequately in practice, this work qualitatively investigates the handling and particularly communication of those mistakes by software architects. Method. We conducted a grounded-theory study in which we interviewed ten German software architects from various domains. Results. We identified software architects’ definitions of architectural mistakes, their handling of these mistakes, and their preferred communication strategies regarding these mistakes. We found that architects communicate mistakes mainly within their project teams and seldom within or across companies. Conclusions. We derived strategies to make learning and prevention of mistakes more effective. To share experiences and knowledge beyond architects’ peer groups, companies should invest more effort in discussing mistakes more consciously and create an environment where mistakes can be discussed openly. KeywordsSoftware ArchitectureSoftware Architecture KnowledgeSoftware Architecture DecisionsSoftware Architecture Communication
The technical debt metaphor is used within software engineering to describe technical concessions that produce a short‐term benefit but result in long‐term consequences. Systems engineering is subject to these concessions, yet there is a limited amount of research associating technical debt with systems engineering. This paper provides the results of an empirical survey investigating the prevalence of technical debt in systems engineering, including the occurrence of technical debt, the use of the metaphor, and the distribution of technical debt within the systems engineering lifecycle. The results of the survey show that while technical debt is common in systems engineering and occurs throughout the lifecycle, the metaphor and terminology of technical debt is not consistently applied. These results emphasize the need to enrich the usage of the technical debt metaphor within systems engineering to enable the management of technical debt and to reduce the risk of technical bankruptcy.
Full-text available
Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt. Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations. Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand. Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management. Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.
Full-text available
This report documents the program and outcomes of Dagstuhl Seminar 16162, “Managing Technical Debt in Software Engineering.” We summarize the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar. The report also includes the abstracts of the talks presented at the seminar and summaries of open discussions.
Technical debt, a metaphor for the long-term consequences of weak software development, must be managed to keep it under control. The main goal of this article is to identify and analyze the elements required to manage technical debt. The research method used to identify the elements is a systematic mapping, including a synthesis step to synthesize the elements definitions. Our perspective differs from previous literature reviews because it focused on the elements required to manage technical debt and not on the phenomenon of technical debt or the activities used in performing technical debt management. Additionally, the rigor and relevance for industry of the current techniques used to manage technical debt are studied. The elements were classified into three groups (basic decision-making factors, cost estimation techniques, practices and techniques for decision-making) and mapped according three stakeholders’ points of view (engineering, engineering management, and business-organizational management). The definitions, classification, and analysis of the elements provide a framework that can be deployed to help in the development of models that are adapted to the specific stakeholders’ interests to assist the decision-making required in technical debt management and to assess existing models and methods. The analysis indicated that technical debt management is context dependent.
Documenting the time dimension part of your architecture might look like extra work. However, anticipation should be a large part of your job as an architect, anyway. If you communicate your anticipation as an evolution viewpoint or architecture roadmap, your architecture description will stay valid longer. And, you'll have a ready answer when stakeholders ask how you've addressed their change and planning concerns.
Technical Debt is created when design decisions that are expedient in the short term increase the costs of maintaining and adapting this system in future. An important component of technical debt relates to decisions about system architecture. As systems grow and evolve, their architectures can degrade, increasing maintenance costs and reducing developer productivity. This raises the question if and when it might be appropriate to redesign (“refactor”) a system, to reduce what has been called “architectural debt”. Unfortunately, we lack robust data by which to evaluate the relationship between architectural design choices and system maintenance costs, and hence to predict the value that might be released through such refactoring efforts. We address this gap by analyzing the relationship between system architecture and maintenance costs for two software systems of similar size, but with very different structures; one has a “Hierarchical” design, the other has a “Core-Periphery” design. We measure the level of system coupling for the 20,000+ components in each system, and use these measures to predict maintenance efforts, or “defect-related activity.” We show that in both systems, the tightly-coupled Core or Central components cost significantly more to maintain then loosely-coupled Peripheral components. In essence, a small number of components generate a large proportion of system costs. However, we find major differences in the potential benefits available from refactoring these systems, related to their differing designs. Our results generate insight into how architectural debt can be assessed by understanding patterns of coupling among components in a system.
Conference Paper
The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.
Software is being produced at such a rate that its growth hinders its sustainability. Technical debt, as a concept encompassing internal software quality, evolution and maintenance, re-engineering and economics is growing to become dominant as a driver of progress in the future of software engineering. Technical debt spans the entire software engineering lifecycle and its management capitalizes on recent advances made in fields such as source code analysis, quality measurement, and project management. Managing technical debt in the future will be an investment activity applying economics theories, will effectively address the architecture level, will offer specific processes and tools employing data science and analytics to support decision making, and will be an essential part of the software engineering curriculum. Getting ahead of the software quality and innovation curve will inevitably involve establishing technical debt management as a core software engineering practice from theory to its applications.