Proposition, justification et choix des architectures concurrentes

La sélection d’une architecture parmi plusieurs architectures concurrentes se fait selon un processus de sélection qui doit être justifié sur la base de critères, sélectionnés selon les principes de l’ingénierie système, critères selon lesquels l’architecture peut être évaluée selon ses forces et faiblesses.

Parmi les principaux écueils, on notera :

• Il n’y a pas assez de solutions candidates. C’est souvent induit par trop de contraintes : manque de temps, de moyens et parfois d’imagination (on est déjà content d’avoir une solution répondant aux besoins).
• Dans les processus itératifs rapides (y compris les processus AGILES), il est parfois délicat de positionner dans le cycle, l’identification d’architectures candidates et les justifications. On a tendance à présenter la solution obtenue.
• Pas de justification capitalisée au moment de la conception, ce qui entraîne du rétroengineering après coup, ou de la perte d’informations et des difficultés à apporter les justifications lors d’un audit, de l’analyse d’impacts ou d’évolutions ultérieures.
• Analyse boîte noire insuffisante, ce qui entraîne un biais dans la sélection des critères, des parties prenantes…
• Ne pas anticiper la variabilité des besoins dans l’évaluation des architectures candidates.
• Mauvais choix des critères permettant de choisir entre les architectures concurrentes : mauvaise prise en compte du non-fonctionnel (évolutivité, résilience…), critères de différences…
• Ne pas prendre en compte l’architecture du modèle de données qui est clef sur certains types de systèmes.
• Implication de trop peu de parties prenantes ou surreprésentation de certaines parties prenantes (marketing, client…).
• Pas de factualisation des critères : l’évaluation n’est plus objective.

Voici quelques bonnes pratiques à prendre en compte :

• Prévoir cette phase dans le processus de développement : imposer par exemple une revue technique régulièrement dédiée à ce sujet (1 fois par mois par exemple), ou un critère aux jalons projet, ou encore un questionnement tous les x sprints.
• Ajuster l’effort au niveau du risque et de l’enjeu associé en fonction des sujets.
• Faire émerger des architectures en rupture en organisant des ateliers créativité et innovation.
• Mettre en place une bonne gestion de la connaissance (dont systèmes passés, veille techno et brevets…).
• Modéliser et décrire les différentes alternatives pour aider à les présenter, les valider, et faire les choix en connaissance de cause.
• Communiquer au travers des diagrammes de l’architecture afin de s’en servir de supports au discours.
• Utiliser des processus de positionnement des architectures les unes par rapport aux autres : la matrice de Pugh, analyse risque/valeur, effort/bénéfice, matrice DSM…
• Utilisation d’outils logiciels permettant d’explorer rapidement un grand nombre d’architectures.
• Réaliser un prototype pour les cas où le risque en jeu le justifie (c’est le principe du POC).
• Pour des évolutions, il est intéressant de comparer avec le statu quo pour challenger l’apport de valeur.
• Pour le modèle de données (des systèmes d’information), distinguer et relier le modèle conceptuel au modèle d’implémentation (ex : un modèle conceptuel complet – au sens mathématique – peut donner un modèle d’implémentation complexe et coûteux).

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 inscrivons l’identification d’options et non pas une seule architecture dans le processus de conception.
“ Nous nous posons systématiquement la question de l’enjeu associé à la conception. C’est ce qui drive nos choix d’alternatives.
“ Nous utilisons un Novelty Ranking qui évalue le risque qu’on prend en fonction du nombre de fois où la solution a été déployée.