Patrimoines numériques « Legacy » : les défis de l’hétérogénéité

Les patrimoines numériques hérités (applicatifs souvent appelés « Legacy ») et l’hétérogénéité des patrimoines numériques constituent actuellement un considérable défi pour l’organisation planétaire.

Pour quelle raison ? Parce que, selon les principaux analystes, les deux tiers du parc applicatif mondial, partie immergée de l’iceberg, et en particulier de la finance (mais pas seulement, également de la distribution et de l’industrie) tournent encore autour de noyaux applicatifs développés, par exemple, dans le langage Cobol et sont exploités avec des technologies liées aux gros systèmes traditionnels « mainframe ». (Avec structures de données fondées sur fichiers indexés, bases de données hiérarchiques, réseaux, ou – plus récemment – relationnelles, moniteurs de transactions tels CICS ou IMS, langages de scripts de type JCL…). Le tout étant souvent adroitement dissimulé derrière de belles interfaces homme-machine graphiques de type Web ou à base de fenêtres.

Aucun problème n’existerait si tout cela était bien documenté fonctionnellement et si le personnel pour maîtriser ce considérable cœur de parc applicatif des années 60 à 90 était toujours suffisamment formé, présent et à même d’assurer la maintenance quotidienne et la bonne évolution de ces applications métiers, leur refonte ou leur migration…

Or les documentations sont passées de mode et se perdent, tandis que les compétences disparaissent et que les formations sont rares, organisées pour maintenir ces processus et ces technologies encore si importantes, tandis que la plus grande partie du personnel initialement formé est soit déjà parti à la retraite, soit en voie de l’être. Phénomène qui semblerait témoigner, du point de vue du développement durable, de négligence comparable à celle qui avait précédé le fameux passage à l’an 2000 sans l’anticiper. Rappelons-nous que celui-ci avait failli faire mettre la clé sous la porte à nombre d’entreprises parmi des plus importantes, et mettre leur personnel à la rue, en raison du possible ou prévisible blocage total de leur infrastructure informatique.

Tel a été l’objet central d’une conférence-débat ADELI (dont la capture vidéo est accessible par le lien ci-contre) organisée le 08 octobre 2019 par le Groupe de Travail « Legacy », conférence-débat préparée et animée par Dominique Doquang, Eric Pasteyer, Arnaud Trouvé et Pierre Fischof, dont nous rendons ici compte avec quelques actualisations.

Les conférenciers : 4 expériences complémentaires

• Dominique Doquang a mené de nombreux schémas directeurs, missions de ré-urbanisation au niveau Entreprise Architecture, missions de rétro-documentation et rétro-modélisation de SI complexes, tous secteurs confondus.
• Eric Pasteyer a mené de longs projets de transformations techniques et fonctionnelles à BNP Paribas, La Coface, LVMH, Véolia Eau, Airbus Hélicoptères…
• Arnaud Trouvé a mené de nombreux projets d’optimisation et automatisation de processus métiers en contextes complexes tels qu’armement, aéronautique, médical, etc.
• Pierre Fischof a mené de nombreuses missions en simplifications, développements, refontes et migrations de patrimoines applicatifs en contexte Legacy, en particulier pour des institutions industrielles et financières.

En introduction, quelques définitions

Legacy (dans le domaine des S.I.)

Littéralement « héritage », désigne des applicatifs informatiques (ou sous-systèmes d’information) importants, gérant beaucoup de données, s’exécutant sur des systèmes fondés sur des technologies passées et qui n’ont plus ou très peu de documentation. Les critères d’identification en sont :

• n’ont plus (ou peu) de documentation ;
• capitalisent beaucoup de cœur de métier utilisé chaque jour ;
• les fournisseurs ou les développeurs n’en sont plus accessibles ;
• l’architecture interne n’en est plus visible ni connue de façon exhaustive ;
• les maintenances, lourdes, prennent énormément de temps (par exemple une à trois semaines par petite tâche au lieu de normalement une demi-journée) ;
• il y a beaucoup de besoins et demandes utilisateurs en attente : de modifications, évolutions ou corrections de bogues (bugs), les demandes s’accumulant sans pouvoir être traitées.

