You are responsible for regularly delivering software releases that contain new functionality for the users - and you have understood that efficient delivery is only possible with a clean code architecture. Or you are the one in the delivery organization who is directly responsible for the code architecture.
Your job (directly or indirectly) is to make sure that the code remains future-proof and will always be easily extended, adapted, maintained. In short: You ensure that the level of “technical debt” in the code is low.
Your organization produces software and will extend, maintain, and adapt it throughout the next years. Such software could be, for example:
You need to balance out investments into new functionality (value creation for the users) versus technical house-keeping (fighting technical debt). However, you have no numbers-driven cockpit for your balancing act.
You are part of the delivery side, but the business side decides and provides the budget. Technical debt is considered “your problem” for which the business side is not willing to pay.
You may have many code checker tools that quantify coding rule violations. However, with this you only get a grasp on technical debt as a potential risk. You have no way to quantify the impact of technical debt on developer productivity (interest payments on technical debt).
If you could show the business side KPIs in their language (money and time) how technical debt affects productivity, you could better convince them to invest in the reduction of technical debt.
If you could visualize the risk in the code landscape to the business side in an understandable and striking way, you could better convince them to invest in the reduction of technical debt.