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 keeps being future-proof and will always be easily extended, adapted, maintained. In short: You make sure that the level of “Technical Debt” in the code is low.
Your organization produces software and will extend, maintain, 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 as “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, by this you only get a grip 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 into 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 into reduction of Technical Debt.