Remarque : même si celui-ci ne représente qu’une partie des applicatifs Legacy, nous traiterons principalement aujourd’hui de l’héritage applicatif Cobol, lequel, selon certains chiffres, constituerait 220 milliards de lignes de codes (les deux tiers du patrimoine numérique) et même 5 milliards de lignes de codes nouvelles écrites par an…

Cycle de vie applicatif en cascade et rétroconception symétrique

Selon les méthodes traditionnelles, « en cascade », l’on suit le cycle de vie classique suivant, bien connu :

• on détecte, étudie, spécifie et modélise les besoins « métier » ;
• on fait la conception d’un nouvel applicatif ;
• puis, on l’implémente physiquement (suivant des technologies et langage en cours).

En rétro-conception, rétro-modélisation, rétro-documentation et réimplantation logicielles (reverse engineering), on procède inversement :

• on part du code, des programmes et bases de données physiques ;
• on reconstitue ce que fait l’application par de la « rétroconception » ;
• on capitalise cette connaissance par la « rétro-documentation », si possible au travers de « modèles » normalisés (pour formaliser la logique des traitements et l’organisation des données) ;
• on peut alors rebâtir l’applicatif dans de nouvelles technologies à fonctionnalités identiques (iso-fonctionnalités), ce qui peut être parfois rapide, parfois peu coûteux ;
• ou bien on peut revoir les besoins métier par des interviews et reconstruire un nouveau système, ce qui sera alors beaucoup plus long et plus coûteux.

Remarque : Le ré-engineering ne concerne pas seulement les systèmes Legacy, ni seulement le numérique.

• Il est en effet utilisé également, par exemple, par des « hackers » pour reconstituer et recopier des logiciels modernes pour d’autres entreprises envers et contre l’accord de leurs propriétaires.
• Il s’utilise aussi pour recopier le plus possible à l’identique des avions, des voitures ou tous types d’objets sous la forme de plagiat industriel, pour le bénéfice de sociétés ou d’États, ce qui serait plus courant qu’imaginé.

1/4 : Management de projet de migration legacy : méthodes, outils

La méthode de management de projet utilisée le plus sûrement pour la rétro-modélisation et la révision ou migration d’applicatifs Legacy présentée aujourd’hui ne sera pas une méthode fondamentalement nouvelle mais, au contraire, fondée sur une méthode déjà éprouvée de façon efficiente dans les entreprises dans d’autres contextes, tels dans les migrations du passage à l’an 2000, par exemple, ou celles du passage à l’Euro.

Pour ce qui est de la méthodologie de rétro-modélisation, les techniques de la méthode internationale « OSSAD » peuvent être largement et strictement utilisées, celles-ci associées à des notations graphiques simples, claires et le plus lisibles par tous.

À côté d’un respect rigoureux très adapté au cas client de ces méthodes, l’une des nouveautés principales de ce type de projet doit résider, outre une expertise technique très solide, dans un outillage moderne et adapté, au travers d’une utilisation large de systèmes experts et d’intelligence artificielle. Comme dans notre exemple sous la forme d’un robot capable de lire le code Cobol afin de l’analyser pour le modéliser, à l’aide du langage XML et ses balises, et pouvoir, si souhaité ensuite, le transformer et le réimplanter.

Le pourquoi et « l’iceberg numérique »

On rencontre beaucoup de responsables de système d’information inquiets du devenir ou du remplacement de leurs applicatifs Legacy. D’autre part, en France, sur 240 formations initiales à l’informatique, seules 4 enseignaient récemment le Cobol tandis que de rares sociétés d’ingénierie informatique formaient des jeunes bac + 4 aux technologies Cobol et mainframe, sans souvent apporter massivement encore un vrai attrait financier,  culturel, prestigieux et en reconnaissance à de telles missions.

L’outillage d’aide à la transformation technique

Pour accélérer la rétro-modélisation, on recourra largement à la programmation de systèmes experts pour lire à plat du code Cobol et le rétro-modéliser sous une forme de logigraphes, avec le recours de XML.

L’utilisation de la méthode OSSAD

