L’architecte SI comme son homologue dans le monde physique de la construction doit produire des plans. Je n’irais pas jusqu’à dire qu’il doit passer tout son temps à cela (il faut se laisser un peu de temps pour de la veille, monter des prototypes, discuter avec d’autres architectes) mais une bonne partie de sa charge de travail doit tourner autour de ces schémas d’architecture.

Et quitte à y passer du temps autant que ce soit le plus efficace possible.

Le schéma peut-être une fin en soi d’ailleurs une fin qui a plusieurs niveaux de finition, il doit permettre

• de communiquer sur le fonctionnement, l’intérêt de la solution décrite. Pour cela il doit donc être
  • accessible sans une formation particulière, d’où l’intérêt d’un formalisme léger et relativement intuitif
  • homogène dans l’entreprise concernée pour éviter de se réinterroger sur la signification de chaque composant à chaque solution abordée
• de capitaliser les informations pertinentes de manière synthétique.

Etablir un schéma peut faire peur. Pourquoi ? Mon hypothèse est qu’il est beaucoup plus difficile de tricher lorsqu’on réalise un schéma que quand rédige un texte : dans ce dernier cas, on peut utiliser le conditionnel, adopter des tournures de phrase un peu floue, recourir à des termes ambiguës. Sur un schéma, c’est plus difficile : vos flèches doivent bien partir de quelque part et arriver à un autre endroit, vos boites doivent bien avoir un nom ! Bien sûr, il reste toujours possible de contourner les difficultés en nommant les objets de manière vague en adoptant des vues tellement haut-niveau qu’on ne distingue plus le sol mais on s’aperçoit alors vite que le roi est nu.

Théoriquement n’importe quel outil de dessin peut être employé pour réaliser des schémas (même PowerPoint mais je ne le souhaite à personne) mais c’est oublié qu’au-delà du schéma il y a le modèle. C’est aussi oublier le fait que si vous faites construire votre maison et que l’architecte vous présente des plans sous PowerPoint ou Paint, vous éprouveriez sans doute une légitime appréhension.

Le schéma est un visuel, le modèle est une base de données contenant des concepts liés entre eux.

Le modèle est la bibliothèque de concepts que vous trouverez sous Archi dans la fenêtre nommée de manière très pertinente… »Models ». Le schéma (ou la vue) est ce que vous trouvez dans la fenêtre principale.

Une vue peut-être considérée comme une projection selon un axe particulier du modèle. Les objets apparaissant dans la vue sont des instanciations des concepts présents dans le modèle.

C’est de la constitution de ce modèle que va découler la vraie plus-value de la méo et une justification majeure du travail rigoureux, constant, exhaustif de réalisation de ces schémas.

Le respect d’un formalisme/langage de modélisation est aussi un exercice qui oblige à se poser des questions sur la nature des concepts représentés et de leurs relations. C’est tout à fait différent d’un schéma « libre » rapidement ébauché sur PowerPoint où l’on choisit des formes/couleurs/flèches au gré des envies : on obtient ainsi (parfois) quelque chose qui peut-être visuellement satisfaisant mais dont la durée de vie est limitée et qu’on ne pourra jamais réellement exploiter.

Un modèle se doit de

• respecter le principe DRY (Do not Repeat Yourself), une information n’est saisie qu’une fois peut importe le nombre de fois où elle est employée.
• être dynamique, lorsqu’un concept est modifié, la mise à jour se répercute immédiatement à tous les schémas où il est utilisé.
• être lisible algorithmiquement, il est possible de l’analyser, de le parcourir pour en extraire de l’information, de ou pour reformater cette information, de le vérifier

Et en contrepartie d’un peu de rigueur, ce modèle va rendre possible :

• la réutilisation les concepts précédemment modélisés, en ce sens il est un catalogue de l’existant.
• l’accélération de la réalisation et l’homogénéisation de nouveaux schémas
• l’analyse, le requêtage des concepts
• une mise à jour rapide et surtout fiable des informations : plus besoin de chercher pendant des heures des documents épars pour des pénibles modifications à la main.

Le contenu du modèle se détermine au cas par cas en fonction du contexte et des usages.

A titre personnel, parce que j’apprécie les options tranchées, j’ai l’habitude de dire que le modèle doit contenir tout ce qui concerne directement l’architecte et que s’il n’arrive pas à le modéliser c’est probablement que ce n’est pas de l’architecture (ce qui ne veut pas dire que cela n’est pas pertinent bien entendu).

Mais attention à ne pas aller vers de la sur-modélisation : à chaque fois que vous ajoutez un concept ou une relation avec un concept, soyez fainéant : estimez si on pourrait un jour vous posez une question qui nécessiterait de requêter votre modèle pour y répondre.

Si oui continuez, si non cette information peut sans doute trouver sa place ailleurs, éventuellement dans la documentation du schéma ou du concept.

Exemple : en mon âme et conscience, j’ai considéré qu’on pourrait me demander le nombre d’utilisateurs potentiels d’une application mais aucunement le nombre d’utilisateurs simultanés. Je vais donc incorporer cette information du nombre potentiels d’utilisateurs à mon modèle (par un nombre sur la relation entre l’application et l’utilisateur 30 et 500 ici puis je note cette pratique dans un document qui référence tout ce qui est modélisé afin que tous les architectes de l’entreprise modélisent cette notion de la même façon) mais je ne modéliser pas le nombre d’utilisateurs simultanés

Idem, dans un certain contexte, les problématiques de performance sont inexistantes (ce qui ne veut pas dire que les performances sont bonnes mais simplement que lorsqu’elles sont mauvaises on passe cela sous silence), aucune exigence sur ces aspects n’est donc modélisée.

La seule limite est votre capacité à transformer en concept Archimate toutes les notions que vous avez à documenter. Un formalisme comme Archimate permet aisément, sans même avoir à le tordre/détourner, de représenter les exigences non-fonctionnelles, les grandes étapes de la vie d’une application, les besoins en terme d’exploitation, etc…Bref toutes les parties qui constituent un dossier d’architecture.C’est un peu dur au début mais je peux vous certifier qu’une fois qu’on a pris le pli, il est intellectuellement hyper-satisfaisant de ne plus rédiger un dossier d’architecture à l’ancienne en bataillant avec Word.

Je reconnais que c’est une position extrême qui rencontre beaucoup de résistance quand je la propose, tant l’habitude du papier et de sa contrepartie électronique -le document word- est ancrée dans nos méthodes de travail.

Mais n’oubliez pas que la puissance d’un modèle est de pouvoir ensuite être traitée algorithmiquement : vous avez besoin d’un document word/PDF ? Développer un rapport qui traite les informations de votre modèle et vous permette de produire un tel document : ce dernier sera parfait pour les besoins de traçabilité, pour « snapshoter » une version particulière de la documentation d’une solution ou pour des exigences réglementaires.

---