La gestion de l'obsolescence du parc applicatif d'une entreprise est une pratique importante au sein d'une DSI et qui répond à des enjeux forts. Le premier est de maintenir la disponibilité des applications en veillant à ce que les socles technologiques aient un cycle de vie en phase avec celui des applications. Le second est d’optimiser l’utilisation du budget de modernisation.

L’obsolescence d’une application vient le plus souvent de l’obsolescence d’un composant qui l’implémente. Par exemple, une application de CRM qui s’appuie sur le logiciel SugarCRM deviendra obsolète aussitôt que la version du logiciel SugarCRM déployée ne sera plus supportée par l’éditeur. A ce stade, l’application CRM sera en risque.

Dans ce billet, nous montrons, pas à pas, comment mettre en place des outils permettant de détecter ces situations et de les anticiper avec l'outil Obeo SmartEA.

Le cycle de vie des logiciels est illustré par le schéma suivant :

Suite au retrait complet, il n’est en général plus possible de passer de contrat de support et plus aucune mise à jour ni correctif n’est possible sans passer aux versions supérieures.

Il reste toujours possible de conserver un composant en production au-delà de son retrait complet, mais ce choix a des conséquences néfastes sur les applications que ce composant implémente :

• cela peut rendre l'application indisponible à cause de la défaillance du composant et de l'impossibilité d'en rétablir le fonctionnement,
• cela rend souvent l'application vulnérable à des attaques du fait de l'impossibilité de procéder à des mises à jour du composant technique,
• cela peut rendre indisponible des documentations, formations, etc.

La gestion de l’obsolescence permet d’éviter ces écueils et consiste globalement à maintenir en phase les cycles de vie des applications avec ceux des logiciels qui les implémentent. La figure suivante illustre un tel déphasage sur l’exemple du CRM :

Dans un cas comme celui-ci, il faut anticiper pour mettre à jour l’application CRM avec un composant SugarCRM plus récent de manière à pouvoir le mettre en production avant la date du 30 avril !

Ce travail de modernisation sur le parc applicatif requiert une boussole pour être priorisé correctement. Par exemple, en traitant préventivement en premier lieu les applications les plus complexes ou celles dont l’échéance d’obsolescence est la plus proche, afin d’éviter d’avoir à traiter une défaillance dans l’urgence, ou encore en traitant les applications les plus critiques vis-à-vis du métier si cette information est disponible.

Les objectifs que nous nous fixons sont les suivants :

• identifier et catégoriser de manière exhaustive les applications qui deviennent obsolètes dans les 2 ans, dans les 5 ans et au-delà,
• identifier les composants technologiques à l’origine de l’obsolescence.

En partant de ces objectifs, nous allons déployer une démarche en trois étapes :

• Définir des métriques permettant de progresser vers son objectif (dans notre cas, il s’agit du temps qu’il reste avant qu’une application ou un système logiciel ne devienne obsolète),
• Mesurer : collecter l’information, la consolider, et calculer les métriques,
• Restituer : produire des livrables à partir de ces métriques permettant de piloter et de prendre des décisions.

Cet article est le premier d’une série de deux billets dans lesquels nous décrivons une approche de la gestion d’obsolescence qui s’appuie sur les couches applicatives et technologiques :

Dans un premier temps, nous nous intéresserons à la mise en œuvre d’une collecte de données avec Obeo SmartEA.

Dans l’article suivant, nous décrirons comment nous pouvons construire des indicateurs et des analyses utiles à la gestion d’obsolescence, et comment restituer ces éléments avec des représentations tabulaires ou graphiques.

La collecte des données est organisée en trois volets :

• organiser le stockage de l’information dans le référentiel,
• définir les moyens de collecte et de mise à jour de l’information,
• mettre en place les contrôles permettant d’évaluer l’état du référentiel vis-à-vis de la collecte.

Stockage des informations

Le stockage des informations doit définir trois points :

• Où sont stockés les objets dans le référentiel (dossier, sous-dossier) ?
• Comment les données de gestion sont attachées aux éléments du référentiel ?
• Les règles qui permettent de déterminer si les données renseignées sont correctes du point de vue de leur forme.