La méthode OSSAD (Office Support System Analysis and Design) est une méthode publique d’analyse d’organisation par les processus des systèmes de management et des systèmes d’information associés issu d’un projet du programme ESPRIT (“Europe Strategic Program for Research in Information Technology”) conduit de 1985 à 1990 par une équipe internationale et multidisciplinaire de consultants (équipe dont a fait partie notre ami Laurent Calmes.)

OSSAD respecte l’approche organisationnelle et opérationnelle des normes en systèmes de management (ISO 9001, ISO 14001, ISO 27001…) qui recommandent une représentation des organisations selon une approche processus, une approche par les risques et pilotée par des indicateurs permettant de corriger les non-conformités et plus généralement les défauts. Elle peut être utilisée dans toute démarche d’organisation. Pour cela OSSAD utilise trois strates :

• la strate des processus ;
• la strate des procédures ;
• la strate des instructions de travail.

Bien que la méthode OSSAD propose une « grammaire graphique » permettant de maîtriser la gestion des données d’un système, des méthodes et notations graphiques complémentaires telles que QUALIGRAMME ont proposé des représentations graphiques plus simples et intuitives permettant de faciliter la compréhension et le dialogue entre utilisateurs métier d’OSSAD et consultants organisationnels ou numériques).

Références cf 14 mai 2007 Rencontre-débat ADELI sur OSSAD animée par Laurent Calmes et son compte-rendu par Dominique Bergerot dans la Lettre ADELI 69 page 13 « Faut-il distinguer organisation et informatisation ? »

Le bon départ de ce genre de projet résidera dans une parfaite écoute et traduction dans la réalité du projet de la stratégie de l’entreprise cliente et de ses objectifs au niveau de sa direction générale. Une étude de faisabilité doit être menée avec le client. À ce stade, l’intervention du « Robot » va permettre de « déblayer le terrain » en apportant une vision plus claire de l’existant et en permettant de mieux déterminer la faisabilité et les économies possibles de charge du projet.
Doivent en découler, si la faisabilité est avérée, des plans d’action et les enveloppes budgétaires adaptées. La communication et la formation doivent suivre.

Les livrables

• un premier « découpage fonctionnel » des parties du SI impactées ;
• l’identification des « principaux impacts » (en tenant compte des projets en cours) ;
• propositions de « stratégie de déploiement » de la transformation technique ;
• une stabilisation ou définition du « plan d’action » général de changement et un premier chiffrage fin ;
• des « cartographies » fonctionnelles, techniques, de flux et de processus ;
• des « scenarii de transformation » et de bascule ;
• des « actions » MOE de « transformation technique » et de procédures ;
• des actions de « formation », de coaching, de changement et de communication.

Toutes ces actions doivent être menées conjointement avec les décideurs.

2/4 : Gestion des processus métier et migration Legacy

Méthodes et outils de BPM et de reverse engineering utilisés

Le BPM (Business Process Management) a commencé à se développer vers la fin des années 90 en utilisant des méthodes de modélisation et des outils numériques adaptés de cartographie et de modélisation des processus métier pour améliorer les liaisons entre couches métier et couches applicatives.

Ci-contre, l’on a des exemples de cartographies réalisées avec la méthode R.A.D., puis avec OSSAD sous Qualigram et Visio, puis avec Simply Otherwise.

Les conséquences de l’utilisation des méthodes et outils exposés de BPM et d’analyse du Code sont une vision plus claire et étendue du S.I. (système d’information) facilitant une possible migration totale ou partielle du patrimoine numérique Legacy et cela limite les « risques industriels » en gagnant du temps, des coûts et des délais et en simplifiant les décisions.

A contrario, par exemple, un client avait autrefois prévu, pour migrer sa facturation de Cobol à Java, un délai de 2 ans et un budget de 7 millions €. Il a cependant finalement dû dépenser 7 ans de délai et 35 millions € de budget. Voilà donc ce que ce client et beaucoup d’autres souhaitent à présent éviter, ceci dans une meilleure maîtrise de leurs objectifs et leurs moyens.

