Peut-être que l’ancienne technologie n’est pas le vrai problème



En avril 2020, le gouverneur du New Jersey, Phil Murphy, s’est levé vers un micro et a déclaré aux journalistes qu’il était étonné que l’État gère toujours son système de chômage sur COBOL – un langage de programmation vieux de 60 ans. L’État avait du mal à suivre la flambée massive des demandes d’assurance-chômage au milieu des verrouillages pandémiques, et il avait besoin de bénévoles connaissant ce langage archaïque pour utiliser sa propre technologie décrépite!

J’ai écrit une histoire à ce sujet pour notre site Web, et elle est montée en haut de notre classement. Mais c’était plus que cela: les principaux organes de presse le couvraient. Les cabinets de relations publiques m’envoyaient des liens vers ma propre histoire dans des courriers électroniques. C’était partout, et nous avons tous joyeusement trempé sur COBOL parce que – eh bien, c’est de la technologie dont nous parlons. Comment pourrions-nous encore exécuter des systèmes aussi importants sur un code aussi ancien?

Qu’à cela ne tienne, les porte-parole de l’État ont gentiment suggéré plus tard qu’ils avaient en fait suffisamment de programmeurs pour faire fonctionner le système – peut-être, en quelque sorte, sous-entend peut-être que le gouverneur s’était trompé.

Ce n’est pas le propos. Le point est le suivant: trop de gens avaient envie d’attaquer COBOL parce qu’il est vieux. Et non seulement cette démangeaison est mauvaise, mais c’est aussi une attitude beaucoup trop répandue qui détourne les besoins les plus urgents.

William Malik, vice-président des stratégies d’infrastructure chez Trend Micro et un vétéran de longue date de COBOL et de la technologie d’entreprise, l’exprime ainsi: «[New Jersey is] probablement avec une machine de 10 à 15 ans, pour à peu près la même raison que je conduis une Audi 2006: ça m’amène là où je dois aller, je n’ai pas besoin d’aller plus vite, c’est parfaitement sûr, je le garde entretenu et je sais comment le conduire.

Selon Malik, ce qui a probablement causé les problèmes dans le New Jersey n’était pas lié aux langages de programmation, mais concernait plutôt la puissance de traitement ou la mémoire.

En d’autres termes, il s’agissait de l’offre et de la demande. Le système a été conçu pour traiter un nombre normal de demandes de chômage, mais il a existé à un moment qui était tout sauf normal.

Avant d’aller plus loin, exposons quelques faits de base. COBOL a été développé vers 1960 en tant que premier langage de programmation traitant des abstractions. Autrement dit, il permettait aux développeurs de donner des commandes aux ordinateurs dans un langage simple. Il est orienté vers les fonctions commerciales et gère toujours bon nombre des systèmes financiers les plus importants du monde, y compris l’IRS et les géants bancaires. Il y a des centaines de milliards de lignes actives de celui-ci, et ce nombre augmente avec le temps, pas de diminution.

Pour cet article, j’ai sollicité les conseils de plusieurs experts en plus de Malik. J’ai parlé avec Marianne Bellotti, une ancienne du service numérique américain qui travaille maintenant pour la société de technologie Rebellion Defence; Steve Brothers, directeur de l’exploitation du logiciel de changement de phase; et le RSSI de Pennsylvanie Erik Avakian. Ils avaient beaucoup à partager, et j’aimerais pouvoir tout mettre ici.

Au lieu d’une transcription, voici quelques points sur lesquels ils s’entendent: Malgré son âge, COBOL reste le bon choix pour certaines tâches.

« Il a été conçu pour effectuer un traitement par lots de données, en particulier un traitement de données basé sur le calcul », a déclaré Bellotti. «Donc, si vous rencontrez un problème qui ressemble à celui-là, il existe de nombreuses autres technologies que vous pourriez utiliser qui le serviraient bien, mais vous pouvez également choisir COBOL, vous pouvez également utiliser un mainframe, ou vous pouvez simplement utiliser le mainframe et Python, Qu’avez vous. »

Autre accord: COBOL n’est pas vraiment un problème de sécurité.

«COBOL ne présente aucun problème de sécurité car il ne parle vraiment à aucune ressource», a déclaré Malik. «Il dit simplement« lire »ou« écrire ».»

S’il y a des problèmes de sécurité concernant les applications COBOL, ils ont plus à voir avec l’architecture informatique et la main-d’œuvre qu’avec le fait qu’elles sont écrites en COBOL.

