Despite a growing awareness in companies and administrations, the risks linked to the obsolescence and modernization of IT and digital systems are still too often underestimated by decision-makers – and this despite the efforts of IT departments.
Considered costly, time-consuming and resource-intensive, managing the obsolescence of the information system (and recent digital investments!) is nevertheless a major challenge, as it enables you to protect yourself against critical risks (access to data, availability of services, cybersecurity, etc.).
It is therefore essential to manage this phenomenon so as not to find oneself having to suddenly manage a significant debt.
Tackled with method and regularity, this approach – which is complex because it requires a cross-functional approach to the organization – gradually moves from being a constraint to being a habit and then a good practice.
How to define IT obsolescence?
Originally used more in the software world (see this Wikipedia article) to evoke the evolution of different functionalities and introduce notions such as backward compatibility, obsolescence has gradually encompassed all aspects of an information system and has become a metaphor inspired by the concept of financial debt.
It is made up of all the digital assets whose maintenance in operation constitutes a significant risk; its perimeter can therefore be very broad, and affect hardware, software, middleware, storage media (see the Museum of obsolete media for an overview of the state of obsolescence of each type of information recording medium – whether musical, video or computer), methods/practices, human resources – and even the culture. Some examples: loss of skills, documentation not updated, unavailable maintenance leading to the absence of patches, technologies at the end of their life, practices or methods replaced by others more widespread or considered more efficient.
It can be visible, or even chosen: we then speak of “deliberate”, “intentional” or “voluntary” debt. This means that the organization is aware of it and is (more or less) ready to assume the consequences later. It responds to a present need, such as speed or cost or value produced. Being aware of it allows one to limit the risk of this debt and to plan for its repayment.
The invisible debt, or involuntary debt, is linked to errors, lack of knowledge, an uncontrollable factor or poor design. Its impact and the risks associated with it were not anticipated.
More broadly, we refer to obsolescence or technical debt when an organization encounters difficulties in making its information system components evolve naturally. And like a debt in the financial sense, it will have to be repaid sooner or later! A well-managed debt does not pose a problem, unlike an out-of-control debt that can lead to serious difficulties.
Today’s organizations have to stay in constant motion, which implies a very regular upgrade of their IS: the more the environment changes, the faster the debt arrives and penalizes those who choose a more measured pace than their competitors.
What are the causes?
There are of course many causes, each contributing to a different degree and according to the organization, to the growth of the debt. To make it easier to understand, we usually distinguish two main types:
The so-called exogenous causes, because they are external to the organization:
- The passage of time itself: aging of assets and resources, wear and tear, natural evaporation of knowledge. Inexorable but anticipatable!
the commercial and/or industrial policy of suppliers: cessation or evolution of products/services, buyouts/sales of an activity, disappearance. Adapted strategies allow us to minimize these changes over which we have no direct control.
changes in regulations and standards that can quickly make a system obsolete because it is complicated to change for various reasons; but here we are dealing with endogenous causes (architecture, technological choices, team capacity, budget, etc.): see below.
changes in practices, technologies, threats, and customer needs; here, choosing not to evolve at the same pace means starting to lose ground – at first in a barely visible way; the necessary catching up will be all the more painful and costly as the years go by.
Endogenous causes, specific to choices (or non-choices), whether daily/operational or strategic, deliberate or not:
- insufficient awareness of the long-term impact of current choices; future obsolescence is both evoked and taken into account in decisions (cf. the argument often put forward of “scalability”), while finally being little implemented operationally; perceived scalability can even have a counter-productive effect by pushing not to invest regularly, the solution being scalable (without anyone really knowing what this means).
- Inappropriate financing – whether in the build phase (thus causing choices that push tasks or deliverables to “later” and lowering quality) or in the run phase (reducing evolutions, preventive maintenance, monitoring) – has a direct impact in the medium term. It is tempting of course, as the expected gains are short-term. Overall, the global financial balance of this type of decision remains unfavorable, but it is not often the priority of the moment (beware in particular of cost-killing or sale of an activity).
- Tight deadlines can also lead to shortcuts or quick-wins that are not really quick-wins: incomplete design, loss of quality due to overly rapid testing, insufficient documentation, sloppy or absent transfer of skills: whatever the team, the pressure will lead to faster or easier solutions that will probably be less advanced; of course, the solution that has been built will work, but what will it be like in 3 to 5 years when the teams and the technology have changed.
- Inadequate skills and organization: the debt can also come from the project stakeholders themselves, with a lack of know-how and skills, the selection of team members not being in line with the project’s needs. An organization, methods, and tools that are out of step with the needs of the project can generate grey areas in a project, leading to difficulties and accelerated obsolescence.
- Finally, one should not underestimate the complexity of a project, a solution or a technology – in both directions: by defining a solution with an overly simple architecture or, on the contrary, by overestimating a need (“gas factory” effect). A thorough knowledge and an adapted challenge of the needs allows to limit these halos.
- Adopting new technologies too quickly or too slowly: in one case, they may not deliver all the expected promises (resulting in ultra-rapid obsolescence), in the other case, they may be almost obsolete when they enter the organization (with an almost immediate transition to obsolescence management).
- Dependence on solutions that are not widespread or diversified (level of competition, alternative technological choices) accelerates the build-up of debt and hinders the development of management scenarios. This type of choice only makes sense when the added value produced is far greater than the present value of the investments to be made in the future to change this solution.
What are the areas covered by obsolescence management?
Obsolescence management represents all of the activities that need to be carried out in order to first identify, remedy and then prevent uncontrolled aging.
Because, like time, the latter is inescapable: it therefore requires anticipation, especially in a globalized, interconnected and constantly evolving world; if it could be envisaged just a few years ago, the “freezing” of a significant part of an IS has become almost impossible today: everything is constantly changing and not evolving means being rapidly outdated.
Having freed itself from its origins linked to application development, the notion of obsolescence management must be approached in a global manner; to speak of debt, there are multiple facets; here are some examples
- infrastructure (systems, networks, storage, tools), which generates performance, availability, maintenance and security limits. Not to mention the growing complexity, the difficulty of finding competent resources for old technologies, and the additional costs of support, operations and licenses.
- applications: applications abandoned by their publisher, economic model slowing down version upgrades (purchase of licenses to go from v1 to v2 without any real need except for the publisher’s discontinuation of v1), poorly documented “in-house” applications, lost know-how.
- middleware: this is probably one of the most insidious, because it is very buried (database management systems, small software programs that have become indispensable, critical data exchange buses, systems for exchanging data with the outside world, software frameworks, etc.); they usually work without being visible, so they are forgotten, while their updating can be particularly complex and their shutdown can disrupt a large part of the organization.
- architecture: old designs, not very modular, outdated languages, strongly coupled applications, etc. are all sources of degradation of functionality, performance and reliability.
- method / tools: the use of outdated or inappropriate methodologies (conception, project management, product design, operations, but also budget and financial management), reinforced by the use of old tools, can lead to slow evolution and/or decisions taken too late or in the wrong direction. The quality of the code, documentation/specifications, parameterization/installations – in short, the deliverables – is key to the future: this must be verified by regular, ideally automated tests (code, pentests, etc.) so that they can be systematically performed for each evolution – even minor ones. The non-detection (or non-treatment) of defects feeds the technical debt.
- skills: particularly in the IT and digital domains, skills and organization management is a key area: identifying and maintaining key know-how, acquiring and renewing knowledge, updating documentation, inventorying/sourcing expertise, balancing novelty and maturity, internalization and outsourcing, intergenerational sharing (the youngest employees are interested in mature technologies, and vice versa), and making room for training (and above all for self-training and labs for those who want them).
What practices should be implemented?
Our experience in technological and organizational consulting for clients with a wide range of profiles (from very small companies to large accounts, including governmental organizations and start-ups) has allowed the emergence of good practices that we share below. Here, there is no magic recipe or miracle solution! It is essentially a matter of regular, methodical, in-depth work – supported by the allocation of a sufficient level of skills and resources:
- Simplicity: even if it is sometimes necessary, the complexity must be justified and its choice perfectly enlightened. It is sometimes enough to remove or limit the ambitions of a specification or an expression of need to greatly reduce it. Simple watchwords applied with discernment such as KISS (in its interpretation “Keep It Super Simple”), or the application of a method as fundamental as “MoSCoW” (Must, Should, Could, Wish) allow to avoid prejudicial and debt-creating drifts.
- Sobriety: as we mentioned in our ITx Café #7 entitled “For a more sober digital world”, the measured use of digital technologies also has the virtue of limiting the complexity of their future evolution and limiting the speed of their obsolescence. This frees up capacity for reinvestment.
- Visibility: what is visible can be understood and managed; this requires a continuously updated inventory of digital assets of course, but also of skills and know-how. And by organizational models that encourage the sharing of information and the highlighting of difficulties as well as successes.
- Knowledge: no more documentation and transfer of competencies thought of in the project phase as one task among others, rather placed at the end and quickly dispatched! Like cybersecurity, documentation and commitment of future run teams is done at the start and then on an ongoing basis; documentation is done during coding, customization or parameterization and is updated throughout the project. The provision of easy-to-use tools is key to the appropriation by the teams.
- Culture: moving from a “project” to a “product lifecycle” approach naturally introduces the notion of updates and end of life of a system. Obsolescence management is then naturally integrated and is no longer a separate subject, which avoids focusing solely on new needs at the expense of the evolution of the existing system, at the risk of its aging.
- Temporality: as it is illusory to think that an organization can erase its technical debt in three months, obsolescence management must be a continuous effort: the reduction of technical debt is done progressively (inventory, risk assessment, remediation plan), and its reconstitution – chosen – is also managed over time.
- Finance: more technical, but accessible to the curious or to IT management control: the comparison between short-term savings and the estimated net present value of reinvestments to be made in 3/5/10 years allows a factual dialogue on the real financial stakes.
The progressive implementation of these practices not only allows us to stop adding to the mountain of debt in front of us, but also allows us to reduce the existing debt as we renew our systems with solutions that have natively taken their obsolescence into account.
The ultimate benefit: the methodical, regular and preventive management of endogenous factors makes it possible to free oneself almost completely from a debt that is suffered, which makes it possible to make the informed choice of a chosen/piloted debt while reserving sufficient leeway to calmly absorb events that are exogenous to the organization. All this in a controlled budgetary and risk context.
To continue the reflection :