La façon de ranger les éléments dans le référentiel doit faire l’objet d’un choix décrit dans une architecture de référence. Ce choix permet de maîtriser l’organisation du référentiel, mais également les droits d’accès aux différents éléments : les permissions (lecture / écriture) étant octroyées par dossier dans Obeo SmartEA.

Ici, nous utilisons la hiérarchie suivante :

Pour ce qui concerne la définition des données de gestion, ArchiMate permet de créer dynamiquement des propriétés attachées aux objets d’un référentiel. Cela se fait simplement, dans le modeleur Obeo SmartEA, à l’aide de la vue Propriétés :

 

On y ajoute une propriété en renseignant son nom dans la colonne “clé” et sa valeur dans l’autre colonne. La valeur est alors propre à l’élément du référentiel.

Il s’agit d’un moyen d’extension propre à ArchiMate et qui permet d’implanter des processus de gestion qui s’appuient sur des données définies par les utilisateurs.

Dans l’exemple de ce billet, nous allons utiliser deux propriétés attachées à chaque application et une propriété attachée à chaque système logiciel :

Objet cible	Donnée	Description
Composant applicatif	EtatEvaluation	Etat vis-à-vis de la mise à jour du référentiel (par exemple, revue et mise à jour de la modélisation du socle technique de l’application concernée).
Composant applicatif	Décommissionnement	Date à laquelle une application sera décommissionnée
Système logiciel	Fin maintenance	Date à laquelle un système logiciel arrive en fin de support.

Moyens de collecte

Plusieurs moyens s’offrent à l’utilisateur de Obeo SmartEA pour renseigner les propriétés lors de la collecte des informations. Le premier est celui que nous avons mentionné dans la section précédente : l’utilisation directe de la vue propriété du modeleur.

Les propriétés peuvent également être éditées directement via le client web :

Cette facilité permet de mettre de nombreux acteurs à contribution pour la collecte des données en ouvrant des accès aux acteurs des départements responsables des composants en question (applications, systèmes logiciels, ...).

Bien entendu, la création de profils utilisateurs permet de limiter les droits de ces utilisateurs à l’édition des objets qui les concernent.

Dans certains cas de figure, les données peuvent également être déjà présentes dans d’autres référentiels de la DSI (CMDB, référentiel d’applications, etc.). Obeo SmartEA se positionne comme une solution ouverte qui facilite la fédération de référentiel et dans une situation où les données peuvent être sourcées dans un référentiel tierce, il est extrêmement profitable d’utiliser cette facilité. Ne serait-ce que via l’import d’un classeur Excel. En effet, on gagne un temps considérable à procéder de la sorte et on évite toute erreur de saisie ou d’interprétation des données.

Cela peut être fait depuis le modeleur ou le client web via les pages de détail des répertoires :

Un classeur d’import doit avoir la forme suivante :

Les propriétés y sont représentées par des colonnes qu’il est possible d’éditer à volonté avant d’importer le classeur pour mettre le référentiel à jour.

Il est également possible d’exporter un dossier pour y mettre à jour les éléments en masse avant de les réimporter. C’est d’ailleurs un moyen extrêmement commode d’avoir un modèle au bon format pour réaliser un classeur d’import.

Pour une connexion pérenne et automatisée, Obeo SmartEA offre une API qui permet d’établir des connexions avec des applications tierces, selon des formats qui peuvent être spécifiques, afin de construire un référentiel d’architecture par fédération des référentiels existants. L’automatisation des connexions facilite la pérennisation des processus mis en œuvre autour de Obeo SmartEA.

Contrôles et validations

Quel que soit le mode de collecte des données, il est indispensable de pouvoir déterminer l’état du référentiel vis-à-vis de la collecte. En effet, les processus les plus sophistiqués et les plus efficaces produiront des résultats totalement inutiles, voire contre-productifs, s’ils sont déroulés sur des données qui ne sont pas en phase avec la réalité du SI.

