Architecture Viewpoints for Documenting Architectural Technical Debt

Introduction

Architecture Viewpoints for Documenting Architectural Technical Debt is a chapter in Economics-Driven Software Architecture.  The authors are Zengyang Li, Peng Liang, and Paris Avgeriou (LLA).  In this chapter, the authors propose a set of viewpoints which are meant to facilitate the documentation of architectural technical debt.  This blog post provides a summary and commentary.

There are three stated contributions for this work.  They are:

1. Identify architectural technical debt stakeholders and their concerns.
2. Propose their architecture viewpoints.
3. Provide evidence for the effectiveness of their viewpoints.

Following a common pattern for articles on technical debt, the authors begin by describing what they mean by their use of the term.  In this case technical debt is taken to mean the compromise of some quality attribute (QA) in exchange for a business advantages.  Quality attributes can include things like modularity, encapsulation, maintainability or evolvability.  Business advantages can include things like time to market and cost savings.  Architectural technical debt (ATD), specifically is when architectural decisions are made that incur or repay technical debt.  As seen in this work, architectural debt normally influences maintainability or evolvability.

Architectural Debt Viewpoints

Hello World

What is there to say about Cunningham's 1992 paper, Experience Report -- The Wycash Portfolio Management System, except that it started it all?  That's enough.  It is now impossible to write a paper (or blog) about technical debt that doesn't begin by citing Cunningham:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

With that short excerpt, Cunningham introduced three ideas with staying power.

1. "not quite right" code is like a form of debt.
2. Time spent maintaining this code is like a form of interest.
3. Technical debt can have positive or negative effects.  Negative effects can be crippling.

Over the years, not quite right code has evolved into not quite right technology, and this phenomenon developed the name technical debt.

It is interesting to see how interest in the concept has developed over time.  In A systematic mapping study on technical debt and its management, Zengyang Li, Paris Avgerioua, and Peng Liang provided this graph with the number of studies from 1992 through 2013.