L'analyse d'impacts avec ArchiMate

L'analyse d'impacts, c’est la capacité à énumérer les conséquences, parfois lointaines, d'une modification du SI. Cette modification peut être très locale comme un décommissionnement de technologie ou plus ambitieuse comme une restructuration d’une fonction métier. Dans tous les cas, il s’agit probablement de la promesse la plus importante de l'architecture d'entreprise et de sa modélisation avec la notation ArchiMate.

En effet, l’idée de mettre la modélisation au service de l’architecture d’entreprise avec la notation ArchiMate ou avec toute autre notation, permet de tisser des liens entre les éléments qui composent une entreprise et de les représenter par une structure informatique. C’est cette structure informatique, qu’on nomme modèle, qui offre la possibilité de réaliser des traitements, des analyses automatisées sur les représentations de l’architecture.

L’analyse d’impacts consiste à identifier un ensemble d’éléments du modèle qui seront concernés d’une manière ou d’une autre par une évolution, un changement, ou l’évolution d’un risque. A ce titre, elle permettra un grand nombre d’analyses. Citons deux exemples pour illustrer l’importance de l’analyse d’impacts : l’introduction ou l’évolution d’un composant technologique et l’évaluation des risques technologiques.

Supposons qu’on souhaite faire évoluer une application en introduisant un nouveau composant technologique ou en procédant à une mise à jour d’un tel composant. L’analyse d’impacts permettra d’identifier de manière exhaustive tous les éléments à prendre en compte dans la réalisation d’une telle opération :

  • l’ensemble des applications qui dépendent du composant technologique concerné et qui seraient touchées par effet de bord,
  • l’ensemble des processus métier concernés par les applications touchées et les garanties de continuité de service qu’il faudra assurer,
  • l’ensemble des acteurs ou rôles concernés et qu’il faudra certainement former à la nouvelle technologie d’une manière ou d’une autre.

Dans cet exemple, on voit bien qu’une analyse d’impacts exhaustive est à la clé de la réalisation d’un plan d’action pour la mise en œuvre d’une évolution technologique et, partant, d’une conduite du changement efficace.

Plaçons-nous maintenant dans la perspective d’une évaluation périodique du risque technologique. Une application est implémentée par un écosystème composé de logiciels ayant un support à durée souvent limitée. L’impact sur une application du fait de s’approcher ou de dépasser la date de fin de support d’un de ces logiciels sera d’accroître la probabilité d’indisponibilité de cette application du fait de l’absence de support. Cette probabilité combinée à la criticité de l’application forme ce qu’on peut appeler le risque technologique. L’analyse d’impacts permet ici d’identifier l’ensemble des logiciels qui implémentent une application et d’évaluer de manière complète et fidèle la probabilité d’indisponibilité.

La notation ArchiMate permet de tisser des liens formels entre les éléments du SI qui permettent d’envisager de telles analyses d’impacts. Cette notation permet également de tisser des liens entre les différentes couches du SI (métier, applicatif, technologique, etc.) permettant des analyses d’impacts utilisées pour établir des plans d’action et des conduites du changement. Pour autant, la mise en œuvre d'une analyse d'impacts efficace, exhaustive et pleinement exploitable requiert un outillage adapté.

Nous avons consacré le webinaire du 15 décembre 2020 à montrer les moyens mis à disposition des utilisateurs pour conduire des analyses d'impacts dans l’outil Obeo SmartEA. Ces moyens sont riches et puissants mais ils restent manuels. Ils sont nécessaires et importants pour réaliser des analyses minutes ou pour mener ponctuellement des analyses d'impacts spécifiques.

Ils peuvent, en revanche, s'avérer insuffisants lorsqu'il s'agit de réaliser un type particulier d’analyse d'impacts qu'il faut répéter un grand nombre de fois (comme dans le cas de l’évaluation du risque technologique). Ils sont également difficiles à utiliser dans le cadre d'une analyse d'impacts impliquant un grand nombre d'éléments où l'exhaustivité de l'analyse peut être complexe à obtenir et à vérifier. Dans tous ces cas de figure, l’automatisation des analyses devient incontournable.
Nous décrivons ici un moyen, accessible à tout utilisateur maîtrisant ArchiMate, de réaliser une analyse d'impacts automatique répondant précisément à la question qui est posée et à cette seule question. Cet outil ouvre des perspectives importantes aux architectes et offre un moyen puissant d'exploiter, voire de maintenir, un référentiel d'architecture.

