Gestion d'obsolescence applicative 2/2 : l'exploitation des données

Dans un précédent billet consacré à la gestion de l’obsolescence applicative, nous avons montré comment utiliser Obeo SmartEA pour construire un référentiel agrégeant des données fiables sur le système d’information. Avec cette solution, les architectes peuvent collecter et organiser des données pour bâtir des processus d’analyse et de gestion du SI qui apportent une réelle valeur.

Dans ce nouvel article, nous allons décrire la deuxième étape d’une gestion d’obsolescence technologique, celle qui consiste à exploiter les données recueillies, en appliquant une démarche pilotée par les risques.

En effet, pour utiliser son budget de modernisation de manière efficiente, il est nécessaire de croiser la criticité des processus métier qui utilisent des technologies (au travers d’applications) avec les informations d’obsolescence. De cette façon, il est possible d’orienter l’effort de modernisation en priorité sur les applications qui font porter le plus de risque au métier. C’est une manière de progresser vers un SI mieux aligné avec le métier.

Nous prenons ici le point de vue du gestionnaire applicatif. Ce point de vue est centré sur les applications mais puise des informations de valeur métier et de criticité du côté des processus métier, ainsi que des informations d’obsolescence du côté des technologies. Ces informations permettront d’évaluer le risque associé à chaque application.

En fin de billet, nous montrerons aussi une carte centrée sur le point de vue métier, qui utilise donc des métriques différentes. En effet, un gestionnaire de processus cherchera plutôt à évaluer le risque particulier de défaillance de son processus. Ce qui est différent que d'évaluer le risque de défaillance d’une application en particulier, celle-ci ayant un impact sur l’ensemble des processus qu’elle sert.

Nous approchons la question de l’évaluation du risque en trois étapes :

• établir les analyses d’impact entre, d’une part les applications et les processus métier qu’elles servent, et d’autre part les technologies mises en œuvre.
• définir un indice de risque pour les applications, de manière à pouvoir évaluer les options de modernisation en fonction de cet indicateur. Le calcul de l’indice de risque s’appuie sur les analyses d’impact définies auparavant.
• construire des rapports permettant de gérer l’obsolescence applicative et de prendre les décisions liées aux opérations de modernisation.

Analyse d’impact

L’analyse d’impact est construite en suivant la méthode que nous avons proposée dans notre billet sur l'analyse d'impacts automatique. La démarche consiste à définir les motifs (ou patterns) de modélisation de manière formelle afin de pouvoir retrouver les liens entre les processus et les applications qui les servent, d’une part, et entre les applications et les technologies d’autre part.

Concernant le lien entre les applications et les technologies, nous pouvons appliquer le motif ci-dessous, déjà présenté dans notre billet précédent :

Nous vous invitons à relire ce billet pour une explication complète de l’analyse d’impacts à l’aide de ces motifs.

Le second motif que nous utilisons cette fois, relie les applications aux processus métier :

La lecture que nous pouvons en faire est la suivante :

• les processus métier sont servis par des fonctions applicatives ou par des services applicatifs,
• lesquels sont attribués, respectivement, à des composants applicatifs ou des interfaces applicatives;
• les composants applicatifs étant constitués d’interfaces applicatives

L’analyse d’impacts peut alors être réalisée depuis l’outil de recherche de Obeo SmartEA à l’aide de la requête AQL suivante, en indiquant le nom du composant applicatif que l’on souhaite évaluer :

self.applicationComponentByName('CRM').impactAnalysis('ApplicationComponent2BusinessProcesses')
    ->filter(archimate::BusinessProcess)

Cette requête retrouve tous les processus qui utilisent l’application CRM :

Définition et évaluation des métriques

Un indice de risque est généralement établi en multipliant un impact par une grandeur en relation avec la probabilité d'occurrence d’un événement. Le risque associé à une application est forgé à partir de ces deux éléments :

