Les coûts des systèmes hérités (2018)

English

Un système hérité (legacy), c’est un logiciel, un ordinateur, un périphérique de stockage encore utilisé mais qui est devenu obsolète. Il n’est pas forcément très vieux, ce peut être par exemple une version de logiciel datant de quelques années qui n’est plus supportée par son vendeur. Cependant, les cas les plus frappants sont ceux de systèmes au fonctionnement stratégique pour une entreprise ou institution, souvent développés sur mesure, qui font appel à des technologies logicielles ou matérielles complètement dépassées.

Des technos qui ne veulent pas mourir

Aussi incroyable cela peut-il paraître, de grandes entreprises et institutions ont encore des programmes vitaux en COBOL qui tournent sur des ordinateurs centraux (mainframes). Les développeurs de ces programmes sont probablement déjà morts, le code spaghetti est peu ou pas documenté, mais ça fonctionne toujours. De vénérables responsables IT vous diront que ce sont des systèmes très sûrs, vous expliquant que ce sont souvent des ordinateurs peu exposés à l’internet et qu’aucun hacker ne connaît COBOL. Même si la sécurité par l’obscurité n’est pas reconnue comme la meilleure, on veut bien croire qu’il y a peu de pirates inspirés par le langage et les systèmes d’exploitation associés comme z/VSE, z/OS et VME. COBOL est en effet un langage de 1959 qui est en état de mort cérébrale depuis le bogue de l’an 2000. Les programmes sont monolithiques et ont des capacités d’évolution proches de zéro. C’est horriblement coûteux à maintenir et d’un avenir très incertain, ne serait-ce que parce que les bons programmeurs COBOL, qui sont parmi les mieux payés de tous les professionnels du développement, se font vieux et qu’il n’y a aucune relève (à ma connaissance, aucun jeune ne rêve de devenir coboliste et la discipline n’est de toute façon plus enseignée).

Des systèmes antiques

En juin 2015, le bureau de gestion du personnel fédéral américain (Office of Personnel Management) s’est vu voler des données touchant plus de 20 millions d’anciens et actuels employés sous contrat avec le gouvernement fédéral. L’enquête a révélé que le logiciel de l’ordinateur central qui héberge la base de données, vieux de 30 ans, était écrit en COBOL et qu’il était « techniquement trop obsolète pour chiffrer les renseignements personnels ». Comme quoi ces systèmes antiques posent bel et bien des problèmes de sécurité…

En 2016, on apprenait grâce au Government Accountability Office, organisme chargé du contrôle des comptes publics du budget fédéral des États-Unis, que l’un des plus vieux investissements fédéraux en IT encore en fonctionnement était le Système automatisé de commandement et de contrôle stratégique (SACCS) destiné à coordonner les fonctions opérationnelles des forces nucléaires. Ce système tourne encore sur des ordinateurs IBM Series/1 des années 70 et le stockage se fait sur des disquettes 8 pouces.

En avril 2018, le site web des impôts fédéraux (IRS) est tombé en panne le dernier jour de déclaration des revenus. Le problème était que le fichier maître individuel (Individual Master File), le système qui stocke toutes les informations fiscales des citoyens, ne répondait plus aux requêtes. Ce système, composé de 20 millions de lignes de code assembleur, a été développé quand John F. Kennedy était président. Les autorités prévoient de le remplacer en 2022, après plus de 55 années de service, mais comme Donald Trump a amputé le budget de l’IRS de 239 millions de dollars, rien n’est moins sûr.

IBM System/360.
Ordinateur central IBM System/360 au centre informatique des Jeux olympiques d’hiver de Grenoble, janvier 1968. Photo Ron Kroon/Anefo. Archives nationales néerlandaises.

Les coûts des systèmes hérités

Entretenir des systèmes de plus de 20 ans, voire de plus d’un demi-siècle, coûte de plus en plus cher. Les spécialistes de COBOL ou Fortran, les vétérans capables d’écrire en assembleur et les ingénieurs maîtrisant les vieux mainframes sont des gens de plus en plus rares, donc de plus en plus demandés et de plus en plus coûteux. La maintenance des plateformes matérielles, dont parfois le constructeur a disparu depuis longtemps, relève aussi du défi dont les solutions sont toujours onéreuses.