Une des principales caractéristiques du langage ArchiMate est la souplesse de sa notation qui propose un langage universel. Cette universalité permet de construire une communauté d'architectes en facilitant le partage de pratiques et d'expériences. Elle oriente également la notation dans une direction qui permet à chaque équipe de décider comment elle modélise son SI ou encore de répondre à des situations différentes avec des solutions différentes, adaptées :

  • Couvrir un vaste périmètre du SI de manière à se construire une image globale. Dans ce cas, nous allons modéliser de nombreux éléments avec peu de détails.
  • Détailler l'architecture d'une application afin de bien en comprendre les risques technologiques. Dans cette seconde situation, nous allons avoir recours à une modélisation détaillée permettant de faire le lien entre les composants techniques, d'infrastructure et l'application.
  • Modéliser l'environnement applicatif d'un processus métier. Dans cette situation, nous souhaitons détailler les liens entre applications et processus métier.

Paradoxalement, cette richesse constitue une difficulté importante pour pouvoir mener des analyses d’impacts automatiques car elle multiplie le nombre de façons différentes de modéliser un même système. Ce qui complique l’application de règles de parcours du modèle qui soient systématiques.

Frédéric Madiot a rédigé un billet de blog qui illustre bien les différentes solutions offertes par ArchiMate pour modéliser différentes situations.

Prenons quelques exemples concrets issus de ce billet:

Le diagramme suivant montre le détail de la communication entre deux applications au travers d'une interface en forme de service web. Cette approche découple les applications en les faisant s'adresser à des services applicatifs qui peuvent être implémentés par différentes applications. Elle répond au principe de couplage faible.

Le fragment de diagramme suivant montre les mêmes applications directement associées l'une à l'autres par des flux applicatifs :

Ces deux approches répondent à des impératifs et des besoins différents et sont toutes les deux aussi légitimes l'une que l'autre. Elles doivent faire l'objet d'un traitement spécifique lorsqu'il s'agit de mener une analyse d'impacts : dans le premier cas, il sera nécessaire de remonter la piste de l'interface et du service pour établir un lien entre applications alors que dans le second, il suffira de suivre les flux applicatifs.

Le diagramme suivant montre, sur une seule carte, plusieurs liens redondants qui répondent à des points de vue plus ou moins détaillés.

  • d'une part les services métier sont directement liés aux rôles métier par un lien de type "implémente" et qui pourraient faire l'objet d'une seule carte,
  • d'autre part, ces mêmes services métier sont liés aux rôles métier au travers d'interfaces métier qui détaillent comment il est possible d'accéder à ces services.


Ici, suivant que l'objectif de l'analyse consiste à identifier un ensemble de rôles métiers impactés ou un ensemble d'interfaces métier, on suivra des liens différents.

Ces exemples indiquent clairement que, de manière générale, l'analyse d'impacts prendra des chemins différents suivant ses objectifs et suivant les principes de modélisation retenus. Il apparaît alors qu'il est difficile de réaliser une analyse d'impacts automatisée universelle au sein d'un référentiel ArchiMate. Afin d'enfoncer le clou, notons que la matrice des relations possibles entre les concepts ArchiMate comporte 120 relations. Ce nombre reflète la richesse de la notation ArchiMate mais indique, dans le même temps, la complexité de réaliser des outils d'analyse d'impacts universels. De tels outils ne permettent tout simplement pas de cibler le besoin de l'utilisateur avec suffisamment de précision et son résultat en serait difficilement exploitable.


Une proposition d'analyse d'impacts automatique et générique

En réponse à ces préoccupations, nous proposons un mécanisme puissant qui repose justement sur cette richesse d’ArchiMate pour créer facilement des analyses d’impacts automatisées.

Ce mécanisme permet à l'utilisateur d'utiliser la notation ArchiMate elle-même pour spécifier les chemins à suivre pour conduire une analyse d'impacts. Cette spécification peut ensuite être exploitée, par un service générique dans une requête Obeo SmartEA, pour calculer automatiquement le résultat de l’analyse d’impacts depuis un objet particulier du référentiel.

Pour illustrer cette approche, nous nous proposons de répondre à la question suivante : "étant donnée une application, quels sont les composants technologiques (logiciels système) qui contribuent à son implémentation ?".

La réponse à cette question peut servir, dans le cadre de l’évaluation périodique des risques technologiques que nous avons évoquée plus haut.

L’outil d'analyse d'impacts déjà fourni par Obeo SmartEA est tout à fait adapté pour mener la première étape de ce travail. Cet outil nous permet de construire manuellement une carte sur laquelle nous pouvons afficher un élément du modèle et choisir parmi les objets qui lui sont connectés lesquels faire apparaître. En prenant l'exemple de l’application “Système de réservation”, nous pouvons ainsi montrer ses composants et les éléments technologiques sur lesquels ils sont déployés :