Un des moyens de garantir cette continuité et d’en minimiser les risques est de s’assurer les capacités d’analyse et de synthèse d’outils parfaitement complémentaires et doués d’évolutions sur l’ensemble des couches du système d’information.

 Dans la couche applicative Cobol :  ScanCod lit à plat le code d’une  application Cobol client avant de le  réintroduire littéralement dans un fichier support XML.

Après traitement du fichier XML, le robot  met en évidence différents contenus de l’application d’origine, dont l’algorithme d’origine, les règles de gestion, les structures de données.

 ScanCod et BPM associés : Cet ensemble devient un  outil de liaison entre les couches métiers et applicatives en utilisant les méthodes de modélisation, d’analyse et les outils adaptés du BPM (Business Process Management).

• Un moyen de rapprochement entre données traitées au sein de l’application de BPM et celles fournies et analysées après traitement de la Map XML fournie par ScanCod
• Un moyen de comparaison plus aisé entre les besoins métiers et les prestations fournies par le SI

3/4 : Réengineering orienté « Données » pour les systèmes Legacy

Sur de gros projets Legacy, Dominique Doquang nous parle de 4 cas de réingénierie, rétromodélisation et rétrodocumentation orientées Données.

Rachat d’une compagnie aérienne

Le 1^er cas est celui du rachat d’une compagnie aérienne par une grosse compagnie nécessitant la fusion des systèmes d’information (Gestion de vols, de réservation, etc.). Il faut très rapidement n’en avoir plus qu’un seul et, ceci en moins d’un an. Deux patrimoines applicatifs et une nomenclature éparpillée à ordonner. Le DSI veut savoir quelles sont les données qui sont gérées par les applicatifs et quels applicatifs garder et éliminer de la compagnie A et B avec réintégration des données de l’un dans l’autre, si ce n’est de ne garder aucun des deux mais d’acheter un progiciel.

Il faut aussi réunir toutes les données de référence et leur contenu (occurrences) au sein du Master Data Management, moyen d’avoir un S.I. cohérent et des données communes. Pour cela :

• (1) « collecter » toutes les informations et identifier les sachants disponibles,
• (2) tout « planifier » et organiser selon les documents et personnes disponibles ou non,
• (3) « réaliser » avec des modèles conceptuels de données, des règles de gestion sur ces données, des dictionnaires métiers et une cartographie des flux de données entre applications, liée à une cartographie applicative et
• (4) « finaliser », avec un diagnostic de données et sur leur qualité.
  On se sert beaucoup de « Templates » (autrement dit des modèles de documents) pour chaque type d’action.

Rétro-documentation d’un leader de l’énergie

Le 2^ème cas est une rétro-documentation d’un leader de l’énergie ayant un parc applicatif très important presque sans documentation. On doit constituer un dictionnaire métier.

On utilisera pour cela une approche agile pour déterminer avec le client le degré de détail et le temps utile à passer sur chaque document. Le dictionnaire métier a été « packagé»  pour être lisible et accueilli par tous.

Migration de l’applicatif Cobol d’un géant du transport

Le 3^ème cas est un géant du transport pour la migration de l’applicatif Cobol de RH vers un progiciel du marché mais avec 800 interfaces prévues à revoir. Le chantier fixé à 6 mois a finalement duré 7,5 mois effectifs (en raison de retards en amont de fourniture de documents). Là aussi, il faut utiliser avec le client des budgets agiles par application. La difficulté est de tenir les délais avec un périmètre mouvant (150 interfaces documentées à abandonner et 100 interfaces non prévues initialement).

Rétrodocumentation de Data Warehouse

Le 4^ème cas est la rétrodocumentation de Data Warehouse d’entreprise stratégique sur lesquels le client ne dispose plus de documentation. Chez un géant pétrolier, la difficulté était l’énorme profusion des données type et de leurs occurrences (nombre de colonnes et de lignes de tables).

On a besoin de 4 types de compétence pour cette rétroconception de données :

• en Expertise Modélisation (maîtrise des niveaux d’abstraction, des contraintes d’intégrité fonctionnelle, des mécanismes de spécialisation et du versioning) ;
• en Expertise Méthode (architecture d’entreprise, BPM, analyse de performances, approche BI) ;
• en Expertise Outils (de cartographie des données, modélisation des données et de gestion des règles) ;
• en Expertise Métier (connaissance transverse entreprise et son langage).