Ces systèmes sont généralement vitaux pour les entreprises (c’est ainsi souvent la raison pour laquelle ils sont maintenus coûte que coûte), et la moindre panne peut donc avoir des effets douloureux. Quand le vieux système informatique de gestion des réservations de la compagnie aérienne Delta a crashé en 2016, c’est toute sa flotte d’avion qui a été clouée au sol et ça lui a coûté plus de 150 millions de dollars. Des millions qui auraient sans doute mieux été investis dans la modernisation, la redondance et la sécurisation de son infrastructure. Une mésaventure du même genre s’était produite en 2004 chez Comair, une filiale de Delta. Le logiciel d’affectation des équipages, programmé en Fortran (alors que personne ne maîtrisait ce langage au service IT de Comair), s’était bloqué en raison d’une limitation inconnue de toute personne travaillant dans la compagnie. 3 900 vols durent être annulés et près de 200 000 passagers restèrent bloqués en pleine période de Noël. Le vieux logiciel était limité à 32 000 changements d’affectations par mois. Cette limite n’avait jusqu’alors jamais été atteinte, mais une tempête de neige historique les 22 et 23 décembre avait entraîné des modifications inhabituellement nombreuses. La limite atteinte, le logiciel s’est bloqué de lui-même le 25 décembre. Après ce ratage monumental, le président de Comair, Randy Rademacher, fut poussé à la démission en janvier. Le remplacement du système legacy par un logiciel de Sabre Airline Solutions avait été approuvé en 2003, mais fin 2004, il n’avait toujours pas eu lieu. C’était le dernier système qui fonctionnait encore sur l’ancienne plateforme IBM AIX de la compagnie aérienne (toutes les autres applications fonctionnaient sous HP Unix). Les conséquences négatives sur l’image de marque de l’entreprise furent importantes et durables.

Aussi, avec un système obsolète, la moindre modification fonctionnelle ou intégration avec un autre système plus moderne demande un temps exagéré, quand elle est possible, ce qui n’est pas toujours le cas. Ces systèmes sont souvent peu ou pas évolutifs, ce qui oblige d’y accoler d’autres couches technologiques pour répondre à la demande. Le résultat est alors en un système encore plus complexe et donc fragile. Il est en outre fréquent que ces systèmes aient des vulnérabilités en raison de technologies dépassées ou de manque de support.

Il faut également voir que tous les coûts ne sont pas directement inscrits dans la comptabilité. Comment chiffrer la perte de l’agilité, de la capacité de changer et de s’adapter à un contexte en perpétuel changement ? Comment évaluer le manque de compétitivité ? Que coûtent les données stratégiques qu’on ne peut pas obtenir parce que le système est incapable de les extraire ? Combien de points de croissance perdus ? De clients insatisfaits qui partent voir la concurrence ? Etc.

La plus grande partie du budget fédéral américain dédié aux technologies (80 milliards de dollars) est consacré au maintien de systèmes hérités. Les agences fédérales emploient encore plus de 1 000 développeurs en COBOL et 600 en Fortran. Quand une entreprise consacre 60 à 80 % de son budget IT dans la maintenance de systèmes hérités, elle le fait au détriment de l’innovation et du futur. Il reste en effet peu de temps et d’argent à faire autre chose que poser des rustines plutôt que de préparer l’avenir. Et on ne peut parler de modernisation quand on commence à bâtir un système de remplacement, ce qui est souvent une opération lourde et complexe, toujours longue. La modernisation effective ne se fait qu’au moment où l’on débranche le vieux système. Quand on ne peut consacrer que 20 % de son budget IT aux efforts de modernisation, cela prend encore plus de temps… Bref, avec des systèmes obsolètes, on s’enferme dans un cercle vicieux.

Souvent, la bonne décision est d’investir massivement pour pouvoir débrancher rapidement un système qui survit sous perfusion. En matière d’IT, même si cela fait un peu peur et que le risque zéro n’existe pas, il est parfois plus que temps de sortir la hache. Le retour sur investissement se fera inévitablement, au moins sur le moyen/long terme. D’autre part, il faut bien savoir que les systèmes modernes sont conçus avec un meilleur souci de l’évolutivité et sont plus modulaires, ce qui rendra plus facile et moins onéreux de les maintenir au goût du jour ou de leur faire effectuer une transition technologique.


The cost of legacy systems

A legacy system is any software, hardware, or storage peripheral that is still in use despite being obsolete. And it doesn’t have to be that old; for example, it could be a version of a software that’s just been out a couple of years but no longer supported by the supplier. Worse yet: sometimes, a company’s or institution’s most strategic system, which is often tailor-made, runs on hardware or software that have become outdated.

Some technologies die hard

Strange but true: to this day, some major enterprises and institutions rely on crucial programmes that were developed in COBOL and run on mainframes. These programmes have probably outlived their programmers, the spaghetti code is probably undocumented, but hey, it still works! CIOs swear that these systems are 100% secure, explaining that they are not Internet-enabled, and today’s hackers don’t know COBOL. And though security through obscurity isn’t a best practice, it is true that few hackers are inspired by COBOL and its attendant operating systems, like z/VSE, z/OS and VME. In fact, COBOL, born in 1959, has been vegetating in a coma since Y2K. COBOL programmes are monolithic and their ability to evolve is zero to nil. Besides, COBOL programmes are incredibly expensive to maintain and their future is uncertain, if only because good COBOL programmers, the highest-paid development professionals around, are getting on in years, and are not being replaced. As far as I know, no young programmer dreams of learning COBOL one day. In any case, it’s no longer taught in school.

