Dette IT = Fardeau éternel ?

 

Dette IT     = Fardeau éternel ?

La dette technique porte un nom d’emprunt parce qu’elle s’apparente un peu à la dette financière : si elle n'est pas remboursée, les intérêts s'accumulent.   Plus cette dette est ignorée, plus elle s'enracine et se propage dans le système, tel un poison à diffusion lente, entraînant une perte graduelle d'efficacité.   La dette technique en informatique, c’est : Pour partie une analogie pour décrire le coût accumulé des compromis de qualité dans les développements. Cela résulte souvent d’une exigence de vitesse, d’efficacité, qui va prendre le pas sur la qualité des développements. Pour partie une analogie pour évoquer les technologies dépassées encore exploitées dans de grandes largeurs, auxquelles l’entreprise peut être fortement dépendante. Le langage Cobol en est l’exemple le plus connu.

Comment diagnostiquer la présence d’une « dette technique » ?

Constatez vous une augmentation des coûts de maintenance ? Rencontrez vous des difficultés à recruter du personnel pour vos projets, notamment des personnes compétentes dans les technologies qui vous posent problème ? Les modifications mineures sur vos projets prennent elles de plus en plus de temps ? Avez-vous ajourné des projets de migration Cloud, tant le système en source vous paraît complexe ? ....    Bien évidemment, un système d’information ne peut pas avoir été développé de façon parfaitement homogène et il saurait y avoir de mise à jour technologique continue. Mais il ne faut pas que cela leste l'entreprises de façon trop importante.    Mesurer la dette technique dans l'architecture informatique est complexe. Il n'existe pas de métrique unique pour le faire. Il existe certes quelques indicateurs tels que le temps nécessaire pour faire fonctionner les chaînes d'alimentation sans erreur, le ratio entre le coût de remédiation et le coût de développement d'une nouvelle solution technique, le niveau de satisfaction des équipes travaillant sur le projet, le nombre de bugs non corrigés, la vitesse de migration, etc. Mais aucune de ces méthodes n'a fait école.

Plutôt que de mesurer, nous proposons de corriger les choses :    En partageant à tous la connaissance d’un système, En réduisant les volumétries, donc la complexité, En permettant les migrations de technologies legacy dépassées.

Corriger les choses en partageant à tous la connaissance d’un système analytics

Nous pensons qu’il est indispensable de porter à la connaissance de chacun l’ensemble des processus qui sont à l'œuvre au sein d’un système analytics : d’où vient la donnée, où elle va, qui l’utilise, comment elle est processée, avec quels outils, quand….   Le data lineage basé sur l’analyse du processing de la donnée, de son stockage, de son ordonnancement, de sa consommation (reporting et requêtes), permet en somme de dresser un portrait exhaustif d’un système et d’en partager la compréhension à tous, quand bien même les technologies sont anciennes et que les chaînes sont complexes.    Notre solution de data lineage, {openAudit}, analyse les technologies les plus répandues dans les systèmes legacy.  Quelques exemples :  Alimentations : Cobol, T-SQL, PL/SQL, Bteq, Perl, etc.  ETLs : DataStage, BODS, SSIS, Talend, ODI, etc.  Data visualisation : BO, Qlik, SSIS, Crystal Report, etc.    L’ensemble des technologies sont réconciliées pour une lecture exhaustive des processus de construction et de déploiement de la donnée.   Nous avons développé d’innombrables mécanismes pour traiter ce qui peut générer des ruptures dans les flux : les vues, les vues de vues, les procédures dynamiques, les transferts de données par FTP, etc. Tout ce qui peut factuellement créer de l'opacité.  La « carte » du système est produite en continue, avec une granularité variable selon le besoin.

Voir aussi :

Data Lineage : Réduction des Risques & Gouvernance

Corriger les choses en réduisant les volumétries

Parmi l’ensemble des branches d’un système, une large partie n’a pas d’usage. Le croisement des usages de la donnée et du data lineage d’{openAudit}, permet de mettre en évidence les flux inutiles, ce qui peut permettre de les écarter avec tout leur contenu : tables, code, jobs ETL, dashboards, etc. La maintenance pourra baisser de manière conséquente.

Voir aussi :

Identifier et supprimer les "branches mortes"

Corriger les choses en permettant les migrations de technologies legacy

Les technologies obsolètes qui constituent une large partie de la dette IT sont souvent très fortement utilisées. Il est complexe de s’en départir : Pour les bases de données, leur forte antériorité est à l’origine d’innombrables dépendances. Pour la couche de data visualisation, l'intelligence s'est sédimentées souvent dans des proportions considérables, ce qui rend les projets de migration souvent hasardeux.   En nous appuyant sur l’hyper granularité des analyses d'{openAudit}, nous avons développé des moteurs de migration permettant de faire des « moves to Cloud » très efficaces, avec un minimum de régression, que ce soit pour certaines bases de données, ou pour certaines technologies de data visualisation.

Exemples :

Migrer de Oracle à Postgre

Migrer de SAP BO à Power BI

Conclusion   La dette IT est un fardeau accumulé en raison d'une somme de petites négligences bien légitimes, ou par la naturelle obsolescence de certaines technologies. Elle coûte cher, car elle nécessite de démêler des nœuds continuellement et de s’entourer de compétences de plus en plus rares. Surtout, elle empêche de moderniser les systèmes.   Pour la résorber, nous pensons que la mise en œuvre de processus automatisés est indispensable. Automatiser, pour partager à tous la compréhension des méandres d’un système, automatiser la détection de ce qui ne sert pas ou plus, et automatiser les migrations vers les technos du moment, souvent dans le Cloud.

Contact