Le problème des outils de rétroconception des données est, (figure ci-dessus), qu’aucun outil ne fait toutes les tâches. On doit donc faire appel à plusieurs outils spécialisés…

4/4 : Architectures « traitements » et migrations Legacy

Impacts de la clarté des architectures logiques de traitements sur les coûts

Après avoir parlé de la rétro-modélisation des données, nous allons à présent parler de l‘architecture des traitements, de leur analyse, de leur évolution et de leur possible migration, plus ou moins facile ou difficile, en fonction de leur limpidité ou complexité d’architecture.

Outre le critère de la bonne qualité ou de l’absence de documentation fonctionnelle et technique applicative, c’est en fonction de l’hétérogénéité et complexité de l’architecture logique et technique des traitements que la rétro-modélisation, l’évolution et la migration des traitements seront, à court terme d’un côté, à long terme de l’autre, simples ou compliquées.

Côté logique, la complexité ou la simplicité tient au fait, par exemple, que toutes les commandes d’accès aux données (dites de « back-office ») ont été traitées proprement dans des modules spécifiques ou mélangées en désordre avec les autres commandes, de même que les commandes de l’interface graphique homme-machine (dites de « front-office ») ont été traitées proprement dans des modules spécifiques ou non.

Ainsi, dans le cas d’une architecture de traitements extrêmement propre et bien structurée, (comme dans le cas de schéma d’architecture du « scénario 1 » ci-contre, dont l’exemple correspond à un grand organisme social), la maintenance, l’évolution voire la migration seront beaucoup plus faciles et légères à manier que dans le cas où l’accès aux données et la gestion de l’interface utilisateur sont inextricablement liés au sein des mêmes modules de traitements (comme dans le cas simplifié de schéma d’architecture, extérieurement apparemment simple mais intérieurement intimement complexe, du « scénario 4 » ci-contre, dont l’exemple correspond à la plupart des applicatifs…).

Peu importe, dès lors, que dans ce scénario 1, deux langages différents soient utilisés pour les services back-office (Cobol + SQL), et les services front-office (Java), dans la mesure où la structure logique est ordonnée remarquablement, homogène, structurée. L’évolution du back-office et celle du front-office peuvent requérir dès lors des tâches, des compétences et des équipes potentiellement différentes travaillant en synergie et coopération, ce qui peut grandement alléger les projets et les simplifier. Un tel choix d’architecture demandera, au départ, en revanche, une importante discipline d’ordre, un investissement conséquent en structuration et ordonnancement des traitements. Mais trouvera sa récompense dans la construction de modules pouvant être testés chacun isolément et posément avec un jeu d’essai particulier, ceci avant d’en tester leurs bonnes communications mutuelles pour le bon fonctionnement de l’ensemble. Comme cela a été le cas pour l’organisme social concerné.

Côté technique, à l’inverse, certains choix de langages et de migrations peuvent sembler, à court terme, simples et peu coûteux mais rendre la maintenance et l’évolution ultérieure de moyen et long terme plus épineuses et coûteuses à réaliser. Comme cela pourrait être éventuellement, parfois, le cas pour la conversion d’un code Cobol compréhensible et lisible dans un code Java moins clairement structuré, moins lisible. Raison pour laquelle il faut toujours penser aux coûts de long terme liés à la durée de vie possible des applicatifs, bien au-delà des seuls frais de court terme…

Cependant, s’il advient que la conversion automatique du Cobol en Java ressemble finalement au code Cobol d’origine du fait d’une encapsulation du code Cobol dans du code Java, alors l’évolution et la maintenance du code Java final peut s’avérer plus simple à gérer, quoique nécessitant un code plus complexe et bavard que le code d’origine Cobol.
(Nous n’avons pas évoqué ici le cas d’une réécriture propre et intégrale du code « à la main », souvent beaucoup plus longue et coûteuse à réaliser mais qui fournit alors un code beaucoup plus lisible et propre…)

Réingineering des traitements : comment, avec quels outillages ?

