Évaluer la maturité de la définition de l’architecture

Il convient ici de bien définir les objectifs en début de projet vis-à-vis des indicateurs, de mettre en place des indicateurs de maturité en début de projet et de faire des revues (de pairs) de manière régulière (à la fois d’audit et ingénierie collaborative).

Parmi les principaux écueils, on notera :

• Ne pas piloter la montée en maturité de la définition
• Avoir des indicateurs qui ne sont que sur la production d’éléments et pas sur leur qualité
• Lier l’avancement contractuel à des indicateurs uniquement de production de documents ce qui peut conduire à maintenir deux jeux de documentations ou pire que la documentation ne soit que pour le reporting
• Réutiliser des architectures existantes dont la maturité est avérée peut empêcher d’identifier des axes d’amélioration
• Une hypothèse de réutilisation stricte mal analysée peut ne pas s’accorder avec le contexte d’utilisation réel et générer des réajustements potentiellement coûteux
• Difficulté d’identifier la maturité de sujets en innovation ou de domaines inconnus
• La maturité d’un système n’est pas la somme de la maturité de ses constituants (propriétés émergentes, intégration…)
• Ne pas monitorer la maturité de la définition sur l’ensemble du cycle de vie (en particulier sur les phases aval à la conception)
• Oublier la maturité des interfaces dans l’évaluation de la maturité de la définition de la solution
• Oublier la maturité du modèle de données dans l’évaluation de la maturité de la définition de la solution
• Ne pas prendre en compte l’évolution des enjeux dans le suivi de l’évolution de la maturité
• Faire de l’évaluation de la maturité de la définition de la solution un travail en chambre

Voici quelques bonnes pratiques à prendre en compte :

• Mettre en place quelques critères d’évaluation standard même de haut niveau, instanciables par les projets, et structurant pour donner une vision transverse aux projets au management et aux architectes. Voici quelques idées :
  • Évaluer la maturité par rapport à l’ensemble du cycle de vie, des use cases, des fonctions et scénarios opérationnels
  • Fonctionnalité : Est-ce que les Use Cases sont identifiés et correspondent aux besoins des stakeholders. Est-ce que les fonctions, la décomposition et les dépendances fonctionnelles sont identifiées ?
  • Structuration : Est-ce que les sous-systèmes, composants sont clairement définis et organisés ?
  • Organisation : Quel est le niveau de correspondance entre l’organisation (incarnation & communication) et la structuration de la solution
  • Interfaces : Identification des interfaces externes et internes (fonctionnelles/physiques) et leur nombre
  • Allocation : Est-ce que les fonctions sont allouées aux composants ? Est-ce que les interfaces fonctionnelles sont allouées aux interfaces Physiques ?
  • Taux de réutilisation (de composants, de patterns, d’interfaces …)
• Dissocier la documentation/livrable (ex : fichier word) des éléments d’architecture qui le constituent (ex : modèles, données …)
• Faire des revues d’évaluation régulières de la maturité de la définition de la solution avec les bonnes parties prenantes (l’équipe technique, les experts sur l’ensemble du cycle de vie)
• Prendre en compte l’avis des experts et responsables des lots
• Prévoir dans le développement des boucles de maturité progressives

Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette phase :

“ Nous avons mis en place un fichier de complétude des architectures qui suit chaque attendu des analyses d’architectures en termes de livrables et d’activités (ex : taux d’étude des phases de vie, nombre de cas d’utilisation, de scénarios…) ce qui permet de définir l’avancement sur l’architecture.

“ Nous suivons l’avancement de la définition de l’architecture sur deux axes : le nombre de macro-uses cases étudiés (défini dès le départ de la conception) d’une part et la qualité de l’analyse (basée sur le nombre de peer reviews) réalisée sur ces cas d’utilisation d’autre part.

“ Outils intéressants disponibles à l’INCOSE (SRL System Readiness Level) & NASA (ARL Application Readiness level) pour instanciation.