Moderniser votre SI - Replatforming

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. Ainsi 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. Par exemple, une solution de replatforming ou rehosting offrant le meilleur ROI sur 3 ans pourrait être déclassée sur 5 ans (Même en comptant un décommissionnement mainframe réalisé au plus juste et meilleur coût).

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 de modernisation ou replatforming optimum.

La conduite du changement

On devra considérer la capacité des équipes de développement et d’exploitation à se projeter dans la nouvelle solution. En effet, plus le gap technologique engendré par la modernisation du SI ou le replatforming sera grand, plus l’effort de formation et d’accompagnement devra être important pour sécuriser la productivité des équipes.

En outre, l’accompagnement nécessaire et le plan de formation prendra en compte le vieillissement des équipes, les départs en retraite et les décommissionnements possibles.

Une approche différente par architecture source

Il existe 3 grands types d’architecture sources :

1. Les Mainframes principalement IBM MVS, Bull Gcos 7 et 8, Unisys,…
2. Les architectures Client/Serveur (Visual Basic, Oracle Forms, Delphi, NSDK, PowerBuilder,…)
3. 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.

Replatforming et ROI

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. D’ailleurs, ils sont essentiellement tirés par le besoin de trouver des marges de manœuvres financières: décommissionner un mainframe est une garantie systématique d’économies significatives!

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. Ou alors 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, grâce notamment aux nouvelles solutions outillées qui accompagnent le décommissionnement mainframe (Comme la solution d’Archivage de MOVE Solutions) . 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. Même si l’on peut réduire la dette technique en migrant assez facilement vers du freeRPG.

Replatforming Mainframe

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 ! En effet, 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. Dès lors 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.

L’atelier détermine par la fonction « a besoin de » les liens entre les objets et produit 3 listes :

1. Le périmètre utile (Used): Liste des objets utilisés en production
2. Les Manquants (Missing): Liste des objets invoqués par un objet utile mais dont le source est manquant
3. 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. Et 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 inutile. En effet, 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 (notamment valider un replatforming imaginé), on réalise en pratique une ou deux itérations maximum. Puis 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é. Il s’agit de parcourir un arbre de décision selon des items hiérarchisés qui ferment des options au fur et à mesure des choix.

1. Linux ou Windows
2. Choix des langages cibles et du poste de travail
3. Choix de la base de données
4. Solution de remplacement du moniteur transactionnel (Moniteur compatible ou Serveur d’Application)
5. 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.

Ainsi, 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 coût d’un projet traitant à la fois une modernisation et des modifications fonctionnelles. Dès lors, 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. Cela est possible 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. Et 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. Alors 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

Charge et le délai d’un projet de modernisation

Tout projet de modernisation commence par un recensement des composants techniques à migrer. On appelle cette opération Cartographie, Scan, Assessment…

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,
• C_i Représente la complexité de transformation de la technologie i et V_i 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 couteux à 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.