Maintenant que vous connaissez un peu mieux le métier et l’architecture, focalisonsnous sur un aspect majeur : la représentation. En effet, vous remarquerez vite que dessiner oblige à se poser des questions auxquelles on n’aurait pas nécessairement pensé, et sert d’excellente base pour échanger et porter la vision.
Pourquoi dessiner mon architecture ?
Mais c'est évident qu'il faut faire un schéma de notre architecture, non ?
Oui, mais… c’est finalement assez rare de trouver ne serait-ce qu’un schéma à jour représentant un système d’information ! o_O C’est lié à l’habitude de positionner l’architecture uniquement en début de projet (on y reviendra), ce qui fait que, quand un système évolue, sa représentation, portée par l’architecte, ne suit pas. On connaît aussi les projets en mode Agile qui « oublient » la conception à chaque sprint, sans parler des visions contradictoires des différents membres de l’équipe !
La documentation, souvent perçue comme une corvée, est pourtant essentielle à la communication et à la pérennité d’un système. Dans l’industrie informatique, les postes évoluent vite et la connaissance orale détenue seulement par quelques personnes est un vrai danger. On appelle ça en anglais le Bus Factor qui mesure, de façon très prosaïque, l’impact qu’aurait la disparition d’un collaborateur clé qui serait percuté par un bus !
Comment représenter une architecture ?
Le premier réflexe que vous devez avoir quand vous voulez décrire une architecture est de vous appuyer sur ce qui a déjà été produit : y a-t-il une représentation normée dans l’entreprise au niveau des icônes ? De l’outillage ? Des codes couleur ? Personnellement, j’utilise en général Microsoft Visio pour mes schémas et Microsoft Powerpoint pour les descriptions et les échanges. Les outils potentiels sont nombreux mais l'essentiel est de définir un référentiel commun et de l'utiliser !
Un écueil classique est de démarrer sur son logiciel et de commencer à placer les éléments. Je vous conseille au contraire de démarrer sur papier, où vous ne serez pas gêné par les contraintes dues aux outils. Une fois une représentation claire dessinée, on peut passer à la phase logicielle pour la rendre jolie et évolutive.
Afin de se lancer sur une bonne piste, il est bon de toujours se poser la question : « Qu’est-ce que je souhaite montrer à travers ce schéma ? » Est-ce que ce sont les contraintes de flux ? Les capacités de reprise ? Les emplacements en datacenter ? On ne pourra jamais tout représenter sur un même support, il faut donc faire des choix structurants en amont tout en gardant à l’esprit de privilégier la simplicité.
Que représenter ?
Ma recommandation pour aborder une architecture est de la découper en sous-ensembles cohérents et complémentaires. C’est la démarche classique de l’ingénieur : on découpe un ensemble complexe en parties plus simples et maîtrisables.
Par défaut, un système d’information vu sous l’angle de l’architecture technique peut se décomposer en 4 plans :
Le plan fonctionnel, représente l’aspect métier, c’est à dire ce que fait l’application et la nature des données qu’elle échange avec le reste du monde ;
Le plan applicatif est concentré sur l’aspect logiciel : les flux (protocole, fréquence, sens), les stocks (partage de donnée...), les middlewares (base de données, serveur java…) et les frameworks utilisés (.NET, Java...) ;
Le plan infrastructure permet de décrire les choix techniques: les serveurs (dans le cloud ou ailleurs), leur dimensionnement, l’interconnexion via les réseaux, etc ;
La couche opérationnelle enfin, décrit comment le système va être géré : les mécanismes de sauvegarde, de supervision, de métrologie, etc.
En résumé
Dans ce chapitre, nous avons vu ensemble l’importance de la représentation. Dès que vous abordez un sujet, ayez le réflexe de dégainer votre stylo, stylet, feutre ou tablette et commencez à dessiner, même mal :) Vous constaterez vite l’immense valeur ajoutée de partager autour d’un schéma simple et concret !
On abordera dans le détail chacune de ces couches ainsi qu’une méthode pour les représenter lors de la prochaine partie.