«Les défis associés aux technologies et aux logiciels plus anciens, tels que COBOL, peuvent inclure l’application de mises à jour de sécurité et d’approches modernes de cryptage et d’authentification des données, telles que l’authentification multifacteur», a écrit Avakian dans un e-mail. «De plus, le personnel informatique qualifié dans ces technologies et logiciels est devenu de plus en plus rare dans la main-d’œuvre, ce qui les rend plus risqués à entretenir et à mettre à jour.»

Et oui, parlons de la main-d’œuvre. Chaque année ou deux, Internet fait la une des journaux sur les sondages expliquant comment tel ou tel pourcentage de personnes qui connaissent COBOL approche de l’âge de la retraite. Le problème, comme le souligne Bellotti, est que l’âge moyen des programmeurs COBOL ne change pas beaucoup au fil du temps – en 2006, une enquête de Computerworld a révélé que l’âge moyen des programmeurs COBOL était de 45 à 55 ans, et en 2020 un Une enquête de Micro Focus a révélé que l’âge moyen des programmeurs COBOL était de 50 ans. Gartner estime que le nombre total de programmeurs COBOL diminue chaque année, et pourtant des entreprises comme Micro Focus et IBM en forment des milliers chaque année.

Il y a un problème sérieux avec les talents qui prennent leur retraite, mais encore une fois, ce n’est pas unique à COBOL. Le problème est la connaissance institutionnelle – lorsque les personnes qui ont rédigé une demande il y a 20 ans partent, les autres ne connaissent souvent pas l’application avec quelque chose de proche de la même intimité. Et depuis le moment où ils ont écrit le programme pour la première fois, il s’est souvent métastasé: de nouvelles fonctions ont été développées, ont rempli de nouveaux cas d’utilisation, sont entrées dans de nouvelles agences. C’est donc beaucoup plus grand et plus complexe, et les gens qui ont tout compris sont sortis.

«Le développeur qui comprend un langage de programmation, s’il a affaire à une très petite quantité de code, peut résoudre le problème et le résoudre assez facilement», a déclaré Brothers, dont la société travaille sur ce problème précis. «Le problème est que vous avez affaire à des millions de lignes de code et que personne ne sait par où commencer.»

Alors, qu’est-ce que cela nous coûte réellement de trop nous concentrer sur COBOL? En grande partie, du temps et des ressources qui auraient pu être mieux dépensés ailleurs. Voici une expérience de réflexion de Malik: disons qu’une agence informatique prend une application COBOL et recrée le tout dans une autre langue.

«Si vous prenez un morceau de code fonctionnel et que vous le réécrivez dans une autre langue, vous devez maintenant tester à nouveau tout le smash», a-t-il déclaré. «Et à la fin de la journée, ce que vous avez maintenant, c’est un nouveau programme qui fait exactement la même chose que l’ancien programme, et vous vous asseyez et vous dites: ‘Pourquoi ai-je dépensé mon argent pour ce projet? N’ai-je pas d’utilisateurs qui souhaitaient une nouvelle interface? Est-ce que je n’avais aucune unité commerciale qui se battait à la porte pour une nouvelle application? »

Pendant ce temps, nous avons des violations de la cybersécurité dans tout le pays à tous les niveaux de gouvernement, fermant les services publics, coûtant de l’argent et transmettant des renseignements à des gouvernements étrangers. Et les citoyens ont encore du mal à naviguer dans les demandes de prestations. Et la saisie manuelle contribue toujours à l’erreur humaine dans de nombreux travaux gouvernementaux.

Donc, avant d’inventorier votre catalogue COBOL, avez-vous pensé aux failles de sécurité dans votre chaîne d’approvisionnement? Votre middleware? Comment se déroule ce programme de correctifs? Utilisez-vous une technologie non prise en charge?

Et oui, il y a des moments où il est logique de déplacer quelque chose hors COBOL. Mais si vous voulez faire cela, il est probablement préférable de penser de manière holistique, dans le sens de la transformation de l’architecture. Comme le dit Bellotti, la question que vous voudrez peut-être vous poser est la suivante: si vous deviez recommencer aujourd’hui, comment le feriez-vous?

«J’insiste beaucoup sur l’utilité de l’utilisateur et la valeur ajoutée avec les projets de modernisation», a-t-elle déclaré. «Nous n’abandonnons pas simplement la technologie parce qu’elle est ancienne; nous abandonnons la technologie car il existe un meilleur outil pour faire le travail dont nous avons besoin. »

Ce n’est pas parce qu’il est vieux que c’est mauvais – n’est-ce pas la vérité.


Ne manquez jamais une histoire avec la newsletter quotidienne de Govtech Today.

S’abonner




Laisser un commentaire