Cette activité vise à :
1. Spécifier les comportements du système sous la forme d’une architecture fonctionnelle en identifiant et hiérarchisant les fonctions internes du système, en définissant et en synthétisant les interfaces fonctionnelles existantes entre ces fonctions par le biais à la fois d’un diagramme d’interactions fonctionnelles et d’un arbre de décomposition fonctionnelle (également appelé Function Breakdown Structure ou FBS). On définit enfin les modes de fonctionnement du système.
2. Allouer les fonctions internes du système aux composants par le biais d’une architecture logique puis physique en identifiant d’abord les composants qui implémentent les fonctions internes à l’aide d’une matrice d’allocation, puis en hiérarchisant ces composants et en définissant enfin leurs interfaces via un diagramme d’interactions.
3. Mettre en œuvre un protocole de convergence et de justification itératif vis-à-vis des parties prenantes et des équipes sous-systèmes en construisant et en faisant évoluer des vues d’architecture. L’objectif est de faire adhérer toutes les parties prenantes à
une même vision de l’architecture du système afin d’en sécuriser la définition et faire valider les compromis éventuels. L’architecte système est responsable d’arbitrer et doit s’assurer
de la convergence mais ce n’est pas forcément lui qui fait les choix d’implémentation. Ces activités ne doivent pas être vues comme séquentielles mais doivent être menées en parallèle. Tous les aspects dysfonctionnels doivent être pris en compte.
L’architecte mène une analyse boîte blanche qui lui permet d’identifier les fonctions couvrant les besoins et usages identifiés et priorisés tout en appréhendant les couplages à venir entre les composants. Il commence par mener une réflexion autant que possible indépendante de la technologie utilisée au niveau des composants puis il pilote les choix d’implémentation. Il est garant de la convergence multi-métier sur les nécessaires compromis à trouver.
Parmi les principaux écueils, on notera :
- Empiéter sur les domaines métiers. L’architecte doit être le lien entre les différents métiers et disciplines et doit permettre les trade-off grâce à une vision d’ensemble. La responsabilité technique doit être portée par l’architecte mais cela est parfois compliqué à être accepté par les métiers (ex: les métiers du logiciel qui travaillent à partir de vues dédiées qui prennent le dessus),
- Ne pas réussir à mener à bien les itérations avec les sous-systèmes en phase d’architecture. Ce qui peut générer des surcoûts et des reprises en aval. Cela est souvent par faute de temps (ils voient l’intérêt mais n’ont pas automatisé l’activité dans leur processus) ou par manque de valeur ajoutée visible de leur part (surtout quand les problématiques d’intégration ne sont pas historiques sur ces couches),
- Croire et laisser croire que la mise en place des pratiques d’architecture est une démarche tout ou rien, sans latitude possible sur son implémentation,
- Confondre logique/physique avec logiciel/matériel,
- Voir l’architecte comme le garant de l’architecture fonctionnelle et pas dysfonctionnelle.
Voici quelques bonnes pratiques à prendre en compte :
- Intégrer les pratiques d’architecture étape par étape et monter progressivement en ambition. Faire un premier projet en mode POC et ensuite généraliser.
- Organiser les niveaux d’abstraction des diagrammes en respectant la règle des 7x7x7.
- Adapter ses pratiques à la complexité du produit et à la maturité de l’entreprise. Il faut toujours garder en tête que la mise en place de l’architecture doit créer de la valeur.
- Prendre en compte à la fois la dimension statique et temporelle de l’architecture.
- Démontrer la valeur strate par strate. On commence par faire monter en maturité le niveau système avant de s’attaquer au niveau sous-système et ainsi de suite. Démontrer la valeur par l’exemple aux strates du dessous est un facilitateur et met en avant plus tôt les changements nécessaires.
- Mapper les activités d’architecture sur les livrables afin de donner le lien entre activités et livrables multi-métier.
- Pratiquer l’écoute active via l’organisation régulière (fréquence à adapter au contexte) de réunions multi métiers d’échange autour des architectures. Les livrables d’architecture pouvant être utilisés comme support de discussion et de compte rendu de réunion. Cela peut également être fait de manière informelle.
- Si le mot fonction est employé il doit être associé à l’adjectif “interne” ou “externe” afin de bien clarifier de quoi on parle.
- Il faut analyser les variantes dysfonctionnelles des cas d’usage.
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 ensemble de revues systèmes qui clarifient les niveaux de maturité des architectures attendus aux jalons et articulent le travail entre système et sous-systèmes. L’architecte participe également aux revues des sous-systèmes (qui doivent prendre en compte les exigences système).
“Nous avons instauré des rituels de travail de 2 ou 3h hebdomadaires pour partager les travaux d’architecture entre les strates et faciliter la convergence multi métier.
“Les équipes logicielles se sont d’abord senties perturbées et inquiétées par la mise en place d’une architecture fonctionnelle. Nous les avons intégrés plus tôt dans la définition des fonctions “boites blanche” pour qu’ils se sentent plus à l’aise et moins en danger.
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.