Si les techniques de réingineering des traitements ont franchement progressé ces vingt-cinq dernières années, notamment en ce qui concerne la possibilité de traduction automatique d’un langage de programmation dans un autre langage, une partie de ces techniques, alors moins abouties toutefois, avait été déjà réquisitionnée et utilisée pour le passage à l’an 2000 et pour le passage à l’Euro.

Chaque outil du marché rétro-modélise le code source d’origine selon sa propre grammaire des traitements, laquelle produit d’abord une analyse des traitements et est susceptible de générer ensuite une traduction du programme dans un autre langage ou simuler cette traduction pour avoir déjà un premier aperçu du code qui sera produit et sa future lisibilité et maintenabilité.

Nous pouvons noter ici que, à côté et au-delà des outils et méthodes permettant de bien analyser le patrimoine applicatif et de mieux évaluer les coûts,  impacts et délais d’éventuelles migrations, il existe aussi sur le marché quelques offres qui, sans produire d’analyses aussi poussées, proposent des migrations de code pour les traitements transactionnels. Les migrations de code pour les traitements par lot (batchs) sont rarement proposées, par contre, sans doute en raison de contraintes et exigences de performances beaucoup plus sévères et complexes. Notons que ces migrations de codes ne sont pas forcément exemptes d’un certain risque de complexification du code des programmes à moyen et long terme, et donc de leur future maintenabilité.

Conclusion : défis, risques et opportunités

Au-delà des apparences, le patrimoine applicatif « Legacy » est donc partout dans le monde, même si souvent dissimulé derrière de séduisants interfaces adroitement trompeurs, occupant donc, selon certains cabinets faisant référence, les deux tiers du patrimoine applicatif mondial existant. Or la vitale continuité d’activité des importantes organisations que sert ce patrimoine logiciel devra être garantie, assurée, que ce soit par de l’entretien ou par du remplacement (achat sur étagère rarement simple à adapter et paramétrer). C’est dire toute l’importance des défis à relever et des risques à surmonter.

En fait, la plupart des grosses entreprises et organisations traditionnelles de la planète n’ayant pas eu à subir d’importants phénomènes de rachat ou fusion, (avec pour conséquence la fusion de systèmes d’information), possèderaient normalement encore un ancien patrimoine applicatif Legacy toujours en production, celui-ci hébergeant le plus souvent en héritage une grosse valeur métier non standardisée et difficilement standardisable par un progiciel. Souvent, les leaders mondiaux dans leur secteur ainsi que les gros ministères de la planète et organisations du secteur parapublic sont dans ce cas.

L’étonnant et cruel paradoxe est que le passage du cycle de développement traditionnel en V à un cycle de développement agile, considéré comme beaucoup plus moderne, a accéléré ce phénomène de vieillissement du patrimoine numérique tendant à l’obsolescence. Ceci par le fait que cette pratique mal maîtrisée court-circuite et néglige bien trop souvent, la production d’une documentation fonctionnelle des besoins à la source de la rénovation du S.I.

En réalité, l’approche agile ne devrait pas remplacer mais compléter l’approche en cascade et en V, ceci pour fournir des systèmes d’information bien documentés fonctionnellement, maintenables et parfaitement durables.

D’autre part, l’externalisation de la maintenance du patrimoine numérique Legacy en tierce maintenance applicative (TMA), son exploitation sur le cloud, n’a rien de forcément magique. Elle pourrait écarter d’abord la vision du problème, un peu à la façon d’une autruche se cachant la tête dans le sable. À elle seule, elle ne peut donc constituer une solution définitive en soi, « éliminant » le problème posé par ce patrimoine.

La nécessité de rénover, voire de migrer son patrimoine Legacy peut constituer en même temps une formidable opportunité de réappropriation de son métier, du Système d’Information de son organisation, ainsi qu’une opportunité d’homogénéisation et d’harmonisation du S.I.,  de son agilité et de sa maîtrise.

Tous ces facteurs font que la problématique des patrimoines numériques Legacy et de leurs langages devrait constituer un vaste et ample défi à relever, ainsi qu’un chantier à gérer, aujourd’hui et dans l’avenir.

ADELI_Support de Présentation Patrimoine Numérique Legacy_2021-01-03_v 1-5