L’abandon du mainframe dans une organisation quelle qu’elle soit est un momentum unique.

Une telle opération présente évidemment des risques importants.

Mais elle représente aussi une réelle opportunité pour adresser un ensemble de problèmes récurrents dans la majorité des organisations, en souffrance depuis souvent trop longtemps.
Nous voulons parler ici de :
– la dette technique (1) ;
– des manquements en matière de transfert de connaissance des seniors vers les juniors ;
– de rationalisation des moyens ;
– de saisie de nouvelles opportunités jusque là négligées.

La dette technique concerne les branches mortes non éliminées dans les anciens programmes, la perte de maintenabilité due aux maintenances successives ( structures de programme ou de données lentement dégradées au cours du temps), le manque de réutilisation (le syndrôme du copier coller), les duplications de données, etc.

Les manquements en matière de transfert de connaissance font trop souvent l’objet de vœux pieux jamais vraiment réalisés. Une opération de migration, si elle se fait dans le cadre d’une bonne mixité juniors-seniors (par ailleurs une des conditions de succès de l’opération), oblige à ce transfert.

La rationalisation des moyens est aussi trop souvent lettre morte, parce que les équipes sont en permanence aux prises avec les exigences quotidiennes. Il s’agit ici de mettre en oeuvre le principe « One concern – One solution » :
– au niveau technique : une seule base de données, un seul langage, un seul outil de développement, un seul outil de scheduling pour les chaînes batch, …
– au niveau fonctionnel : un seul outil de modélisation, une approche décloisonnée sur les données et les fonctionnalités, …

En matière de nouvelles opportunités, il s’agit de s’intéresser à des sujets comme la virtualisation de serveurs (et pourquoi pas également, tant qu’à faire, des desktops), les solutions open source, les outils de gestion de règles métier, l’intégration continue, …

Les différents scénarios possibles doivent être évalués non seulement en fonction des coûts, délais et risques, mais aussi en regard de ce qu’ils apportent ou non par rapport aux quatre critères évoqués plus haut. Il serait dommage de les négliger dans l’analyse de décision.

______________________________________________________________________________________________

(1)
Un projet de développement logiciel inclut une partie de conception (elle correspond à la définition de son architecture et  design technique).  Lors de la programmation, le respect de l’architecture et du design conditionne la qualité du projet.  Écrire le code source en suivant la conception définie en amont lui permet d’être cohérent, et de faciliter les activités de maintenance. On distingue pour l’essentiel deux types de maintenance :
– la maintenance corrective : pour corriger les bug informatiques ;
– la maintenance évolutive : pour modifier ou ajouter de nouvelles fonctionnalités.
Lors des phases de maintenance un non-respect de la conception,  intentionnel ou non,  induit des coûts supplémentaires ultérieurs.  Ce sont les intérêts.  C’est pourquoi l’on parle de dette technique, pour montrer l’analogie avec la dette dans le domaine financier.  Comme dans le domaine financier, il vaut évidemment mieux rembourser la dette rapidement plutôt que de continuer à payer des intérêts sur la dette dans la durée.
En résumé, quand on code au plus vite et de manière non optimale, on contracte une dette technique que l’on rembourse tout au long de la vie du logiciel sous forme de temps de développement de plus en plus long, et de bugs de plus en plus fréquents et difficiles à corriger.