CHAPTER 9 Architectural Debt Management inValue-Oriented Architecting
Zengyang Li,Peng Liang,Paris Avgeriou
2014-01-01
Abstract:In the field of software architecture (SA), there has been a paradigm shift from describing the outcome of the architecting process to documenting architectural knowledge (AK), such as architecture decisions and rationale, which are considered as first-class entities of a software architecture (ISO/ IEC/IEEE, 2011). Architecture decisions often involve trade-offs made between a number of stakeholder concerns. In particular, technical concerns (e.g., system quality attributes) are often compromised to meet business concerns (e.g., development cost or time to market). For example, poorly designed legacy components may be reused instead of implementing their functionality from scratch, in order to achieve fast product delivery. Such trade-offs made in architecture design may lead to architectural technical debt (ATD, or shortly architectural debt). In a broader scope, technical debt (TD) refers to immature software artifacts that fail to meet the required level of quality (Cunningham, 1992; Seaman and Guo, 2011). Accordingly, ATD refers to immature architecture design artifacts that compromise systemwide quality attributes (QAs), particularly maintainability and evolvability. On the one hand, TD needs to be repaid sooner or later, as it may have grave consequences for future software development cycles; on the other hand, TD (and ATD as a type of TD) is not necessarily a “bad thing,” but rather something that can be leveraged for business advantage when incurred with full knowledge of the consequences, that is being explicitly managed (Kruchten et al., 2012). Although many approaches have been proposed to document architecture decisions in the architecting process (e.g., decision views in architecture design; see van Heesch et al., 2012a, 2012b), the ATD caused by decisions is still not effectively managed. In most cases, ATD is not made explicit, and architecture decision making does not take into account the ATD that will be incurred by the different design options. This may cause problems particularly during system maintenance and evolution, when ATD is accumulated and difficult to repay. In this chapter, we present an initial attempt to tackle this problem through the following: (1) an ATD conceptual model; and (2) an architectural technical debt management (ATDM) process applying the proposed conceptual model, and aligned with a general architecting process. Our contribution to this end can facilitate optimal decision making in architecture design and achieve a controllable and predictable balance between the value and cost of architecture design in the long term.