Dans ce blog, je présente ce travail sur le DAT ou Dossier d’architecture technique d’un point de vue d’un architecte réseau et services (sécurité, qualité de service, gestion d’infrastructure). Le lien vers le travail complet est: D.A.T(er) comme un professionnel, un Architecte…
Le DAT…
Le dossier d’architecture technique ou DAT s’inscrit en amont dans le processus de la définition et réalisation d’une solution technique en réponse à une demande, à un besoin. Il définit naturellement la demande émanant d’un demandeur que nous appellerons « client », et la réponse qu’en fait « l’architecte » en termes choisis dans le domaine concerné, informatique ou autre. Il est nécessaire aussi, de distinguer le travail du DAT, qui est plus une démarche, et l’aspect lié à sa rédaction qui n’est pas moindre puisqu’il constitue un livrable, une réalisation, un produit, un objet de travail, etc.
Il se constitue en quelque sorte comme un « contrat », entre le client et l’architecte, qui s’articule, par écrit, en plusieurs parties dont la logique est accessible au client, défendable par l’architecte et exploitable par « l’exploitant », l’entité qui aurait pour rôle de déployer la solution technique et son exploitation.
D’un autre point de vue, en plus qu’il représente un contrat qui fige le besoin du MOE et engage la responsabilité de réalisation du MOA, le DAT peut être vu comme un objet intermédiaire de travail. Il est intermédiaire dans le sens où il ne constitue pas en soi la réponse au besoin mais une étape (réalisée, concrète) dans la réalisation du besoin, de sa réponse finale. C’est un objet de travail que nous pourrions assimiler au jeu de maquette que réalise l’architecte (urbain) pour démontrer le concept à son client, avant la réalisation effective des bâtiments…
Client, Exploitant, Architecte…
Si les termes « client », « architecte » ou « exploitant » peuvent se référer à des entités bien particulières, physiques ou morales, rien n’empêche de les considérer comme des entités logiques, de différents rôles ou d’approches dans la réalisation d’un objet qui répond à un besoin concret. . .
Ce travail vise à présenter ces différents rôles dans leurs contextes de développement (de discours ou logique) et d’interaction dans un travail collaboratif qui aurait pour produit le DAT ou tout autre objet (intermédiaire).
Cette liste s’agrandit avec le contexte et la complexité du projet et la tâche à réaliser. Rien n’empêche d’envisager d’autres rôles : chef de projet, manager IT, ergonome, MOE, etc. le seul enjeu est de permettre de voir clairement une logique (ou discours) cohérent dans le traitement du besoin, de la demande, etc. qui est en plus, idéalement, en résonance avec d’autres discours ou logiques sans les remettre en cause mais en recherche d’un terrain d’entente ou compromis qui donne sur un nouveau niveau d’abstraction, de transformation et qui réunit différentes sensibilités au lieu de les confronter et casser toute créativité.
L’exemple de travail dans ce livre : Le wifi d’entreprise
Dans ce livre, nous nous situerons dans le domaine riche de l’informatique et surtout, ce qui de ce domaine, touche à l’infrastructure : les réseaux télécoms, réseaux informatiques, systèmes informatiques d’infrastructure, sécurité réseau et systèmes, etc.
Dans ce travail, pour permettre à un maximum de lecteurs de s’y retrouver, nous avons choisis de décrire les principes et étapes de conception sur l’exemple d’implémentation d’une solution WIFI. Dès lors, nous pouvons imaginer le « client », dans son contexte : associatif, de PME ou de grande entreprise, qui a un besoin de mobilité informatique, et demande à l’architecte de l’aider à articuler ce besoin techniquement et de répondre par une solution de terrain, fonctionnelle et exploitable en toute autonomie !
Organisation du livre
Les chapitres s’organisent d’une manière à présenter les grandes étapes logiques de réalisation d’un DAT, l’ordre étant dépendant de l’approche choisie : 1) la définition du besoin et la déclinaison de cette définition en critères fonctionnels, logiques et d’éléments physiques de choix des composantes de la solution, 2) la proposition de la solution d’architecture dans une approche Top-Down, à titre d’exemple, du plus général au plus spécifique de l’ingénierie et de l’implémentation, 3) l’établissement de recommandations quant aux exigences du déploiement, de l’intégration et de l’exploitation.
Chaque chapitre est organisé de façon à présenter les faits liés au sujet abordé et au même temps, l’évolution sous forme visuelle de deux éléments : l’architecture de travail (solution wifi d’entreprise) et le schéma du processus général du développement (aspect plus fonctionnel). N’oublions pas le sommaire qui est une ressource importante à la compréhension de ce développement : il est fait de façon à permettre une lecture séquentielle et logiquement logiquement. Il ne faut donc pas hésiter à le lire en totalité et questionner systématiquement la logique de ce développement et cette organisation.
Il y aurait des chapitres plus techniques que d’autres mais qui restent accessibles à un lecteur non familier avec ces concepts. Le but recherché n’étant pas la complexification technique mais de montrer l’ampleur du travail requis. Dans ce cas, il ne faut pas hésiter à passer rapidement ces descriptifs ou analyse technique et rappeler systématiquement que c’est pour indiquer une telle ou telle complexité liée au processus général et plus fonctionnelle ou à l’articulation du besoin sur des aspects plus logiques.
A vos commentaires
C’est avec un grand plaisir que ce travail a été réalisé témoignant d’une passion pour le domaine. Et, c’est une invitation pour vous de partager cette réflexion au travers de vos commentaires!
