Le "legacy system" le talon d’Achille de la transformation numérique.

 

Image : Pixabay 



Confronté à un "legacy system" qui empêche les mouvements, que faire ? 


Les entreprises qui ont consenti de lourds investissements dans des programmes de transformation numérique constatent souvent que le curseur de ladite transformation ne s’est pas déplacé au rythme attendu !

De (trop) nombreuses réponses ont été développées historiquement avec des technologies qui appartiennent maintenant au passé : les systèmes hérités, ou legacy system. Et malheureusement la dépendance à ces technologies est forte, car ces systèmes contiennent les données dont les entreprises ont besoin pour prendre des décisions aujourd'hui, et sûrement celles de demain !

Plus que jamais, cette forte dépendance à l'égard des legacy system est l'un des grands obstacles dans le parcours semé d’embuches de la transformation numérique. Les services IT sont fortement mis à contribution avec des injonctions parfois incompatibles : mouvement vers des plates-formes Cloud, simple remplacement des solutions applicatives datées par des logiciels SaaS, lancement de grands programmes de modernisation du legacy…, etc.

Le tout, en assurant une réelle continuité de service. Bon courage !

Commencer par ne pas précipiter les choses.

Au cours des 10 dernières années, de nombreux programmes de modernisation de legacy ont échoué, et certains grands projets de migrations ont accouché de solutions largement sous-performantes. Ce sont souvent les entreprises qui ont voulu aller trop vite, ou qui ont péché par orgueil. D’un legacy system qu’elles traînent comme un boulet, elles finissent par se retrouver dans le cloud avec des architectures incompréhensibles, des coûts inflationnistes, et un métier qui récrimine car n’étant pas partie prenante de ces atermoiements. D’un legacy system A, on passe à un futur legacy system B. Dommage !

Il ne faut pas céder aux effets de mode. Il y avait eu un mouvement vers les solutions packagées type ERP il y a quelque temps, maintenant nous avons le Cloud. Mais cela peut déboucher vers de vraies régressions.

S’il y a un risque de dégrader les fonctionnalités clefs de l’entreprise durablement ou que ces fonctionnalités touchent aux compétences clefs de l’entreprise, alors il sera opportun de ne pas précipiter les choses, de prendre son temps, pour éviter à tout prix les « black box ».


Des pistes de travail  


1- Une surcouche technique

Le remplacement complet des systèmes hérités est une entreprise risquée. Une entreprise de Retail européenne de notre connaissance a plutôt opté pour une stratégie particulière : créer une enveloppe autour du legacy system. Ces « wrappers » font émerger la logique métier qui est implémentée au plus profond des legacy systèmes en préservant la stabilité du système, tout en cassant l’uniformité du système en place. Des technologies de streaming, comme Kafka, Spark ou Kinesis, etc., permettent de mettre en place ce « wrapping » intelligent. Ce modèle a typiquement permis à plusieurs entreprises à réutiliser la logique de leurs mainframes, sans entreprendre de coûteux programmes de décommissionnement.

2- Cartographier son legacy système, et connaître les zones « chaudes », « froides »

Il est très important d’être conscient du patrimoine technologique qui s’est développé de façon incrémentale au fil des ans. Pour ce faire, la meilleure des méthodes sera de cartographier les SI techniquement en définissant les origines des informations, ce à quoi, elles servent, à qui elles servent. Les zones de surexploitation et de sous exploitation du SI devront être identifiées pour permettre de prioriser les chantiers. Avec cette « carte » en main, les équipes ont la haute main sur les flux dans les systèmes, leurs interactions avec les systèmes applicatifs, leur importance. Faire évoluer les systèmes, ou carrément les décommissionner sera infiniment plus simple. Surtout si cette cartographie est délivrée en continue.

3- La "matière morte" dans un legacy system

Les legacy systems charrient de la « matière morte ». Typiquement des flux qui ont été créés pour des applications qui ne servent plus, ou pour de gens qui ne sont plus là. Il sera précieux de songer à « débrancher » les solutions qui n’ont plus d’usage mais également tous les sous-jacents.

Les données qui servent réellement ont une empreinte dans les bases d’audit. En parcourant parallèlement tous les flux permettant de produire ces données utilisées par les métiers, on opère mécaniquement une discrimination entre les composants des systèmes qui sont utiles de ceux qui ne le sont pas.

Les équipes techniques auront à loisir de supprimer ou d’archiver la « matière morte » en temps continu. On pourra ainsi amener le système à sa juste mesure dans un temps raisonnable, sans opérer de révolution.

Par ailleurs, les traitements « utiles » sont intriqués dans la cinématique d’ensemble. Il peut être judicieux d’opérer une réduction massive du nombre de traitements en générant automatiquement du code « ensembliste » qui va factoriser tout ce qui peut l’être (surtout les curseurs dans le code procédural). On amènera ainsi le système à son optimum, avec en plus une compréhension facilitée du processing de la donnée.

4- S’appuyer sur le métier, une logique « top down ».

Au lieu de dépenser de l'énergie pour complétement révolutionner un legacy system, il vaut parfois mieux investir des ressources dans l’obtention d’un résultat exploitable par le métier qui pourra rapidement développer des nouveaux « business insights ».

Cela créera un puissant moteur de transformation « par le haut », qui permettra une évolution pragmatique du SI dans l’idée de créer du business. C’est plus vendeur. L'équipe qui travaillera à ce projet doit inclure des collaborateurs qui connaissent parfaitement le legacy system, car les nouvelles solutions utiliseront la logique métier déjà présente de longue date.

Conclusion

L’évolution des systèmes d’information, et donc la modernisation des legacy n’est pas une option : la compétition internationale impose aux entreprises une lecture toujours plus fine de leur business, et les oriente vers des stratégies « data driven ».

Comment dans ce contexte se départir de son legacy system, si encombrant, mais si utile. Comment le moderniser, puis migrer vers les cloud comme le souhaitent la plupart des entreprises. Rajouter une couche technique pourra faire le job, c’est une vraie option. Il apparait capital de cartographier son SI pour mieux le simplifier. Il faudra surtout s’appuyer sur les métiers en privilégiant la prise en compte de leurs besoins actuels et futurs pour ne pas créer de rupture de charge.


#cloudmigration  #legacysystem #Itdebt

www.ellipsys-bi.com 

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque