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 (il y a le travail du DAT, qui est plus une démarche, et l’aspect à sa rédaction qui n’est pas moindre puisqu’il constitue un livrable, une réalisation, un produit, etc.) 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 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 de 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) dans la réalisation du besoin de sa réponse finale. C’est un objet de travail que nous pourrons assimiler au jeu de maquette de 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 rôles différents ou d’approches dans la réalisation d’un objet qui répond à un besoin concret. . . ce travail vise à présenter ces différents 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 d’agrandit avec le contexte et la complexité du projet: la tâche à réaliser. Rien n’empêche d’envisager d’autres rôles de: 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 de compromis… d’un niveau d’abstraction, de transformation nouveau 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 en ce qui concerne : les réseaux télécoms, réseaux informatiques, systèmes informatiques d’infrastructure, sécurité réseau et systèmes, etc. ; pour se repérer facilement
dans ce travail et 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 aborder 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, articulée logiquement… il ne faut pas hésiter à le lire en totalité et essayer de questionner la logique de 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 avec le processus générale (plus fonctionnelle) ou d’articulation du besoin (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!
