Gérer les obsolescences : Réduction de la dette technique… et des factures !
La présence d’obsolescences sur les patrimoines applicatifs de nos clients mainframe est une constante.
Nous y trouvons toujours, je dis bien toujours, des technologies anciennes qui auraient dû être décommissionnées il y a déjà longtemps.
Si je risquais un mauvais jeu de mot, je parlerais d’Obsolescence Programmée.
Programmée par les informaticiens que nous sommes.
On trouve en masse et dans le désordre :
- Des gestionnaires de données des temps anciens tels que VSAM (Fichiers Séquentiels Indexés), DL1 ou IMS (Bases hiérarchiques) , IDMS (Base réseau) ou pire encore des gestionnaires de données maison, inventés il y a longtemps, par des techniciens trop intelligents.
- Des L4G antédiluviens : TELON, CSP, EGL, PACBASE, … dont on ne sait pas se passer,
- De l’Assembleur dont plus personne ou presque ne sait comment cela marche ou ose y toucher,
- Des environnements vieillissants tels que IDEAL DATACOM,
- Des Générateurs de code ou de JCL maisons,
- Des Utilitaires : SPITAB, EASYTRIEVE, EARL…
- Etc.
Qui ne rêve pas d’avoir un patrimoine standard COBOL, CICS, DB2, JCL et de pouvoir utiliser des outils de développement standardisés et modernes ?
Et mon COBOL, docteur ?
Sur le COBOL aussi, on trouve souvent des choses à redire.
Quelques questions à se poser :
- Avez-vous fait la migration vers COBOL V6 ?
- Êtes-vous certains que tous vos programmes, s’ils devaient être recompilés aujourd’hui, fonctionneraient à l’identique ?
- Combien avez-vous de composants inutiles dans vos bibliothèques ?
- Et combien de lignes de code mort dans vos programmes ?
Même si on n’a pas prévu de quitter son mainframe tout de suite i, engager un projet de suppression de ces obsolescences présente de nombreux avantages :
Réduction des factures
Ces technologies obsolètes font très souvent l’objet de droit d’utilisation élevés.
S’en affranchir permet de réaliser des économies substantielles.
Je dis cela… je ne dis rien.
Passer à COBOL V6 optimise les performances des programmes qui consomment moins de Mips, allégeant d’autant votre facture.
Gestion du risque
Vérifier la compatibilité de ses composants avec la version courante du compilateur permettra d’identifier la liste des programmes qui ne pourront subir de maintenance sans un minimum de refactoring. Un peu de gestion de risque évitera les mauvaises surprises en production.
Réduction de la dette technique et préparation de l’avenir
Décommissionner des technologies obsolètes, permet de réduire sa dette technique et de rationaliser son système en factorisant les technologies vers les standards.
Ces technologies n’ayant pas d’équivalent sur le monde Open, on supprime également ainsi, les principales adhérences aux mainframes. Cela facilitera et accélérera les futurs projets de modernisation qui auront ainsi un ROI à plus court terme.
Comment fait-on ?
La suppression de ces technologies obsolètes se prête parfaitement à une approche automatisée qui permet d’être exhaustif dans l’analyse, la transformation et les tests.
Nous apportons les solutions techniques de remplacement et les outils de transformation et de test.
Comme toujours chez Move, pas de coût de licence et un engagement forfaitaire.
On en parle ?
i Voir le post Fifty ways to leave your mainframe
Image par Gerd Altmann de Pixabay