Antiquated systems

In June of 2015, hackers targeted the American Office of Personnel Management, making off with data pertaining to 20 million current and former federal government contract workers. The ensuing investigation revealed that the software on the mainframe that hosted the database was 30 years old, written in COBOL, and “too obsolete from a technical standpoint to encrypt personal information”. Which shows that these ancient systems do indeed pose security problems...

In 2016, the Government Accountability Office, the organisation responsible for auditing the United States’ federal budget and accounts, stated that one of the federal government’s oldest investments still in use was the Strategic Automated Command and Control System (SACCS), a system to coordinate the operational functions of US nuclear forces. This system is still running on 1970s-era IBM Series/1 software and 8-inch floppy disks.

In April 2018, the IRS Web site crashed on the last day of filing. The problem was that the Individual Master File, the system that stores taxpayers’ tax data, stopped responding to queries. This system, made up of 20 million lines of assembler code, was developed when John F. Kennedy was President. It is set to be replaced in 2022, after 55 years of service, but that remains to be seen, since Donald Trump has slashed the IRS’s budget by US$239 million.

IBM System/360.
IBM System/360 mainframe computer at the Grenoble Olympic Winter Games computing centre, January 1968. Photo Ron Kroon/Anefo. Dutch National Archives.

The real cost of legacy systems

Maintaining 20-year-old or even 50-year-old systems is increasingly expensive. COBOL and Fortran specialists, old-school coders able to write assembler code and older mainframe engineers are thin on the ground, and therefore in high demand and expensive. And that’s not counting the hardware platform, often supplied by long-gone builders, adding to the complexity and expense of the problem.

Despite their shortcomings, these systems are often vital to a company, which is why they’re being preserved at all costs. Therefore, their slightest hiccup can be extremely painful. When Delta airlines’ old reservation management system crashed in 2016, its entire fleet was grounded. The US$150 million dollars it cost the company would have been far better spent on infrastructure modernisation, redundance and security. Comair, a subsidiary company of Delta, went through a similar experience in 2004. In that instance, the crew dispatching software, written in Fortran (a language that nobody knew in Comair’s IT department), froze for unknown reasons. Some 3,900 flights had to be cancelled, leaving 200,000 passengers stranded during the Christmas rush. It turns out that the software was limited to 32,000 schedule changes per month, a limit that had never been reached before. However, a record-breaking snowstorm on December 22 and 23 caused innumerable changes, causing the software to hit its limit and shut down on 25 December. After this embarrassing gaffe, Comair’s President, Randy Rademacher, was forced to resign. In fact, the replacement of the legacy system by Sabre Airline Solutions was approved in 2003, but at the end of 2004, it still hadn’t been rolled out. This was the last system that still ran on the airline’s ancient IBM AIX platform (all other applications ran on HP Unix).

With an obsolete system, the slightest functional change or its integration in any modern system takes an insane amount of time, when it is even possible. The problem with these systems is that they’re rarely scalable, meaning that they have to be complemented by yet another technology layer to meet current needs, resulting in a complex and delicate balancing act. And these systems are often vulnerable due to obsolete technology or unavailable support.

Further, the real costs of these systems cannot always be estimated. For example, how do you quantify loss of agility, or the inability to change and adapt to an evolving environment? How do you value lack of competitiveness? What is the opportunity cost of strategic data that you just can’t obtain because the system is unable to produce them? How do you know how much growth was missed? How many clients were lost to the competition? Etc.

The greater part of the IT-related federal budget of the United States (US$80 billion) goes to maintaining legacy systems. Federal agencies still employ over 1,000 COBOL and 600 Fortran developers. Companies that spend 60 to 80% of their IT budget on maintaining legacy systems do so at the expense of innovation, since there is precious little time or energy left to prepare for the future once you’ve finally finished installing patches. And you just can’t consider modernizing until you build a replacement system, which is a long and costly operation. Real modernization happens when the old system is unplugged; but when you can only spend 20% of your budget on modernization, things move even more slowly. In other words, obsolete systems drag you into a vicious circle.

Often, the right decision is to make massive investments to quickly and mercifully unplug a legacy system that has been on life support for years. Of course, this is always a scary move, and there is no such thing as zero risk; but sometimes, drastic measures are called for. The return on investment is assured over the medium and long terms. Besides, modern systems are developed with an eye to upgradability and scalability, making them easier and cheaper to update or migrate to a new technology.