Cette carte illustre les liens entre une application et son écosystème technologique. L’idée que nous proposons est d’utiliser ces analyses d’impacts manuelles pour généraliser les liens que nous y identifions et en extraire des motifs (pattern en anglais) de modélisation présents dans le référentiel et à utiliser pour réaliser une analyse d’impacts. Nous représentons ces motifs par un fragment de modèle ArchiMate. Le fragment que nous déduisons à partir de la carte ci dessus est décrit dans la figure qui suit :

 

Le lien entre les deux diagrammes est illustré par l’image suivante dans laquelle nous mettons en relation les éléments du fragment avec les éléments d’architecture qu’ils représentent :

De la même manière, les relations du fragment sont issues des relations du modèle. Par exemple, la relation d’attribution du nœud vers lui-même dans le fragment représente toutes les relations entre L’élément ‘Config back-end réservation’ et les composants technologiques qui lui sont attribués (WebSphere AS7, Elastic Search, etc.).

A partir de cette spécification qui décrit un parcours au travers d’un modèle ArchiMate, nous pouvons implémenter un mécanisme chargé de calculer automatiquement les résultats d’une analyse d’impacts selon ce parcours. Le principe est relativement simple : lorsque dans le calcul d’une analyse d'impacts on rencontre un élément d’un type ArchiMate présent dans la spécification de l’analyse d’impacts (par exemple “Noeud”), les relations pertinentes à suivre sont celles qui figurent sur l'élément de ce type dans la spécification (“implémente”, “attribuée à”, “regroupe” et “composée de” pour le type “Noeud”). On peut alors suivre le chemin inverse de celui qui nous a conduit à construire le fragment de droite : depuis l’élément "Noeud’" de mon fragment, j’ai une relation d’attribution vers les composants technologiques. Dans l’analyse d’impacts, j’inclue tous les composants technologiques accessibles en suivant une relation d’attribution depuis les éléments de type "Noeud" que j’ai déjà inclus. En poursuivant cette règle pour tous les éléments présents dans mon analyse jusqu’à ce que plus aucun élément ne puisse être ajouté on complète l’analyse d'impacts.

Les lecteurs attentifs auront noté que certaines relations doivent être parcourues "à l'envers". C'est le cas, par exemple, de la relation d'implémentation entre composants applicatifs et nœuds, ou encore de la relation d'attribution entre les nœuds et les machines.

Nous marquons ces relations avec le système de propriétés dynamiques pour indiquer qu'elles doivent être parcourues depuis la cible vers la source dans le cadre de cette analyse d'impacts :

 

Mise en œuvre dans Obeo SmartEA

Le mécanisme décrit ci-dessus a été automatisé au travers d’un service nommé “impactAnalysis”. Celui-ci peut être invoqué sur un élément source, en passant en paramètre le nom du fragment qui spécifie l’analyse d’impacts à effectuer.

Concrètement, l’appel de ce service d’analyse d'impacts peut se faire dans tous les contextes où une requête AQL est exploitable.

Par exemple, si nous souhaitons répéter l’analyse d’impacts réalisée manuellement sur le système de réservation, il suffit d’exécuter la requête suivante qui recherche le composant applicatif “Système de réservation” et invoque le service "impactAnalysis" sur le fragment décrit précédemment que nous avons appelé “ApplicationComponent2SystemSoftware” :

aql:self.applicationByName('Système de réservation').impactAnalysis('ApplicationComponent2SystemSoftware')

Utilisée dans le champ de recherche, cette requête permet de peupler le panier avec le résultat de l'analyse d'impacts :

Il est alors possible de mettre ce résultat en forme par simple drag&drop du contenu du panier sur un diagramme libre ArchiMate.

L’analyse d’impacts est désormais complète et peut être communiquée aux personnes concernées.

Nous avons présenté dans ce billet une analyse d’impacts automatique et sa mise en œuvre dans le contexte de la recherche avancée de Obeo SmartEA. Il est également possible de mettre ce service d’analyse d’impacts en œuvre dans de nombreux autres contextes, en particulier, en paramétrant des requêtes tabulaires (SmartRequest) ou en créant des relations dérivées. Il est possible de tester Obeo SmartEA en suivant ce lien. Si vous êtes intéressé par le test du nouveau mécanisme que nous présentons dans ce billet, dites-le nous et nous vous donnerons les moyens de l’évaluer.

Challenges and Practical Solutions for MBSE
Sirius Web Behind the Scene #3

Related Posts