Sur base des éléments collectés auprès des différentes parties prenantes, l’architecte formalise des modèles logiques du système, organisés selon un cadre d’architecture système. Il est le garant du respect de la syntaxe – plus ou moins formelle – donnée par le langage de modélisation choisi et des activités de modélisations à effectuer. La signification précise de chaque composant d’un modèle systémique doit avoir été définie de manière explicite et non ambigüe.
Les travaux de l’architecte reposent sur la construction de modèles qui permettent de produire (de manière automatisée dans une vision idéale) une documentation d’architecture système exhaustive, cohérente et non ambiguë.
Parmi les principaux écueils, on notera :
- Voir les modèles uniquement comme des outils de communication et d’alignement et ne pas baser ses décisions d’architecture sur l’exploitation des modèles,
- Ne pas mettre en place de liens de traçabilité entre les modèles,
- Ne pas expliciter les liens entre modèles d’ingénierie et modèles d’architecture,
- Ne pas assez se focaliser sur la forme : un diagramme illisible n’est pas communicable et est donc difficilement exploitable,
- Ne pas se servir des modèles pour mettre en avant les chaînes de valeur et les communiquer auprès des parties prenantes.
Voici quelques bonnes pratiques à prendre en compte :
- Procéder par étape dans la mise en place d’une ingénierie tirée par les modèles : d’abord on formalise, puis on partage les modèles, on construit des architectures, on ré-utilise des architectures, on s’en sert pour de la simulation, puis pour spécifier etc,
- Mettre en place un plan d’architecture par projet qui instancie la boîte à outil et le niveau de profondeur attendu pour chaque case (il faut cependant donner des critères par exemple, modéliser la nouveauté),
- Attacher l’aspect risque et valeur sur les modèles afin d’en avoir une vue globale partagée et se servir des modèles pour mettre en avant les périmètres sur lesquels il faut travailler (particulièrement pertinent dans une entreprise avec un fort historique),
- Avoir une démarche de modélisation de bout en bout – du développement aux tests (ex : formaliser des scenarios avec une optique test (traçabilité)), tout en tenant compte du temps alloué,
- Communicate by always using the same models (so as not to lose people) and adapt the level of detail to the audience (so you need several levels for each model),
- Ne pas hésiter à ajouter des images ou autre pour rendre la modélisation plus facile à comprendre et mieux communicable,
- Voir un objectif clair par modèle et un seul message par diagramme : on doit savoir pourquoi on fait de la modélisation. Ne pas hésiter à créer un second diagramme si on doit passer un second message ,
- L’information doit être accessible sans que les outils soient un frein,
- Il faut bien penser au cycle de vie des modèles créés et en particulier bien définir la manière de les gérer en configuration,
- Jeter les diagrammes quand ils ne sont plus utiles (arrêter de les maintenir).
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 utilisons nos modèles d’architecture pour valider des analyses safety,
“ Nous avons mis en place un modèle 150% qui est instancié par projet en fonction du contexte et des objectifs à atteindre,
“ Nos outils de modélisation : Visio, Draw IO, Enterprise Architect, Capella, Rhapsody, Tom Sawyer (“simple” mise en page automatique à partir de connexion à d’autres outils).
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.