Poser le sujet
La modernisation de système d’Information est un terme assez générique qui recouvre différentes problématiques et différentes solutions.
D’une manière générale, on peut définir les besoins sous-jacents comme :
- Réduction des coûts informatiques,
- Désendettement technique
A peu près toutes les problématiques se retrouvent dans ces deux thèmes qui se rejoignent finalement car le premier frein à la réduction des coûts est lié aux adhérences des technologies utilisées avec des infrastructures chères à exploiter.
Ainsi, par exemple, un certain nombre de langages de programmation uniquement mainframe n’ont pas d’équivalents sur les architectures ouvertes et sont donc difficilement migrables vers des infrastructures modernes et économiques telles que le Cloud.
La notion de ROI
Il est important de considérer convenablement la notion de ROI et notamment sur quelle période de temps on le mesure.
Il existe plusieurs solutions cibles qui n’ont pas le même coût de possession, pas le même coût, pas le même délai de mise en œuvre.
Une solution offrant le meilleur ROI sur 3 ans pourrait être déclassée sur 5 ans.
Il est également nécessaire, bien que cela soit assez difficile, d’estimer les impacts positifs ou négatifs de chaque solution en termes de qualité de prestation et de productivité des équipes de développement et de maintenance
L’utilisation du ROI comme élément de choix, doit donc combiner une analyse de la solution technique cible, son coût et son délai de mise en œuvre.
Il est également indispensable de prendre en compte la capacité d’investissement de l’entreprise. En effet, l’entreprise ne dispose pas d’un budget illimité et ne peut peut-être pas financer en une seule étape le projet optimum.
Il est possible que la solution rationnelle passe par des étapes intermédiaires, chacune porteuses d’économies et d’améliorations pour permettre à l’entreprise de supporter le coût du projet vers la solution cible.
La conduite du changement
On devra considérer la capacité des équipes de développement et d’exploitation à se projeter dans la nouvelle solution. Plus le gap technologique sera grand, plus l’effort de formation et d’accompagnement devra être important pour sécuriser la productivité des équipes.
L’accompagnement nécessaire et le plan de formation prendra en compte le vieillissement des équipes et les départs en retraite.
Une approche différente par architecture source
Il existe 4 grands types d’architecture sources :
- Les Mainframes principalement IBM MVS, Bull Gcos 7 et 8, Unisys,…
- Les architectures Client/Serveur (Visual Basic, Oracle Forms, Delphi, NSDK, PowerBuilder,…)
- Les architectures plus récentes, à base de Framework Java/C# ou Javascript, mais qui commencent à nécessiter des projets de migration vers des versions plus modernes des Framework
- Les mini systèmes notamment IBM iSeries
S’il est relativement aisé de trouver un ROI quand on possède un parc Mainframe du fait des coûts de licences et de maintenance, cela se complique quand on considère les architectures client /serveur. Les gains sur le Run étant beaucoup plus faibles.
Le ROI attendu est donc davantage qualitatif avec une réduction de la dette technique et la gestion du risque lié à l’arrêt du support des langages C/S.
Il est également difficile de trouver un ROI financier sur les mini systèmes qui sont souvent très économiques, robustes et faciles à exploiter.
On peut considérer que les projets de modernisation Mainframe sont auto-finançables car ils induisent des gains financiers substantiels avec un ROI sur moins de 2 ans en principe. Ils sont donc essentiellement tirés par le besoin de trouver des marges de manœuvres financières.
Les projets de modernisation C/S n’apportent le plus souvent pas de valeur ajoutée fonctionnelle. On gère le risque d’obsolescence de la technologie, le risque de pénurie de main-d’œuvre, on se dote d’une capacité d’interopérabilité accrue avec une ouverture facilitée vers le multicanal enfin on profite des nouveaux outils et nouvelles méthodes de développement et d’exploitation.
Le ROI de ces projets se situe entre 5 à 10 ans. Il sera nécessaire d’allouer un budget spécifique à une ligne désendettement technique qu’il est toujours difficile de valoriser raisonnablement.
Les mini-systèmes iseries bénéficient du support d’IBM et ne présentent pas de risque technique court terme. Il est donc encore plus difficile de trouver un ROI dans un projet de transformation technique. On peut réduire la dette technique en migrant assez facilement vers du freeRPG.
Se débarrasser des a priori
L’a priori technique consistant à considérer que la puissance des Mainframes n’a pas d’équivalent dans le monde open ne prend pas en considération la notion de progrès technologique et la loi de Moore. Ce qui était vrai il y a encore 10 ou 15 ans ne l’est plus ! Un cœur d’un processeur PC moderne représente une puissance de l’ordre de 100 à 200 Mips sur MainFrame. Et il y a bien plus d’un cœur dans un processeur moderne. La tendance étant à une augmentation exponentielle du nombre de cœur par processeur.
Une configuration hardware permettant de supporter l’équivalent d’un Mainframe 500 Mips coûte moins de 20 000 € et encore bien moins dans un Cloud mutualisé.
La seule objection recevable concernerait l’exploitabilité qui est très aboutie sur les Mainframes. Les solutions dans le monde open existent bien évidement mais sont moins intégrées. Il conviendra de mettre en place très tôt dans le projet les outils d’exploitation cible afin de laisser aux équipes le temps de se les approprier et de les customiser.
Définir la modernisation
Une bonne manière de définir la modernisation est de considérer l’architecture que vous mettriez en œuvre si vous lanciez le développement d’un nouveau système from scratch.
Un projet de modernisation devra donc viser la mise en place l’architecture que vous choisiriez si vous lanciez le développement de vos applications aujourd’hui.
Les projets qui mettraient en œuvre une architecture cible qui ne serait pas celle que vous choisiriez aujourd’hui relèvent plutôt du replatforming et ne seront donc que des étapes intermédiaires dans votre processus de modernisation.
L’architecture cible doit permettre de rationaliser les technologies au sein de votre entreprise et donc autoriser la convergence des applications tant Mainframe que Client/Serveur vers une architecture unique à l’état de l’art.
Les solutions techniques
Il y a plusieurs solutions techniques pour améliorer votre système :
- Migrer vers un ou plusieurs progiciels
- Migrer vers une architecture semblable mais plus économique :
- Emulation
- Replatforming
- Moderniser
La migration vers un progiciel ou une Solution Saas
Cette solution est une approche davantage fonctionnelle que technique. Elle est parfaitement adaptée à des systèmes sources ayant, en plus de la dette technique, des lacunes fonctionnelles dont le comblement demandera de tels efforts de mise à niveau qu’il est plus rationnel d’abandonner le système actuel.
L’émulation
L’émulation consiste mettre en œuvre une solution d’émulation de la plateforme source et à y implanter sans transformation le code source as-it-is .
Exemple : Micro-Focus Enterprise Serveur ou Tmax Soft
Il n’est en principe pas nécessaire de modifier le code source. Des tests de non régression et d’intégration sont à prévoir. La reprise des données est un point critique.
L’avantage de l’émulateur consiste en une mise en œuvre plus rapide et peu d’impact sur les équipes qui continuent à travailler presque exactement de la même manière. Par contre il n’y a aucun désendettement technique…
D’expérience, il est rare que les émulateurs couvrent 100% du patrimoine source même si les éditeurs promettent des merveilles… Il est très souvent nécessaire de procéder à des modifications plus ou moins importantes du code et des requêtes SQL et de traiter des langages ou utilitaires non couverts par l’émulateur.
La couverture précise et la compatibilité de l’émulateur par rapport à votre système actuel est un point à vérifier très en amont pour bien estimer le coût et le délai du projet.
Le Replatforming
Le replatforming consiste à mettre en œuvre une architecture similaire mais en utilisant des composants logiciels plus économiques.
Il n’y a pas ou peu de gap technologique, juste des gains financiers.
Les projets de replatforming nécessitent de modifier les composants Sources pour les faire fonctionner sur la plateforme Cible.
Exemple : MVS CICS DB2 COBOL vers Unix Tuxedo, Postgre SQL COBOL IT.
Un tel projet nécessitera :
- De migrer les fichiers et la base de données avec un transtypage des zones et une conversion EBCDIC –> ASCII,
- De transformer les requêtes SQL
- De modifier le COBOL pour le rendre compatible avec le compilateur cible,
- De convertir les JCL en scripts Unix
- De remplacer les utilitaires par des équivalents sur la cible
- De migrer l’ordonnanceur,
- D’assurer des tests de non régression exhaustifs
- D’intégrer l’ensemble dans le SI
Tout langage ne disposant pas d’équivalent sur la cible devra être migré vers une technologie supportée (Cobol, Java ou .net,…)
L’effort de migration est assez important, le gap technologique faible, les gains essentiellement financiers peuvent être conséquents.
Il ne sera pas possible de faire converger vers une telle architecture les applications Client/serveur.
La modernisation
Un projet de modernisation consiste comme nous l’avons vu à mettre en place une architecture à l’état de l’art et à y porter les programmes existants tant Mainframe que Client/Serveur.
Les plateformes cibles sont principalement J2EE et Microsoft .net. Le choix entre elles relève du dogme et de la politique d’entreprise.
Des sujets à anticiper
La problématique du langage de développement cible
Dans l’idéal le langage de développement Cible serait un langage moderne, largement répandu et ne nécessitant pas de coût de Runtime.
Java ou C# sont de bonnes solutions selon ces critères.
Migration des langages Mainframe vers Java ou C#
La migration des langages Mainframe vers Java ou C# est techniquement possible, mais est en fait une « fausse bonne idée ».
Les solutions de migration automatique de COBOL vers java donnent un résultat catastrophique d’un point de vue performances et maintenabilité qui n’est pas compensé et de loin par l’économie réalisée sur les RunTime d’un compilateur COBOL commercial.
Passer d’un langage procédural à un langage Objet nécessiterait en toute logique une reconception UML adaptée et donc un effort de réécriture important avec des délais en conséquence.
Or le coût et la rapidité de migration et le caractère iso fonctionnel sont prépondérants dans la réussite d’un projet de modernisation.
Il est bien plus rationnel de chercher à factoriser les langages vers deux standards que sont COBOL et Java ou C#.
Les langages Mainframe seront migrés vers COBOL et encapsulés dans des services de manière à libérer les nouveaux développements qui pourront être effectués en COBOL, en Java/C# ou dans un mixte des deux.
Cette approche permet de limiter l’impact sur les équipes de développement qui conserveront leur productivité sur le COBOL tout en ouvrant immédiatement la possibilité de développer dans une technologie moderne.
La migration des différents langages Mainframe vers COBOL est très largement industrialisable avec un taux de conversion automatique proche de 100% qui sécurisent le projet.
Migration des langages Client/Serveur.
La migration des langages C/S peut et doit se faire directement vers une Cible Java ou C#.
Cependant, pour assurer une qualité des programmes Cibles optimale en termes de maintenabilité, il n’est pas souhaitable ni possible de réaliser une transformation totalement automatisée. Une finalisation manuelle du code est nécessaire. Elle est d’ailleurs l’occasion de faire monter en compétence les équipes de maintenance qui s’approprient ainsi les applications et seront totalement opérationnelles dès la bascule.
Le taux de transformation automatique sur ces projets est de l’ordre de 80%.
Le poste de travail
Le poste de travail cible est un point fondamental de la stratégie. Il doit être pensé dès le lancement du projet et si possible mis en place sur l’ancienne plate-forme de manière à former très tôt les développeurs et sortir ce sujet du chemin critique.
Les poste de travail sous Eclipse permettent aujourd’hui d’adresser tous les environnements Source et Cible à l’aide de plugins dédiés.
Le successeur d’Eclipse comme standard sera sans doute VS Code qui bénéficie du support enthousiaste des développeurs.
On devra viser une approche DEVOPS sur la mise en œuvre de ce poste de travail et des nouvelles méthodes de développement.
Les autres adhérences à l’ancien système
On pourra traiter dans le même esprit que la mise en œuvre anticipée du poste de travail, les autres adhérences à l’ancien système en mettant en œuvre très tôt des solutions de remplacement adressant l’ancien et le nouveau système.
Par exemple, l’ordonnanceur MainFrame pourra être remplacé dès le lancement du projet par une version permettant de lancer des jobs tant sur Mainframe que sur Linux de manière à sortir ce sujet du chemin critique et que la bascule sur le nouvel environnement soit la plus transparente possible pour les exploitants.
La méthodologie de modernisation
Tout projet de modernisation commence par un recensement des composants techniques à migrer. On appelle cette opération Cartographie, Scan, Assessement…
C’est une étape indispensable qui doit être menée de manière suffisamment approfondie pour identifier les points de complexité de la transformation et les volumétries associées.
La charge et le délai d’un projet de modernisation s’estime en considérant pour chaque technologie la somme du produit de la complexité de la Transformation X Volumétrie:
Où
- Chaque valeur de i représente une technologie à transformer,
- Ci Représente la complexité de transformation de la technologie i et Vi le nombre d’objet de la technologie i.
En effet une technologie très compliquée à transformer comme l’Assembleur par exemple ne posera pas de réel problème si sa volumétrie est faible. De même, une technologie très facile à migrer comme le COBOL ou le JCL ne posera pas de problème technique quelle que soit la volumétrie.
A l’inverse des patrimoines contenant de nombreux objets dans des technologies complexes à migrer, seront coûteux à transformer.
Les informations nécessaires à la réalisation de cette estimation sont obtenues par la Cartographie de votre système.
La cartographie initiale
La cartographie consiste à collecter les sources de tous les objets de votre patrimoine et de tirer les références croisées entre les objets pour définir le périmètre réel de votre projet qui correspond aux objets en production.
Un simple recensement des sources n’est pas suffisant car un grand nombre d’objets sont obsolètes dans les bibliothèques. De même, il est nécessaire de s’assurer de disposer de tous les sources à transformer. Il est fréquent que des sources anciens correspondant à des objets très stables soient difficile à retrouver…
Du fait du nombre d’objets à traiter, cette opération doit être réalisée avec un outil automatique qui seul peut garantir l’exhaustivité et la qualité de l’analyse.
La cartographie est itérative.
On alimente l’atelier avec les sources collectés et on paramètre les points d’entrée TP et les jobs lancés.
L’atelier détermine par la fonction « a besoin de » les liens entre les objets et produit 3 listes :
- Le périmètre utile (Used): Liste des objets utilisés en production
- Les Manquants (Missing): Liste des objets invoqués par un objet utile mais dont le source est manquant
- Non Référencés (Unused) : Liste des objets fournis mais non invoqués par un objet utile.
On itère en complétant la fourniture des sources manquants et en ajoutant les points d’entrée qui auraient pu être oubliés.
Les nouveaux points d’entrée vont référencer certains objets qui ne l’étaient pas.
Pour être exhaustif, il est nécessaire de ne plus avoir de Manquant, un seul manquant pourrait invoquer de manière transitive un grand nombre d’objets que nous pourrions à tort considérer comme inutiles.
La cartographie doit être exhaustive pour réaliser le projet de transformation.
Quand il s’agit d’analyser le patrimoine pour mesurer la complexité de la transformation et les meilleurs scénarios, on réalise en pratique une ou deux itérations maximum et on extrapole les résultats avec une marge d’incertitude.
Les scénarios possibles
Le résultat de la cartographie permet d’estimer l’effort de transformation pour un scénario donné.
Le choix de la plateforme cible peut être assisté en parcourant un arbre de décision selon des items hiérarchisés qui ferment des options au fur et à mesure des choix.
- Linux ou Windows
- Choix des langages cibles et du poste de travail
- Choix de la base de données
- Solution de remplacement du moniteur transactionnel (Moniteur compatible ou Serveur d’Application)
- Solutions de remplacement pour les produits tiers et Progiciels
L’ordre de ces items peut être modifié en fonction des convictions et de l’existant au sein de votre SI, mais la démarche reste la même.
On pourra étudier un ou plusieurs scénarios.
Le POC
Un ou plusieurs POC (Proof Of Concept) pourront être réalisés pour vérifier la faisabilité technique de telle ou telle solution et valider que les performances sont suffisantes.
Les Performances
Les performances sont un élément déterminant de la solution. Une solution 100% compatible d’un point de vue technique pourrait permettre un projet quasi instantané mais si les performances ne permettent pas de passer le plan batch durant la nuit, il ne sera pas possible de l’adopter…
Les grands principes
Un projet ISOFONCTIONNEL
Un projet de modernisation ne doit pas tenter d’apporter en même temps des améliorations fonctionnelles.
En effet, la validation de la transformation se fait de manière technique par une comparaison d’exécutions de traitement sur la Source et la Cible. Cette comparaison peut ainsi être très largement automatisée.
Les écarts de comparaison sont analysés et permettent d’affiner les règles de transformation dans un processus itératif.
Si on introduit des modifications fonctionnelles, il sera nécessaire de procéder à une couteuse recette métier à chaque itération et de constituer un référentiel du comportement attendu.
A chaque écart on devra se demander si c’est la transformation qui est en cause, ou la modification fonctionnelle ou le cas de test ou une combinaison de facteurs…
Il n’est pas possible de sécuriser le délai et donc le cout d’un projet traitant à la fois une modernisation et des modifications fonctionnelles.
Les modifications fonctionnelles doivent être réalisées en amont et on convertit alors des programmes fonctionnellement modifiés ou en aval en modifiant les programmes convertis et certifiés.
Bien évidemment, le projet de modernisation prend en compte le cycle de vie de l’applicatif en convertissant dans un process de report de maintenance piloté, les objets modifiés depuis le début du projet.
Il est recommandé de limiter la volumétrie de ces reports de maintenance qui représentent une charge de test.
Les environnements
La mise à disposition des environnements projets est toujours un point critique. Il convient de disposer d’environnements Source et Cible dédiés et convenablement dimensionnés. L’environnement de production devra être disponible assez tôt pour réaliser les tests de performance et le tuning.
Les données et les scénarios de tests
La reprise de données est sur le chemin critique du projet : Pas de données, pas de test !
La mise au point des règles de transformation se faisant par des itérations de tests. Il est nécessaire de disposer très tôt d’un jeu de données intègre et de scénarios de tests correspondant (exécutions de traitements sur la source avec capture des données avant et après).
Le projet
La méthodologie d’un projet de modernisation est éprouvée depuis de nombreuses années. La nature de la cible technologique n’influe pas sur la méthodologie qu’il convient de respecter à la lettre pour éviter les écueils.
La mise à disposition des prérequis, notamment des environnements dédiés au projet est cruciale.
La méthodologie se décompose d’une manière Macro en :
Cartographie Projet
Pilote
- Détermination d’un lot pilote représentatif
- Mise au point des règles de transformation sur le Pilote
- Transformation automatique du Pilote
- Validation du Pilote
Industrialisation
- Traitement par lot du reste du patrimoine avec transformation et validation par lot
Intégration
- Intégration de la nouvelle plateforme dans le SI et tests d’intégrations
Report de Maintenance
- Reconversion et test des composants modifiés
Bascule
- Répétitions des opérations de bascule
- Bascule
Les moyens techniques du projet
L’apport des outils
Un projet de modernisation d’ampleur ne peut raisonnablement être réalisé sans outils d’analyse, de transformation de masse et de tests industriels.
Les volumétries en jeu et les interdépendances entre les objets ne permettent pas de traiter ce type de projet à la main avec le niveau de qualité et d’exhaustivité nécessaire.
On fera intervenir un « outilleur » qui sera en mesure de mettre en place la suite d’outils permettant :
- L’analyse du patrimoine
- La transformation automatique du patrimoine
- Les tests de non régression industriels.
Sur ce dernier point, il est à noter qu’un des livrables du projet pourra être le référentiel de tests de non régression en intégration continue permettant une capitalisation sur les bonne pratiques de développement sur la nouvelle plateforme.
Positionnement de MOVE SOLUTIONS.
MOVE SOLUTIONS est un des rares outilleurs et la plus grosse équipe spécialisée en France.
MOVE réalise des projets de modernisation depuis sa création et propose des cibles natives à l’état de l’art J2EE ou .net avec un cout de possession optimum.
Les outils MOVE sont mis à disposition sans coût de licence y compris sur les plugins Eclipse et VScode qui enrichissent le poste de travail pour optimiser la productivité. Aucune adhérence des outils avec le code livré.
MOVE est noté 1+ par la banque de France soit la meilleure note crédit possible.
De nombreuses références sur des projets majeurs.
