Retour à la liste
Like debt at national or organizational level, reducing technical debt is a major preoccupation for many CIOs, especially those who take up their role and arrive at the helm of a legacy information system. What are the ins and outs of this notion? How can we measure its impact and steer it over the long term? Here are some answers.
What is technical debt?
American computer scientist Ward Cunningham is credited with inventing the concept of technical debt. Based on an analogy with financial debt, this notion was theorized in 1992 and applied to software development.
Technical debt covers all the incidentology and technological obsolescence that generate complexity and slow down the development of the information system, with a cost that takes a long-term hold on the CIO:
- lines of code developed quickly, temporarily, but never rewritten;
- a component that has become obsolete, unsupported and a source of security vulnerabilities;
- an unexecuted version upgrade, rendering an entire section of the system obsolete;
- an architecture progressively degraded by successive compromises.
If the debt is not repaid, its weight increases mechanically over time. A snowball effect sets in: “interest” accumulates and is added to the initial debt, until, in extreme cases, it paralyzes the smooth running of the CIO. Teams then find themselves mobilized almost exclusively to maintain failing software or infrastructures, to the detriment of innovative Projects and IS evolution.
Why are technical debt and legacy often confused?
By extension, some CIOs equate the concept of technical debt with that of legacy, i.e. the old system built on previous generations of technology that is inherited. There is, however, one important nuance worth highlighting.
A legacy system, though imposing and sometimes complex, can be sufficiently well urbanized, documented and maintained not to constitute an IS liability – quite the contrary. On the other hand, if left unattended, legacy systems can quickly fall into debt, with significant damage as a result.
“I have often observed that legacy systems create a form of dependency on experts who, over time, master obsolete technologies with little or no documentation. This situation serves the collective interest and slows down the evolution of the IT system as a whole.”
Claude Carvalho, Director of Information Systems and Transformation at Galian-SMABTP.
Breaking out of this “legacy spiral” often involves carrying out genuine Organizational change management (OCM), to return to a more structured, transparent and sharable process.
What are the many costs of technical debt?
Technical debt is not an abstract concept. It generates very concrete costs at several levels:
- A direct financial cost, in corrective and upgrade maintenance, measurable in particular in Third-Party Application Maintenance (TMA) budgets;
- An operational cost, linked to service interruptions, recurring bugs and performance degradations that can slow down, penalize or even halt the smooth running of a service;
- A cost in terms of image for the CIO, in the eyes of all the company’s stakeholders: users, business departments, senior management, etc;
- Lastly, there is a human cost in terms of Teams’ morale and commitment, particularly when it comes to keeping obsolete systems afloat. The feeling of “putting patches on a leaky ship” can be deleterious to the collective dynamic.
Creating technical debt is, to a certain extent, almost inevitable. Development means producing new functionalities that need to be maintained over time, in a context where technologies are constantly evolving. So the challenge is not to aim for zero debt, but to understand, anticipate and steer it.
Is talking about good and bad technical debt a false debate?
Many analyses position technical debt in a quadrant : intentional or unintentional, prudent or imprudent. Can we then speak of “good” and “bad” technical debt? To a certain extent, yes.
Involuntary technical debt
More often than not, it is the result of long-standing bad practices or past mistakes:
- repeated compromises on code quality ;
- lack of peer review ;
- inadequate documentation;
- lack of non-regression tests;
- neglect of architecture and overall vision ;
- inappropriate technological choices or obsolescence allowed to set in.
This debt can quickly spiral out of control, permanently crippling the IS’s ability to function properly. When almost all Resources are mobilized to maintain a fragile system, there is no room for innovation or development.
Intentional technical debt
Conversely, not all technical debt is negative. It is often the case that an organization knowingly assumes a debt.
When rapid go-to-market is a major strategic challenge, you may decide to prioritize development speed and Agility over intrinsic code quality. This trade-off is perfectly legitimate as long as the expected benefits – particularly commercial ones – outweigh the anticipated drawbacks.
It’s a question of finding the right balance between opportunistic quick wins and a more purist vision, with full awareness of future impacts. To illustrate: developing a solution in 30 days or 100 days for a similar apparent functional result does not mean building the same thing. The effects on the technological heritage and its capacity to evolve will be profoundly different.
It’s up to the CIO and the architects to make these choices, based on the target architecture and the IS application map, without forgetting the need to assume the future cost.
Why is it necessary to deal with technical debt?
Good or bad, technical debt becomes a real problem when it can no longer be contained. There are a number of concrete levers for action:
- after Go-live, leave Projects open for a few more weeks to finalize, document and consolidate ;
- instill a genuine culture of quality and give architects the latitude they need to structure IS over the long term;
- integrate, into project portfolios, initiatives explicitly dedicated to internal IS optimization, by allocating an identified bandwidth to them.
Can AI help manage technical debt?
The emergence of Artificial Intelligence (AI) in the IT field naturally raises the question of its role in controlling technical debt. Today’s CIOs, CIOs and PMOs are wondering how these new technologies can help reduce the problems associated with obsolescence, system complexity and accumulated bugs.
AI offers several interesting levers for managing technical debt:
- Automated code and system analysis: some tools use machine learning to identify risky areas in the code, redundant functionalities or critical technological dependencies. These analyses enable problems to be detected quickly, before they become costly, and Teams to focus on priority actions.
- Intelligent prioritization of projects and sprints: combined with project scoring criteria, AI can help estimate the impact of each project on technical debt and overall IS performance, facilitating resource allocation and the choice of tests and interventions to be repaid as a priority.
- Automation of maintenance and testing: AI can generate automated scripts to correct code, limit bugs in existing software and improve the integration of functionalities. Teams can then concentrate on developing new functionalities and improving overall IS quality.
- Predictive tracking of data and systems: by analyzing historical data and performance KPIs, AI can anticipate areas of the IS likely to generate debt, enabling proactive interventions to be planned in the development and maintenance process.
However, the use of AI is not without its risks, and can paradoxically contribute to an increase in technical debt if left unchecked:
- AI can accelerate the development of complex or poorly documented solutions, creating new layers of debt if practices, testing, documentation and integration don’t keep up.
- Over-reliance on Automation tools can mask structural problems in the IS, giving the impression of control while code, software or infrastructure continue to deteriorate.
- Resources and Teams can be diverted to Tracking AI or correcting its recommendations, instead of addressing the root causes of the debt.
To curb these risks, a number of precautions must be taken:
- Integrate AI into a rigorous process: every recommendation or automated action must be validated by experienced architects or developers.
- Prioritize value-added interventions: AI should be a diagnostic and scoring tool for Projects, not an automatic generator of functionality or uncontrolled code.
- Qualitative and quantitative tracking: each project must be evaluated to measure its impact on technical debt, even when it incorporates recommendations or automated scripts derived from AI.
AI represents a powerful lever for reducing and steering technical debt, provided it is used in a controlled and critical way. It makes data more visible, detects problems early and directs Resources efficiently, but it does not replace human vigilance and expertise in the strategic and sustainable management of IS.
How can you steer your technical debt wisely?
1. Making technical debt everyone’s business
Technical debt doesn ‘t just concern IT teams: it affects the entire information system and, by extension, the company’s performance. It is therefore essential to involve a broad spectrum of players, to ensure that debt does not remain an invisible or deferred problem.
- It’s not limited to software and applications: infrastructure, data, urbanization and software interfaces are also concerned.
- It’s not just a matter of the run: it’s during development that decisions are made about whether or not to create debt. Decisions taken during a sprint, the choice of priority features or compromises on code quality have long-term consequences.
- It impacts budgets, deadlines and available resources: poorly managed debt can tie up Teams in corrective maintenance and testing, to the detriment of innovative Projects.
For these reasons, CIOs need to create a culture of transparency around technical debt, by systematically including this subject in Projects committees and raising awareness among all stakeholders: business departments, finance, security, and even key users. A good practice is to record debt-creating decisions in management tools, so that everyone understands the origin of choices and their impact.
2. The key role of the CIO/GM duo
Governance of technical debt cannot be confined to the CIO alone. Like financial debt, it must be tracked at the highest strategic level: senior management and the CIO must act as a pair to arbitrate choices and define debt tolerance.
- Technical debt is a strategic asset: as mentioned above, some debts can be assumed if they accelerate the time-to-market of a critical software or functionality, but they must be documented and integrated into the planning of future Projects.
- Technical debt enables a balance to be struck between speed and quality: the CIO / GM team can decide to give priority to certain Projects that can be delivered quickly, while planning tests, maintenance and the gradual reduction of debt.
Involving senior management also makes it easier to adhere to strategic decisions, such as prioritizing Projects that help contain or reduce technical debt, while remaining aligned with business objectives. It is this shared vision that transforms technical debt into a strategic parameter rather than a purely technical problem.
3. Make technical debt visible, particularly in the Budgets
Transparency is a key condition for making technical debt a shared subject.
Demonstrating the budget is decisive: it is essential to work with quantified, comparable scenarios to justify investment choices, particularly those devoted to debt reduction. This approach must be based on a clear demonstration of the expected gains – financial, operational and organizational – to secure the support of decision-makers.
A good indicator is run costs as a proportion of the CIO’s overall Budgets. An increase in TMA and patching costs is often the visible symptom of a growing debt. Hence the importance of anticipating, right from the development stage, the recurring costs incurred by each Project.
A ratio of 10 to 15% of the development cost as the annual recurring cost is a sound basis for integrating the cost of maintaining an application from the outset.
4. Educate with technical debt
Technical debt is a difficult subject to grasp outside the IT sphere. It is precisely for this reason that education is a key factor in its management.
The CIO’s role is to make this debt accessible, intelligible and debatable with his or her contacts – business units, senior management, finance – because that’s the only way to keep them involved over the long term.
The first step is to assess the debt and get a picture of it, however imperfect. The aim is not to obtain an exhaustive measurement, but to answer simple, structural questions: what is really expensive today? What presents a short- or medium-term risk? What IS elements can we live with sustainably, without jeopardizing performance or security?
Just like financial loans of varying degrees of soundness, not all technical debt is created equal. Some debts can be controlled, amortized and assumed; others can quickly spiral out of control and become critical. In such cases, it’s up to the CIO to evangelize in order to facilitate informed, nuanced decision-making: an old system can be perfectly virtuous if it’s well urbanized, maintained and aligned with business needs, while a more recent solution can carry a high debt if it’s poorly integrated or not very maintainable.
This ability to qualify debt, rather than demonize it, is essential if we are to move away from simplistic trade-offs and establish a constructive dialogue around IT choices.
5. Changing the way we look at technical debt
Changing the way we look at technical debt means adopting an economic and forward-looking approach to information systems. The representation of the CIO’s Budgets should contribute to this.
When a company takes out a loan, the repayment automatically affects its future financing capacity. The same paradigm must be applied to technical debt: if it is left to grow unchecked, future IS budgets will be encumbered, reducing the company’s ability to invest, innovate and support its strategy.
So the challenge is not just a technological one, but a decision-making one. Taking on debt can be a rational choice, provided it is assumed, understood and steered over time. Conversely, debt that is incurred, invisible or poorly explained inevitably leads to defensive trade-offs, which are often late and costly.
Installing this reading grid enables decision-makers to make informed decisions, by integrating the deferred impacts of their choices on the trajectory of the information system.
Conclusion – From awareness to sustainable management
Technical debt is neither an anomaly nor a failure in itself. It is the natural product of the trade-offs, constraints and choices that mark the life of an information system. What makes the difference between a CIO in control and one under constraint is not the absence of debt, but its ability to understand it, make it visible and steer it over time.
For CIOs, CIOs and PMOs, the challenge is now clear: to move away from a reactive, symptom-focused approach, and adopt structured governance of technical debt, integrated with portfolio management, budgeting and IT performance steering processes.
This is precisely where solutions like Abraxio come into their own. By providing a consolidated view of Projects, trade-offs, costs and value, they make it possible toobjectify decisions, structure dialogue between IT and the business, and put technical debt back on a controlled trajectory, in line with corporate strategy.
Steer technical debt is not about eliminating it at all costs. It’s about restoring it to its rightful place: as a strategic parameter, assumed and governed, serving the sustainable performance of the information system.