Analyse d’impact du SI : que vérifier avant de retirer une base de données ?

Le remplacement d’une application approche. Sa base de données fait aussi partie des composants à retirer. Mais avant de confirmer son arrêt, une question reste ouverte : quelles autres applications l’utilisent encore ?

Une application de reporting peut continuer à y lire des données après la migration de l’outil principal. Pour préparer le retrait, il faut retrouver ces dépendances et identifier les activités métier concernées.

L’analyse d’impact de Boldo, introduite dans la release d’automne, suit les relations de votre référentiel à partir des actifs que vous choisissez. Elle vous aide à repérer les applications et les activités à examiner avec les équipes avant le retrait.

Partir de la base dont le retrait est prévu

Prenons un exemple fictif. La base « Clients historique » est utilisée par deux applications : « CRM historique », dont le remplacement est prévu, et « Reporting commercial ». La première soutient la gestion de la relation client ; la seconde, le pilotage commercial.

L’équipe de migration travaille déjà sur le CRM. Elle doit maintenant vérifier si la base peut être retirée au même moment. L’analyse doit donc partir de la base elle-même.

Dans Boldo, choisissez-la comme source. L’analyse retrouve les applications qui lui sont reliées dans le référentiel. Vous n’avez pas à reconstruire ces liens manuellement à partir des seules dépendances que vous connaissez déjà.

Si votre revue concerne plusieurs bases, vous pouvez aussi définir les sources par un filtre, par exemple à partir d’un statut renseigné dans l’inventaire. Ici, sélectionnez uniquement « Clients historique ».

Retrouver les applications qui utilisent la base

La première étape consiste à retrouver les applications utilisatrices. Pour cela, choisissez la relation qui les relie à la base et le sens dans lequel la parcourir.

Dans le référentiel, la relation « utilise » va de l’application vers la base. Pour retrouver les applications utilisatrices, partez de la base et suivez cette relation en sens inverse. Les flèches affichées restent orientées de l’application vers la base.

Dans notre exemple, ce parcours fait apparaître le CRM historique et le reporting commercial. Le retrait de la base concerne donc aussi l’équipe qui prépare les rapports commerciaux.

Avant de confirmer la date d’arrêt, vérifiez avec cette équipe si le reporting utilise encore la base, quelles données il y récupère et quelle source pourrait la remplacer. Boldo rend visible la dépendance renseignée dans le référentiel ; les responsables de l’application peuvent ensuite confirmer son usage réel.

Remonter aux activités métier concernées

La liste des applications donne un premier périmètre technique. Pour comprendre les conséquences possibles sur le métier, poursuivez l’analyse vers les capacités métier qu’elles soutiennent.

Boldo permet d’enchaîner des étapes, chacune avec ses relations à suivre. Dans cet exemple, la première retrouve les applications qui utilisent la base. La seconde suit les relations entre ces applications et leurs capacités métier.

Le CRM historique mène à « Gestion de la relation client ». Le reporting mène à « Pilotage commercial ». Le projet de remplacement du CRM doit donc aussi tenir compte de la continuité des rapports commerciaux.

Pour comprendre pourquoi une capacité apparaît dans le résultat, suivez les liens qui la relient à la base via une application. Vous pouvez alors examiner cette dépendance avec le responsable métier concerné.

Vérifier les dépendances avant de conclure

Pour le reporting commercial, demandez à son responsable si l’application lit encore cette base. Trois situations sont possibles :

• Elle utilise toujours la base. Il faut prévoir comment maintenir cet usage après le retrait.
• Elle utilise désormais une autre source. Mettez le référentiel à jour pour que les prochaines analyses reflètent ce changement.
• Son usage reste incertain. Identifiez la vérification à mener avant de confirmer la date d’arrêt.

Une application absente du résultat peut néanmoins utiliser la base. Une relation manquante, un mauvais sens de parcours, un filtre, une condition d’arrêt ou des droits d’accès limités peuvent expliquer cette absence. Vérifiez aussi les avertissements indiquant que le calcul ou les chemins affichés sont incomplets.

L’analyse aide à repérer les dépendances à vérifier avec les équipes. Elle ne suffit pas, à elle seule, à confirmer que la base peut être arrêtée.

Consulter le guide de l’analyse d’impact

Préparer la revue de retrait avec les équipes

Sauvegardez la configuration de l’analyse pour la réutiliser au fil du projet. La sauvegarde ne fige pas les résultats : ceux-ci sont recalculés à partir des données accessibles lors de la consultation.

Pour préparer un atelier, convertissez le résultat en diagramme. Vous pouvez alors organiser les cartes et ajouter les annotations utiles à la discussion.

Dans notre exemple, une note près du CRM indique « Reprise prévue dans le projet CRM ». Une autre, près du reporting, précise « Usage de la base à confirmer avant retrait ».

Le comité peut ainsi examiner trois questions concrètes :

• La reprise des usages du CRM est-elle suffisamment préparée ?
• Le reporting utilise-t-il encore la base ?
• Faut-il prévoir une autre source de données avant son arrêt ?

Avant chaque nouvelle revue, reprenez l’analyse sauvegardée et vérifiez si les dépendances ont changé. Contrôlez ensuite que le diagramme présente toujours les éléments à examiner. Pour préparer un support lisible, consultez nos conseils sur les diagrammes d’architecture applicative.