The SQALE Debt Map: How to use it

I previously explained the use of the SQALE Pyramid here . I will explain here how to use the Debt Map indicator.

We can produce this indicator at 2 levels:
• The first level is the Project level. In this case each point of the map is a file.
• The second level is the Portfolio level. In this case each point is an application.

We’ll see how to use this indicator in each case.

The Project level Debt Map
In this case, each file of the application is placed on the graph (X and Y axes) according to two measures:
X is the total amount of Technical Debt of the file. This is the estimated time required to fix any non-conformity identified. The higher this value is, the more time will be needed to get a “right” file.
Y is the cumulated “Non-Remediation Cost” of all non-conformities identified in the file. The concept of “Non-Remediation Cost” was presented and explained here. To summarize, this represents the business impact of the non-conformities. The higher the value, the greater the risk incurred if the file is delivered as it is.

Figure 1: SQALE Debt Map at file level

This graph allows you to quickly analyze all the files of the application. If we take the example of Figure 1:

  • File 2 includes about 5 times more Technical Debt than File 1.
  • All things being equal, the technical debt of File 3 is 10 times more dangerous/risky than File 2.

This graph is also useful to make decisions about remediation priorities. For example, in the case of a project working on an application with a legacy part.

If you have very little time available, you will refactor File 4 because it has little debt but this debt is potentially highly damageable. Compared to refactoring File 3, your task will have a much higher Return on Investment.

If you have more time available, you will extend the operation to all the files with a Non-Remediation Cost over a given threshold. As an example, you will decide to refactor the 5 files whose Non-Remediation Cost is over 500. By doing so, you will decrease significantly the level of exposure of your users.

The Portfolio level Debt Map
In this case, the points on the map are applications. Each application is positioned according to its Technical Debt density and its Non-Remediation Cost density.
This allows to analyze the situation of a complete portfolio and to compare all the different applications whatever their technology, size and context.

If we take the example of Figure 2:

  • App B contains about 5 times more Technical Debt than App A.
  • All things being equal, the technical debt of App C is 40 times more dangerous than App A.

This will help to analyze the situation and identify which part of your portfolio needs attention.

Figure 2: SQALE Debt Map at application level

If an application provides very little « business value » and its annual maintenance workload is very low, the fact that it is not very well positioned in the Map Debt is not worrisome.
On the contrary, if an application is very critical, and its code is not of good quality (that is to say, it is positioned at the top right of the map), we understand that this represents a risk and improving the code of this application may be of high priority.