The details of each ATDM as well as their input and output in the architecting process are decribed below.
1. ATD identification detects ATD items during or after the architecting process. An ATD item is incurred by an architecture decision, thus, one can investigate an architecture decision and its rationale to identify an ATD item by considering whether the maintainability or evolvability of the software architecture is compromised.
2. ATD measurement analyzes the cost and benefit associated to an ATD item and estimates them, including the prediction of change scenarios influencing this ATD item for interest measurement. For interest measurement, three types of change scenarios are considered: (1) the planned new features according to the version plan of the software project; (2) the already-known maintenance tasks that enhance specific QAs (except maintainability and evolvability) of the implemented software architecture; and (3) the emerging requirements. The first two types of change scenarios can be predicted while the rest one is unforeseeable. For some complex software systems (e.g., operating systems), the time interval between two releases can be very long. For instance, Microsoft Windows 7 Service Package 1 was released 16 months after the first release of Microsoft Windows 7. For such kind of software systems, it is inevitable that new requirements emerge during the development of a new release. Some of these new requirements need to be implemented in the release. Thus, in such cases situation, to ensure a reasonable accuracy of interest measurement, the interest of related ATD items should be re-measured at different times during the development of the release.
3. ATD prioritization sorts all the identified ATD items in a software system using a number of criteria. The aim of this activity is to identify which ATD items should be resolved first and which ones can be resolved later depending on the system’s business goals and preferences. There are a number of ATD items in a software system and all the ATD items will not be resolved at one time due to their cost or technical issues. The ATD items have different financial and technical impacts on the system. Consequently, it is wise to choose the items with higher priorities to be resolved first. Software projects have different context, and there are no standard criteria to decide the priority of an ATD item in a project. However, the following factors need to be taken into account in ATD prioritization: (1) the total cost of resolving an ATD item; (2) the cost/benefit ratio of the ATD item; (3) the interest rate of the ATD item; (4) how long the ATD item has been incurred; (5) the complexity (e.g., the number of involved components of an ATD item) of resolving an ATD item. Since not all types of benefits can be measured in a unified metric, it is hard to automatically prioritize the ATD items by tooling. However, an appropriate tool, which reasonably deals with the factors described above, can facilitate ATD prioritization.
4. ATD repayment concerns making new or changing existing architecture decisions in order to eliminate or mitigate the negative influences of an ATD item. An ATD item is not necessarily resolved at once. In certain situation, only part of an ATD item is resolved, because it could be too expensive to resolve the entire ATD item, and resolving part of the ATD item can make the ATD item under control with an acceptable cost. When an ATD item is partially resolved, the ATD item will be revised and split into two parts: the part that is resolved and the part that is not.
5. ATD monitoring watches the changes of the cost and benefit of unresolved ATD items over time. When an architectural change happens in the part of architecture design containing an unresolved ATD item or when one ATD item is partially resolved, the affected ATD item will be recognized as a changed ATD item. All the changed ATD items will be measured in the next ATDM iteration. This ATDM activity makes ATD changes explicitly and consequently keeps all the ATD items of the system under control.
- Z. Li, P. Liang, P. Avgeriou, Architectural Debt Management in Value-oriented Architecting, in I. Mistrik, R. Bahsoon, Y. Zhang, K. Sullivan, R. Kazman (eds.), Economics-Driven Software Architecture, Elsevier, 2014, Pages 183-204.