Evaluer l’impact des obsolescences technologiques sur un parc applicatif

Une application logicielle s’appuie généralement sur un grand nombre de technologies (langages, moteurs, sous-composants, etc). Lorsqu’une de ces technologies est considérée comme obsolète par une entreprise, pour des problématiques de maintenance ou de sécurité par exemple, il est important de pouvoir identifier rapidement les applications concernées. 

Dans un précédent post de blog sur la criticité métier et ses impacts sur l’IT, j’ai montré comment des indicateurs définis au niveau de la couche métier pouvaient être propagés au niveau des couches applicative et technologique.

Dans ce nouveau post de blog, nous allons voir comment appliquer le même principe avec Obeo SmartEA pour, cette fois-ci, remonter des informations depuis la couche technologique vers la couche applicative. En l’occurence le niveau de conformité d’un composant.

Cette information de conformité peut être renseignée sur un composant technologique grâce à un champ Conformité qui peut prendre cinq valeurs : “Proposé”, “Prévu”, “Actif”, “Déprécié” et “Obsolète”.

 

Une fois cette information renseignée sur un composant technologique, Obeo SmartEA peut calculer automatiquement la propagation de cette donnée sur tous les autres composants technologiques ainsi que toutes les applications qui l’utilisent.

Sur l’exemple ci-dessous, nous pouvons voir que le fait que le composant PHP 5.2 soit indiqué comme Obsolète, remonte automatiquement sur les technologues Apache 2.4 et Config Sugar CRM, ainsi que sur l’application CRM.

 

 

Pour tous les composants technologiques, cette remontée d’information s’effectue automatiquement grâce à la définition dans le Modèle de Référence de deux attributs calculés “Composants Dépréciés” et “Composants Obsolètes” dont l’expression (écrite en AQL) parcourt de manière récursive les relations de composition à la recherche d’éléments dépréciés ou obsolètes.

 

 

Pour les composants applicatifs (uniquement ceux stéréotypés Application), le principe est le même, mais cette fois-ci en recherchant les composants technologiques qui réalisent l’application grâce à deux attributs calculés “Réalisateurs Dépréciés” et “Réalisateurs Obsolètes”.

 

 

Ci-dessous, nous avons modifié l'exemple précédent en ajoutant un lien de réalisation entre Plug-in support client et CRM. Nous pouvons voir que Obeo SmartEA met automatiquement à jour la liste des réalisateurs obsolètes de CRM, en ajoutant API REST Support qui provient indirectement de Plug-in support client.

 

Lors du webinaire que j’ai présenté le 26 octobre 2023, et qui est accessible en ligne, j’explique en détail l’utilisation du modèle de référence pour calculer cette notion de conformité :

 

De la même façon que nous détectons automatiquement les technologies dépréciées ou obsolètes, il pourrait également être intéressant de connaître les applications “pilotes” qui utilisent des technologies qui ne sont pas encore complètement homologuées. Grâce à la possibilité de paramétrer le modèle de référence dans Obeo SmartEA, il serait possible d'ajouter cet indicateur, ou toute autre KPI nécessaire à l'alignement entre les différentes strates de l'entreprise, depuis la stratégie jusqu'aux technologies déployées.

Sirius Web 2024.3.0
Comment identifier les composants IT critiques pou...