Modernisation du mainframe : quatre voies et leur coût réel
Un mainframe est rarement remplacé parce qu’il est cassé. Il est remplacé parce que plus personne ne le connaît, ou parce qu’une interface avec le reste du parc ne peut plus être construite. Cette différence décide de la voie qui convient.
Quatre chemins, chiffrés en risque
On les présente souvent comme une échelle dont le dernier barreau serait le meilleur. C’est faux : au bon endroit, les quatre sont la bonne réponse.
- Le laisser et mieux l’exposerLe système reste et reçoit une interface moderne à côté, pour que le reste du parc puisse l’atteindre. La voie la moins chère, et souvent la plus sage quand le système fait ce qu’il doit et que seul l’accès manque.
- Le déplacer sans le réécrireLa même application, une autre couche en dessous : émulation ou environnement chez un fournisseur. Le risque est faible car la logique ne change pas ; ce que l’on règle, c’est le matériel et les compétences en dessous, pas la lisibilité du code.
- Le reconstruireRefaire la fonctionnalité sur une pile moderne. Le plus cher, le plus long, et le seul qui nettoie réellement la complexité d’origine. Défendable seulement si quelqu’un peut expliquer ce que fait l’ancien système, ce qui est précisément le problème à l’origine du chantier.
- Le remplacer par un progicielSi le processus n’est pas unique : un progiciel plutôt que du sur-mesure. La plus grande économie à terme et le plus grand choc à court terme, car le processus doit se plier au progiciel et non l’inverse.
Ce que nous y faisons, et ce que nous n’y faisons pas
Nous ne sommes pas un éditeur d’applications et nous ne faisons pas semblant. Voici où nous apportons de la valeur.
L’environnement autour
Réseau, stockage, interfaces, sauvegarde et la nouvelle couche de plateforme. Ce travail existe sur les quatre voies, et c’est la partie qui retarde un chantier applicatif quand elle n’est pas prête.
Des personnes pour porter le chantier
Administration réseau, cloud et systèmes en régie, pour la période où deux environnements tournent en parallèle. C’est la phase où une équipe est structurellement trop petite.
Ce que nous ne faisons pas
Réécrire l’application, démêler la logique métier ou prendre en charge une migration de code. Des sociétés ne font que cela ; nous préférons le dire au départ plutôt qu’à mi-parcours.
Pour aller plus loin
Ce à quoi cela se rattache.
Les questions qu’on nous pose
Celles qui reviennent le plus, en bref.
Réalisez-vous vous-mêmes la migration applicative ?
Non. Nous faisons l’environnement autour — réseau, stockage, interfaces, sauvegarde et la nouvelle couche de plateforme — et nous fournissons des personnes pour la période où deux environnements tournent en parallèle. Réécrire l’application relève de sociétés qui ne font que cela.
Laisser le système en place est-il une option sérieuse ?
Souvent la plus sage. Si le système fait ce qu’il doit et que le problème est que le reste du parc ne l’atteint pas, une interface moderne à côté est moins chère et bien moins risquée qu’une reconstruction.
Quelle voie pour ce système ?
Dites-nous ce qui tourne, qui le connaît et où cela coince. Nous disons laquelle des quatre voies nous prendrions et quelle part nous revient.
Des connaissances informatiques concrètes dans votre boîte mail
De nouveaux guides sur la gestion, la sécurité et le poste de travail, écrits par ceux qui font le travail. Sans discours commercial, et la désinscription se fait en un clic.