Contexte d’architecture, sources et actualisation des données

Une application décrite dans plusieurs sources

Une équipe de migration trouve une application retirée dans le portefeuille, active dans la CMDB et encore couverte par un contrat fournisseur. Chaque enregistrement répond à une question différente. Avant de l’exclure de l’analyse d’impact, l’équipe vérifie si l’application fonctionne encore et qui l’utilise.

Un système de référence fait autorité pour un ensemble de faits défini. Le registre des contrats peut porter l’échéance signée ; l’inventaire d’exploitation peut confirmer le composant déployé. Ces systèmes peuvent aussi contenir des relations utiles. Le modèle d’architecture relie les faits nécessaires à la décision en conservant leurs sources.

Le contexte nécessaire au changement

Pour une migration des paiements, le contexte utile comprend les applications, les capacités servies, les interfaces, les données concernées et les exigences de la solution. Un lien entre service et application diffère d’un lien entre deux applications. Le type et le sens de la relation doivent être conservés.

L’ADD reprend ce contexte pour décrire l’existant, comparer les options et consigner les décisions. Les systèmes sources continuent de porter leurs données opérationnelles ou contractuelles. Une valeur copiée dans le modèle d’architecture demande une source et une règle de rapprochement lorsque l’original change.

Dans ArchiLU, un assistant peut récupérer ce contexte par MCP et créer ou compléter un ADD. L’architecte vérifie le périmètre et les faits avant de présenter les options. La revue doit encore rechercher les dépendances absentes de la réponse et de la cartographie.

L’acquisition et le rapprochement des données

Choisir la source de chaque fait avant l’import. L’équipe applicative peut vérifier l’usage métier, les achats confirmer le contrat et l’exploitation confirmer un composant déployé. Un import qui réunit ces sources demande encore une règle pour reconnaître la même application.

Les identifiants stables des sources facilitent le rapprochement. Les noms seuls peuvent masquer un doublon ou fusionner deux systèmes distincts. Conserver les valeurs contestées jusqu’à leur résolution par le responsable du fait et motiver la priorité donnée à une source.

• Identifier la source, la date de collecte et le responsable de chaque jeu importé.
• Rapprocher les enregistrements par des identifiants stables et revoir les cas ambigus.
• Vérifier le type et le sens des relations avant d’accepter les liens.
• Transmettre les conflits et les références manquantes au responsable du fait.
• Appliquer les corrections acceptées par le processus de changement autorisé.

L’actualité de chaque fait

Une fiche modifiée hier peut encore contenir une interface que personne n’a vérifiée depuis un an. La date d’import prouve le moment de la copie. Une vérification demande une source, une date et une personne ou une procédure ayant contrôlé le fait concerné.

La fréquence de revue suit le rythme de changement et l’usage de l’information. Un inventaire de déploiement et une description de capacité métier peuvent avoir des calendriers différents. Avant une décision de migration, revérifier les dépendances qui peuvent changer le résultat, même si leur revue périodique n’est pas échue.

L’assistant peut tenir compte de l’actualité d’un fait si le contexte récupéré la précise. Si cette information manque, la réponse indique l’incertitude et la vérification nécessaire. L’absence d’une relation ne prouve pas l’absence d’une dépendance.

Une revue de préparation délimitée

Choisir cinq applications concernées par un changement prévu. Pour chacune, confronter le responsable, l’état du cycle de vie et les dépendances enregistrés à la source opérationnelle et à l’équipe applicative. L’échantillon reste lié au travail à préparer.

Demander à l’assistant les applications touchées et un brouillon d’analyse d’impact. Vérifier chaque objet cité et examiner les liens manquants. Pour ce pilote, relever les erreurs factuelles, les dépendances inconnues et le temps de correction.

Si les preuves restent incomplètes, limiter la conclusion au périmètre vérifié. L’ADD peut laisser une interface nommée en attente de confirmation. Le décideur voit alors quelle partie de la proposition dépend de cette réponse.

Les responsabilités après le pilote

Le responsable applicatif vérifie les usages et les dépendances avec l’exploitation. L’équipe architecture maintient les noms communs et les règles de relation. Les achats actualisent les données contractuelles. Le responsable du projet fait répondre aux points ouverts avant la décision concernée.

Rattacher la revue aux événements existants : mise en production, renouvellement fournisseur, retrait d’application ou migration achevée. Une correction trouvée en préparant l’ADD doit mettre à jour le modèle par le processus autorisé. Sinon, le projet suivant retrouvera la même erreur.

Vérifier les accès à chaque source et les lieux de traitement de l’assistant utilisé. Lors du partage du contexte, tenir compte des droits de la source d’origine et de sa copie dans le modèle d’architecture.