Ce sera également une référence de partage et d’échange afin de concrétiser la vision du système.
Quel est le point de départ du DAT ?
Petit quart d’heure histoire avant de commencer :)
J’ai connu de nombreux DAT dans ma carrière en tant qu’architecte. Des documents fleuves de 120 pages, qui n’ont jamais été lus que par leur rédacteur. Des formats expéditifs, mal compris, écrits par défaut pour répondre à des exigences documentaires. Parfois de simples schémas sur papier pris en photo ! Bizarrement, c’est souvent le schéma qui porte le plus de valeur, car il est produit avec un but en particulier, une idée à expliciter.
L’architecture aujourd’hui, dans sa grande majorité, n’a pas besoin de documents fleuves détaillant chaque aspect. On s’appuie sur les experts de chaque partie (système d’exploitation, réseau, sécurité, base de données, Cloud…) pour connaître et mettre en place les bonnes pratiques, apportant ainsi toute leur valeur ajoutée.
Je préfère personnellement un document tactique mettant en avant principalement les points d’attention, les décisions d’architecture, et qui représente les 4 couches décrites dans la deuxième partie.
Quels sont les objectifs du DAT ?
Dans la plupart des entreprises pour lesquelles j’ai eu le plaisir de travailler, le DAT a toujours rempli au moins 5 objectifs majeurs :
Porter la vision de l’architecture cible, c’est à dire décrire explicitement la synthèse de ce que chacune des parties prenantes a en tête, à travers des schémas reprenant les 4 couches.
Documenter les engagements de service : DIMA, PDMA et les autres aspects présentés dans la première partie.
Présenter comment l’architecture cible y répond, en détaillant les mécanismes de disponibilité, de performance, de résilience, de chiffrement, de sauvegarde…
Décrire le travail à réaliser de façon macro et servir de référence pour le chef de projet.
Servir de support de communication afin de présenter efficacement le projet au management, aux autres architectes (on y reviendra) et aux équipes en charge de la réalisation.
Selon les organisations, on y ajoutera des éléments de coûts, calendrier, contrat ou encore une partie historique des décisions. Je vous proposerai dans le prochain chapitre un plan type reprenant tous ces aspects. A vous selon le contexte de privilégier tel ou tel aspect en fonction de votre organisation et de ses contraintes, en gardant à l’esprit de conserver clarté et lisibilité.
En somme, laissez libre cours à votre imagination en fonction de votre contexte et du besoin. L’important est qu’on retrouve les éléments de méthode et quelques impondérables que je vais vous décrire tout de suite après.
