Les relations à rendre visibles
Pour chaque dépendance importante, préciser le responsable, l’usage, le mode de défaillance et l’alternative disponible. Vérifier les dépendances communes : deux solutions peuvent sembler indépendantes tout en partageant une identité, une plateforme, une compétence ou un contrat.
Découper davantage n’est pas toujours mieux. Une architecture trop fragmentée peut accroître les coûts d’exploitation et la difficulté de diagnostic.
Définir les domaines, les services exposés, les données de référence et les frontières de responsabilité, tout en documentant les dépendances transverses.
Une séparation théorique peut masquer un couplage réel par base de données, fichier partagé ou compétence unique.
Application à votre contexte
Pour chaque relation importante, précisez l'usage, le responsable et ce qui se passe en cas d'indisponibilité. Cherchez aussi les ressources communes qui rendent plusieurs alternatives moins indépendantes qu'elles ne le paraissent.
Commencez par un périmètre utile à une décision : une transformation, une dépendance critique ou un portefeuille d'applications. Reliez les vues métier, applicative, données et technique. Une notation rigoureuse est utile, mais elle ne remplace ni un responsable de l'information ni une question de départ claire.