Ici il est question de la gestion d’obsolescence, mais tous les processus de gestion de SI doivent s’assurer avant tout de la qualité et de la fiabilité des données sur lesquelles ils appuient leurs activités. C’est la première étape avant de passer à l’exploitation du référentiel. Pour que les analyses d’impacts fournissent des résultats corrects et complets, cette étape doit comporter des mises à jour et des vérifications de la modélisation elle-même.

Pour aider dans cette tâche, Obeo SmartEA offre plusieurs outils qui peuvent être utilisés conjointement :

Les règles de validation permettent de contrôler les règles de stockage des données :

• vérifier que les objets sont stockés dans les dossiers prévus à cet effet,
• vérifier que les objets concernés ont des valeurs correctement renseignées.

Les tableaux de bord permettent de suivre la progression de la collecte et de visualiser l’état de son référentiel.

Nous définissons une règle par propriété permettant de valider le renseignement de ces éléments sur tout le référentiel :

Ces règles permettent de valider non seulement la présence de la propriété, mais également le fait que la valeur renseignée est au bon format.

Pour une date, on valide qu’elle a bien le format jj/mm/aaaa à l’aide d’une expression régulière :

self.propertyDefined('Décommissionnement') and self.getPropertyValue('Décommissionnement').matches('[0-9]{2}/[0-9]{2}/[0-9]{4}')

Pour une valeur devant appartenir à une liste prédéfinie, on utilise le service correctProperty du langage de requêtage :

self.correctProperty('EtatEvaluation','DONE,TODO,DOING')

Enfin, pour le positionnement des éléments dans des dossiers spécifiques, on utilise des services de navigation dans les dossiers :

self.parentFolder().name='Technologies' and self.parentFolder().parentFolder().name='Système d\'Information'

Ici, le service parentFolder renvoie le dossier contenant l’objet sur lequel on appelle le service. Cela permet de contrôler toute la hiérarchie de stockage d’un objet.

Ces règles sont définies de manière relativement simple grâce à la présence de services riches dans le langage de requêtage de Obeo SmartEA.

À ce mécanisme de validation s’ajoute la possibilité de paramétrer des widgets de suivi dans le tableau de bord de la page d’accueil. Par exemple, la figure suivante décrit un histogramme des applications réparties par état d’évaluation :

Cet histogramme permet de suivre l’état de la revue du parc applicatif en temps réel, sans passer par la validation. Il est paramétré à l’aide de requêtes du même type que celles employées pour les règles de validation :

Par exemple, la requête pour retrouver l’ensemble des applications évaluées fait appel au service de recherche par propriété :

self.childrenByProperty('EtatEvaluation',’DONE’)->filter(archimate::ApplicationComponent)

Le service childrenByProperty renvoie l’ensemble des objets ayant la valeur spécifiée dans la propriété indiquée. On filtre ensuite pour ne conserver que les composants applicatifs.

Mot de la fin

Dans un processus de gestion implémenté à l’aide d’un référentiel d’architecture d’entreprise, la collecte des informations est souvent la phase la plus longue et la plus complexe à réaliser si l’on souhaite maîtriser la qualité des données qui sont collectées.

Obeo SmartEA simplifie cette phase en offrant des outils permettant de mener à bien ces campagnes de collecte, et de les automatiser lorsque les données sont présentes dans des référentiels tierces.

Dans cet article, nous avons présenté une approche de collecte qui peut être mise en œuvre grâce à ces outils :

• spécifier les éléments à collecter,
• spécifier l’emplacement et la forme des données,
• contrôler que la collecte respecte ces spécifications,
• piloter la collecte des informations à l’aide d’indicateurs adaptés.

Les principes décrits dans ce billet s’appliquent à de nombreux autres processus de gestion (citons, l’analyse des risques technologiques, les analyses de coûts, etc.) et ont une portée générale.

Dans un prochain billet, nous aborderons le volet suivant de l’analyse d’obsolescence : la restitution des informations permettant de conduire le processus de gestion dans sa dernière phase.

En attendant, retrouvez certaines fonctionnalités décrites dans cet article dans cette vidéo enregistrée lors de l'un de mes précédents webinaires :

 

Pour tester les outils présentés dans cet article, n’hésitez pas non plus à nous demander une version d’évaluation de Obeo SmartEA.