Published on 2002, July, 19th in Journal du Net
At a time when the acceleration of digital transformation is unprecedented, the issue of IT debt is becoming a cause for concern for many businesses.
According to a Stepsize report, IT teams spend an average of 33% of their time maintaining
and managing legacy systems, 50% of which is dedicated exclusively to managing IT debt. More than 60% of the professionals surveyed believe that technical debt is the cause of many incidents and slows down the development process.
The
pressure of business as usual, the accumulation of bad individual choices, the lack of communication and understanding between business and IT and the lack of qualification of this debt are four factors that can explain its importance. As a result,
the debt accumulates, its impact is felt and the scope for resolving it is reduced.
To this can be added the difficulty for IT teams to respond effectively to business expectations, creating a progressive misalignment between the
two parties and then a loss of confidence in IT teams. This is a vicious circle that companies need to avoid if they are to meet the ever-increasing demands for responsiveness and scalability, while guaranteeing an optimal user experience.
IT debt and its snowball effect on business activity
The metaphor of IT debt was formulated in 1992 by computer scientist Ward Cunningham. At the time, he was expressing the idea that the development of short-term solutions for IT systems entailed a set of trade-offs that brought with them constraints that
would have to be repaid in the form of engineering tasks. IT debt thus encompasses all deviations from the technological state of the art, whether deliberate or not, which have a harmful long-term impact on IT costs, time-to-market and business continuity.
Many people take the shortcut of equating IT debt with obsolescence, but that's only a tiny part of it.
To be exhaustive, IT debt must include all the other failings of companies:
- Code debt - poor development practices,
- Data debt - deviations in the quality of data hosted in repositories and other sources,
- Skills debt - loss of control over the solution, often amplified by document debt,
- Architecture debt - design errors and lack of knowledge of patterns,
- Urbanisation debt - poor urbanisation choices, or no urbanisation at all.
We can also talk about vulnerabilities, as security debt, because they can have major consequences for business and finances and, more generally, for performance, availability and the user experience. Another key issue for businesses is environmental
debt, which is an integral part of IT debt because of the influence of solution design on the target carbon footprint, for example by limiting the amount of data stored or servers allocated.
Going back to the origin of the metaphor,
IT debt is paid every month with increasingly expensive and time-consuming upgrades and more and more production incidents. Added to this are the procedures and manual actions required to remedy these incidents, as well as a poor experience for customers
and users due to degraded performance and availability. Redesign projects, when they are decided, lead to higher costs than if the debt had been dealt with correctly over time.
Governance and measurement at the heart of a "zero debt" strategy
The prerequisite for getting out from under IT debt is knowing how to quantify and qualify it by putting in place a tool-based approach to measurement and processing. Several founding
principles are at the heart of this approach: a 360° assessment to identify and quantify IT debt in all the forms mentioned above, a business focus to modulate its importance by highlighting the business value of the services affected, and established
communication and education to convince management teams of the priorities for dealing with IT debt with real problems and potential consequences.
This approach is proving effective in developing, validating and launching remediation
plans. It can also be a genuine strategy for the ongoing management of IT debt, with the aim of achieving "zero debt". Google's systemic approach, the Site Reliability Engine, which involves a strong commitment from top management, is based on the definition
of SLOs (service level objectives), a sort of moral contract between the business and IT, and the systemic measurement of these SLOs. Any deviation from the SLO is charged to the teams, and once a certain threshold is reached, development is frozen so
that all efforts can be focused on dealing with the faulty debt. To begin this type of approach, you need to bear in mind the two pillars of a 'zero debt' strategy: governance and measurement. In addition to ongoing measurement, solid governance of IT
debt needs to be put in place, combining central governance with a network of people responsible for each project. This will ensure smooth communication and decision-making. It is essential to have a counterweight when it comes to making technological
choices in the face of relative business priorities, and to set aside regular time to deal with this issue.
Solutions to simplify the handling of this debt have also emerged within companies with a proven 'zero debt' strategy. Thanks
to modern architecture patterns, in particular modular architectures (microservices, containers, etc.), decoupled architectures (APIs, events, etc.) and automated architectures (cloud, observability, etc.), debt can be reduced by breaking it down into
smaller units, which are easier to visualise and process as they arise.
To reduce or even achieve 'zero debt', it is essential to reconcile technical issues with business challenges, and this is the art of enterprise architects and their
experience in the field. In fact, the profession of enterprise architect has evolved considerably in recent years to cover the full spectrum from business to technology, juggling top-down and bottom-up approaches and building powerful points of view adapted
to each type of stakeholder. In the final analysis, this is the missing link if IT debt is to be dealt with effectively.
Back to Sopra Steria Next