• nous allons assimiler le nombre de composants technologiques obsolètes à la probabilité de défaillance d’une application.
• nous construisons un indice de criticité d’une application en prenant en compte la criticité des processus qu’elle sert :
  • un processus de criticité faible compte pour 1 dans l’indice,
  • un processus de criticité moyenne compte pour 2,
  • un processus de criticité haute compte pour 3.

La requête AQL permettant de calculer cet indice pour une application est la suivante (la fonction let permet de collecter l’ensemble des valeurs de chaque propriété Criticité de chacun des processus métier reliés au composant applicatif que l’on évalue, de manière à pouvoir calculer l’indice global pour le composant selon la formule expliquée ci-dessus) :

let 
  criticities = self.impactAnalysis('ApplicationComponent2BusinessProcesses')
    ->filter(archimate::BusinessProcess).getPropertyValue('Criticité') 
in 
  criticities
    ->count('Haute')*3 + criticities
    ->count('Moyenne')*2 + criticities
    ->count('Faible')

Ensuite, pour compter le nombre de composants obsolètes, nous utilisons la requête AQL suivante (nous collectons tous les systèmes logiciels liés au composant à évaluer, et nous ne retenons que ceux dont l’année de fin de maintenance est inférieure à 2022 :

self.impactAnalysis('ApplicationComponent2SystemSoftware')
    ->filter(archimate::SystemSoftware)
    ->select(s | s.getPropertyValue('Fin maintenance').annee() < '2022')
    ->size()

Nous pouvons maintenant combiner les deux requêtes pour obtenir une évaluation du risque technologique associé à chaque application :

let 
  criticities = self.impactAnalysis('ApplicationComponent2BusinessProcesses')
     ->filter(archimate::BusinessProcess).getPropertyValue('Criticité') 
in 
  self.impactAnalysis('ApplicationComponent2SystemSoftware')
    ->filter(archimate::SystemSoftware)
    ->select(s | s.getPropertyValue('Fin maintenance').annee() < '2022')
    ->size() *(criticities
        ->count('Haute')*3 + criticities
        ->count('Moyenne')*2 + criticities
        ->count('Faible'))

Cette dernière métrique nous donne donc une évaluation du risque associé à chaque application.

Pour rappel, nous avons pris le point de vue applicatif et le risque est évalué en prenant en compte l’ensemble des processus métier servis par une application.

Par contre, si nous prenons le point de vue métier, nous allons plutôt nous intéresser au risque de défaillance du processus en combinant sa criticité à lui (et uniquement celle ci) avec une autre métrique : le nombre d’applications ayant un composant technologique devenant obsolète avant la date de décommissionnement de l’application.

Nous ne détaillerons pas les calculs de cette nouvelle métrique ici, même si nous l’utilisons dans la suite!

Production de rapports

L’activité de pilotage des risques requiert d’identifier rapidement les risques les plus importants pour les traiter en priorité. À partir d’un risque nous pouvons ensuite remonter à l’origine de celui-ci de manière à déterminer les actions qui permettront de limiter sa probabilité. Nous pourrions également évaluer l’ampleur des impacts si ce risque survient. Mais, comme indiqué précédemment, nous prenons ici le point de vue applicatif et il ne lui appartient pas de limiter l’impact du risque, celui-ci étant déterminé par les processus métier.

Le premier rapport que nous proposons est donc une cartographie graphique des risques applicatifs.

Dans notre référentiel, les applications sont classées par domaine en utilisant des objets ArchiMate Groupement. Nous pouvons utiliser ces groupements, pour construire automatiquement une carte qui représente l’ensemble des applications regroupées par domaine.

Après avoir déposé manuellement (par glisser/déposer) les groupements d'applications que l’on souhaite contrôler, une analyse d’impacts automatique calcule les applications concernées et les place automatiquement sur le diagramme, en leur appliquant une couleur sur la base d’un calcul de l’indice de risque :

• en rouge les applications à haut niveau de risque (l’indice est supérieur à 50)
• en orange les applications à niveau de risque moyen (l’indice est compris entre 20 et 49)
• en vert, les applications à faible niveau de risque (indice est inférieur à 20)

Si nous prenons le point de vue métier, nous pouvons produire une carte différente qui, elle, projette les applications sur les processus métier qui les utilisent :

Dans cette carte, les applications apparaissent potentiellement plusieurs fois, dans chaque processus qui les utilise. Ici, la couleur exprime une autre information : elle indique le risque de défaillance propre des applications (existence d’un composant technologique devenant obsolète avant le décommissionnement de l’application). L’usage de cette carte est différent de celui de la cartographie des risques applicatifs : elle permet aux propriétaires des processus de se faire une idée du risque technologique associé à leur processus.

Pour autant, lorsqu’une action de modernisation est décidée pour limiter le risque, ces deux diagrammes ne sont pas suffisants pour établir le lien entre une application et les composants technologiques qui l’implémentent. Pour cela nous proposons une table qui croise les applications avec les composants technologiques et qui évalue un indicateur de compatibilité entre les dates de décommissionnement et de fin de maintenance. Cette table est un exemple de ce qu’il est possible de faire avec l'outil SmartRequest de Obeo SmartEA pour fournir des indicateurs visuels forts :

En effet, cette table permet de retrouver en un coup d'œil les éléments fautifs grâce à un indicateur visuel coloré. Nous utilisons également le système de lien permettant de naviguer directement sur les éléments concernés.

Enfin, pour compléter l’ensemble de rapports, nous pouvons configurer un tableau de bord dans Obeo SmartEA qui permet, en un coup d'oeil, de se faire une idée des niveaux des différents indicateurs :

Les quatre widgets de ce tableau de bord montrent des métriques complémentaires sur la gestion de portefeuil applicatif :

• le risque applicatif permet de se rendre compte rapidement du niveau de risque global de son portefeuil en visualisant un histogramme des risques
• l'obsolescence applicative fournit un indicateur permettant d’anticiper les décommissionnements d’application à différents horizons
• l’obsolescence technologique fournit la même indication que la métrique précédente mais sur le patrimoine technologique de la DSI
• enfin, le dernier widget permet de contrôler la fiabilité des données qui servent à évaluer les métriques en identifiant l’état d’une campagne d’évaluation des applications dont on peut imaginer qu’elle serve à réaliser des mises à jour des données les concernants

Mot de la fin

Nous avons vu ici un exemple de paramétrage de Obeo SmartEA qui répond aux besoins d’une équipe de gestion de portefeuille applicatif.

Ce type de paramétrage, qui pourrait adresser d’autres besoins similaires, peut être effectué directement par les utilisateurs de l’outil, puisqu’il ne nécessite aucun développement spécifique.

En effet, pour réaliser ce paramétrage nous avons mis en oeuvre un module qui met à disposition des utilisateurs deux services génériques :

• l’analyse d’impacts automatique,
• la réalisation de cartes capacitaires dynamiques, basées une analyse d’impact, qui permettent de visualiser la valeur d’un indicateur à l’aide de couleurs.

Ces deux services ont uniquement recours à des requêtes AQL, ce qui les rend accessibles par tout utilisateur Obeo SmartEA maîtrisant ce langage de requêtage.

J’espère avoir convaincu mes lecteurs de la capacité de Obeo SmartEA à supporter les différents processus et points de vue d’une DSI et à offrir de réels services au-delà de la modélisation ArchiMate ou BPMN et de la collecte des données, ce, sans développement spécifique.

Le module que nous utilisons dans ce billet est pour l’heure expérimental mais nous pouvons le mettre à votre disposition pour une évaluation!

D'ici là vous pouvez également vous inscrire au webinaire que je présenterai le 14 décembre 2021 pour détailler ce sujet de la gestion d'obsolescence. J'aurai l'occasion de montrer concrètement comment réaliser ces requêtes et ces tableaux de bord avec Obeo SmartEA.