Raincode blog

Dépendance des Entreprises aux Mainframes: Une Dette Technique ?

Posted by admin raincode on Jan 14, 2016 10:21:27 AM

 

Par Alex Huart, Chief Evangelist Officer chez Raincode

 

Durant plusieurs décennies, tout le monde s’est posé la question du divorce de l’entreprise avec son mainframe et son code legacy. La désillusion fut grande car il s’est avéré impossible de rompre trente ans de vie commune sans d’insupportables conséquences.

On a donc admis comme une évidence, notamment pendant les quinze dernières années, qu’il fallait continuer à payer le prix fort pour maintenir l’exploitation du backoffice. Il est temps de revoir cette position et d’évaluer les nouvelles technologies permettant de balayer le dogme mainframe-legacy-argent.

 

Dette technique ?Alex_transp.png

 

Dès le début des années 80, les mainframes semblaient vivre leurs dernières heures. Trop encombrants, trop chers, trop compliqués. Les années 90 ont ainsi vu naître un grand nombre de chantiers pour diminuer la place de ces équipements au sein des services informatiques des grands organismes publics et entreprises privées. Le résultat : un échec. En effet, les compétences relatives à ces machines particulièrement complexes se faisaient alors de plus en plus rares : une documentation quasi inexistante, un personnel vieillissant, peu d’attrait des jeunes ingénieurs pour ces technologies dépassées à l’heure de l’émergence d’Internet, etc. Aboutir à l’isofonctionnalité en migrant sur des équipements modernes s’est révélé un casse-tête inextricable à l’époque. Pour achever le scénario, l’épouvantail « bug de l’an 2000 » finit par pousser définitivement les DSI à abandonner ces projets.

 

Pourtant, personne ne serait en mesure de remettre en question le fait que l’ensemble des activités informatiques critiques sont encore aujourd’hui hébergées sur des mainframes et que la grande majorité des programmes associés sont écrits en COBOL, PL/I et autres langages obsolètes. Alors, sommes-nous pieds et poings liés ? Il serait tout à fait contre-productif de considérer cet état comme un fait irrémédiable et de simplement se contenter de faire avec cette soi-disant dette technique. Le fatalisme est un luxe que la pression budgétaire et le manque de flexibilité de ces systèmes mainframe rendent inopérant.

 

Dépenser de l’argent pour investir dans le futur ou pour s’acquitter d’une dette technique ?

 

Nombreux sont ceux qui prônent l’isofonctionnalité par la réécriture : réécrire son patrimoine applicatif dans un langage moderne. Cela pourrait sembler être LA bonne idée : se débarrasser enfin des passifs archaïques pour passer à Java ou C#. Mais cette opération prend beaucoup de temps, coûte cher, et peut être dangereuse, voire inutile. En effet, il est ici question de millions de lignes et il est impossible d’arrêter ces grands systèmes pour de longues périodes. Trop d’applications critiques et essentielles en dépendent. De plus, quels bénéfices y aurait-il à réécrire ces programmes en répliquant les bugs, voire en en générant de nouveaux ? Quel intérêt aurait un entrepreneur du bâtiment à reconstruire un immeuble neuf, mais en conservant les défauts de l’ancien ?

 

Comment ne pas subir cette situation, mais plutôt en profiter ? Comment optimiser son SI et tirer profit de cet état de fait ?

 

La réponse : ne pas toucher au code source, mais le confier à des compilateurs, dans un processus de rehosting. Les compilateurs permettent de transformer un langage structurel en langage machine. Le rehosting complète la démarche en migrant les bases de données ou les moniteurs transactionnels vers des outils plus actuels ou des émulateurs. Il affiche ainsi des atouts techniques et financiers qui ont le mérite supplémentaire de rassurer les marchés.

 

Ce processus ne présente aucun risque technologique s’il est réversible, puisque le code originel, et donc fonctionnel, n’est pas altéré. Il peut être recompilé et dupliqué sur une nouvelle machine, en conservant le mainframe en parallèle. De cette manière, l’entreprise s’assure une continuité de service, avec la possibilité en prime de pouvoir transférer ses programmes progressivement, de corriger le code source au fur et à mesure, de revenir en arrière si nécessaire, et ce, sans interruption et sans risque. De plus, cela coûte beaucoup moins cher et lui permet d’investir les économies réalisées dans de nouveaux développements.

 

Avancer pas à pas

 

Pour y parvenir, plusieurs étapes sont indispensables:

  • Une phase d’inventaire, pour collecter les métriques du système (taille, complexité, couverture des fonctionnalités des plateformes techniques) ;
  • Relever les erreurs et supprimer le « code mort » ;
  • Construire un plan d’action et procéder progressivement ;
  • Imaginer de nouvelles pistes pour le code de destination.

La réversibilité, la continuité de service et le faible coût du processus de rehosting évolué sont des gages de stabilité pour l’entreprise. Il faut désormais considérer les systèmes legacy comme des sources d’optimisation potentielles et les faire vivre avec des risques maîtrisés et des ressources humaines disponibles, sans révolution.

 

Plus d'informations sur le compilateur Raincode:

 

 RAINCODE COBOL FOREVER FREE

Topics: .NET, Rehosting, Stack, mainframe, COBOL, PL/I, compilers