On continue notre série d’articles sur le DAT. Si ce n’est pas encore fait, n'hésitez pas à aller consulter le premier article.

Dans cet article, nous allons rentrer un peu plus dans le détail de la construction, du maintien, et de la validation d’un DAT.

Précédemment, nous avons vu que le DAT est constitué de plusieurs documents.

Tous ces documents sont interconnectés et partagent le même socle d’information. Ainsi, on peut illustrer le DAT comme une pyramide dans laquelle la formalisation de la couche suivante dépend de la précédente.

Lorsque l’on veut rédiger un DAT, il est judicieux de commencer par le schéma applicatif d’où les autres documents vont découler :

• La cartographie des flux est la conséquence immédiate des flux représentés sur le schéma
• Le tableau des matériels et le schéma technique décrivent l’infrastructure technique sur laquelle repose l’application ou le service et qui porte les modules applicatifs renseignés sur le schéma

Un DAT de qualité : enjeux sur la consistance des informations décrites

Formalisation initiale et maintenance du DAT

L’éclatement de la donnée dans plusieurs documents avec différents formats  représente un risque majeur d’erreur, que ce soit à la création ou lors des mises à jour du DAT. En effet, on peut faire une modification dans un document en omettant de faire la modification associée dans un autre, créant ainsi une erreur ou une incohérence. Ces erreurs peuvent se multiplier au cours du temps pour à terme mener à un DAT ayant un décalage important avec l’implémentation réelle de l’environnement décrit. A cela s’ajoute le turnover des architectes et d’autres acteurs projets pouvant amener à une perte d’historique et de connaissance, augmentant naturellement le risque d’erreurs.

Voici 2 exemples typiques pour mieux comprendre cette problématique :

• Un même flux n’a pas le même protocole entre le schéma applicatif et la cartographie. Admettons que le flux I2 soit décrit en HTTP sur le schéma applicatif et en HTTPS dans la cartographie des flux.
• L’inventaire matériel n’est pas cohérent entre le tableau des matériels et le schéma technique, avec des machines présentes sur le schéma et absente du tableau.

Dans les 2 cas, comment savoir où est l’erreur ? Les informations étant partagées au travers des différents documents, nous ne sommes pas capables de prime abord d’identifier l’erreur racine. Il faut pour cela se plonger dans l’historique des modifications et éventuellement faire appel à des sachants connaissant précisément l’implémentation de l’application. Il va sans dire que cela peut représenter beaucoup de temps perdu à investiguer sur des configurations de serveurs, des firewalls, des anciennes versions de DAT, etc.

Standardisation du DAT

N’oublions pas que le DAT, en plus d’être un document technique, est un support de communication qui peut être lu par différents acteurs ayant des attendus différents. Les équipes réseaux vont surtout s’intéresser à la cartographie des flux, les équipes de déploiement au tableau des matériels, les métiers au document de synthèse, les équipes de sécurité à l’ensemble du DAT, etc.

Avoir une homogénéité dans tous les DAT est donc primordial pour en faciliter la lecture, permettre à chacun de savoir où trouver l’information qui l’intéresse et éviter toute incompréhension. C’est pour cela qu’il est recommandé d’utiliser un template avec les données structurantes pré-remplies pour chaque document : par exemple, la cartographie des flux contient la liste des zones réseaux. Ce template est simple pour les documents type Excel (cartographie des flux, tableau des matériels), les fichiers type Word (document de synthèse). En revanche, pour ce qui est des schémas, l’homogénéité est plus difficile à obtenir avec les outils du marché (type Visio, Drawio, etc.) et dépend beaucoup de la rigueur de l’architecte.

Aussi, un SI évolue en permanence, avec par exemple la création de nouvelles zones réseaux, la disparition de certaines, des décommissionnements de services d’infrastructure consommés par les applications, etc. Le template du DAT doit donc évoluer en conséquence afin de permettre aux architectes une documentation parfaitement adaptée à la situation du SI.

Cycle de validation d’un DAT

Le DAT dispose d’un processus de validation spécifique via un Comité d’Architecture. Il s’agit d’une instance collégiale ayant pour rôle de valider les DAT : soit la publication d’un nouveau DAT pour une nouvelle application, soit pour valider une mise à jour de DAT dans le cadre d’une évolution d’architecture. En effet, il faut préciser que tout nouveau DAT ou toute mise à jour de DAT est associée à une Mise En Production (MEP). Cette MEP peut être simple (par exemple une ouverture d’un nouveau flux ou l’approvisionnement d’un serveur) ou complexe (par exemple l’installation complète de l’application si le DAT est nouveau).

Le passage en Comité d’Architecture nécessite au préalable une relecture par des pairs et/ou des experts qui vont faire des retours sur le DAT (des remarques et/ou des réserves). Le comité donne ensuite son accord final (ou non), donnant ainsi le droit au projet de réaliser sa MEP.

Un élément primordial concernant ce processus de validation est qu’il doit être circonstancié au type de validation, à savoir qu’on ne traite pas de la même manière une validation mineure (par exemple l’ajout d’un flux) et une validation majeure (changement de zones réseaux, ajout de modules applicatifs, ajout de 100 flux). Cette souplesse est indispensable pour que cette étape de relecture et validation ne soit pas perçue par les projets comme une contrainte. Sans cela, les projets pourraient trouver des parades et faire des évolutions d’architecture sans faire évoluer et valider leur documentation, ce qui impacte la maîtrise du SI.

Afin de mettre en perspective les éléments partagés ci-dessus, reprenons l’exemple de l’application Zebra décrite dans le premier article :

Imaginons que dans le cadre de la relecture, l’expert sécurité ait émis la réserve suivante :

• Toute connexion depuis l’externe nécessite le passage par un dispositif de filtrage applicatif.

Le projet et l’architecte ont donc revu leur architecture et proposé le schéma suivant qui a été accepté par la sécurité :

Cette étape de relecture permet donc de parfaire l’architecture et d’éviter les pratiques qui ne sont pas en accord avec les standards (sécurité, infrastructure, etc.).

L’architecte, bien que maîtrisant son sujet, peut parfois commettre des erreurs ou avoir des oublis ! C’est pour cela qu’autant de personnes sont impliquées dans l’élaboration du DAT, de sa rédaction à sa validation. Le DAT est un travail d’équipe !

Un résumé des notions importantes vues jusqu’ici :

• Le DAT peut être comparé aux plans d’un édifice et donne les informations techniques et fonctionnelles relatives à une application (ou un service d’infrastructure)
• Un DAT se compose d’un corpus documentaire dont chaque document a une fonction précise et qui sont tous interconnectés entre eux via des informations communes
• Un DAT est sujet à erreurs et incohérences auxquelles il faut être vigilant. Etablir des standards d'édition ainsi que des processus de revue et validation est donc primordial
• Le DAT est un support de communication destiné à plusieurs corps de métiers et qui doit être compris par tous

PS : Nous avons créé l'outil Uncia pour apporter une réponse simple à tous ces écueils. Allez visiter notre page et faites-nous signe pour plus d'information !

https://uncia.io

https://www.linkedin.com/company/unciaio/

‍