Rentrons maintenant dans le vif du sujet : vous connaissez maintenant la méthode et les objectifs principaux d’un DAT. Il est temps d’appliquer la méthode, afin de constituer le document et démarrer vos premiers travaux d’architecture.
Je vous propose dans ce chapitre de suivre un plan type de DAT, et, pour chaque section, de vous décrire comment mener l’analyse. Vous trouverez un exemple filé tout au long de l'explication.
Le contexte : les besoin fonctionnels
S’il y a une partie dans un DAT à remplir, c’est bien celle-là. Elle correspond en partie à l’analyse fonctionnelle et répond aux questions suivantes :
Que fait le système décrit ?
Quel a été l’historique du projet ?
Quelles sont les attentes principales (nouveau marché pour le métier ? réduction des coûts ?...) ?
Qui sont les principaux acteurs ?
Quelles directions sponsorisent le projet ?
Quelles sont les contraintes métiers qui auront un impact sur l’architecture ?
Un exemple de besoin fonctionnel est : l’application Toto doit permettre à nos clients de commander directement nos produits électroménagers sur Internet plutôt que de passer en magasin.
Les besoins non fonctionnels
On va lister ici les contraintes techniques au sens large : performances, disponibilité, utilisation de langages ou d’infrastructures particulières, nombre d’utilisateurs à la cible, leur localisation, les contraintes de temps, etc.
Vous l’aurez bien compris, l’exhaustivité et surtout le partage de ces besoins non fonctionnels va faire toute la valeur de l’architecture proposée.
La représentation fonctionnelle
Place au dessin ! Si vous vous rappelez la première partie, vous connaissez l’importance de représenter ce que vous avez compris de l’architecture fonctionnelle, au travers d’un ou plusieurs schémas. Avant de démarrer sur votre logiciel préféré, je vous recommande de systématiquement de griffonner sur une feuille de papier et de vous demander : quel message je veux faire passer ? Est-ce de mettre l’accent sur les flux ? Les stocks ? Les blocs fonctionnels de traitement ?
L’approche classique est de suivre le parcours de l’utilisateur et de suivre son cheminement dans le système.
La liste des environnements et le dimensionnement associé
Une fois l’analyse fonctionnelle réalisée, nous allons décliner chacune des architectures applicatives et infrastructure en fonction des environnements, c’est-à-dire des ensembles de briques ayant un usage dédié durant le cycle projet (test, formation, intégration, développement, production…).
C’est dans cette section qu’on va les lister, en donnant quelques-unes de leurs caractéristiques : nom et localisation, liste des services utilisés (cloud, serveur, base de données…), zones réseaux traversées, taille des espaces de stockages alloués, nombre de coeurs, etc.
La représentation applicative
Comme pour l’aspect fonctionnel, il s’agit ici de schématiser les informations obtenues lors de vos entretiens.
Je vous recommande encore une fois de suivre le parcours utilisateur, mais cette fois en faisant apparaître chacune des briques applicatives : serveur web, base de données, reverse proxy, firewall, partage de fichiers, ainsi que les logiciels ou progiciels utilisés.
Il faut ici faire apparaître les flux techniques, avec leur port, leur protocole et bien respecter le sens d’initialisation du flux comme évoqué dans la deuxième partie.
La localisation de chacun des éléments (utilisateurs, services cloud, datacenters…) est primordiale sur ce type de schéma.
Dernier conseil, faites apparaître le nom des infrastructures sous-jacentes utilisées (par exemple, le nom du serveur qui porte la base de données), pour faire le lien avec les schémas d’infrastructure.
La matrice de flux
Extraite de l’analyse applicative, la matrice de flux va permettre de faciliter le travail des équipes sécurité et des chefs de projet.
De façon très classique, la matrice que je vous propose liste les sources, destinations, protocoles et zones réseau pour chacun des flux de votre application.
En général, on va s'intéresser principalement aux échanges nécessitant une approbation ou une ouverture de firewall. Toutefois, je vous recommande de faire également apparaître ici les points d’attention (je sais, je me répète :)) : transferts particulièrement volumineux ou fréquents, sensibilité particulière à la latence ou autres.
La représentation infrastructure
Dans la droite lignée des schémas applicatifs et fonctionnels, la couche infrastructure va permettre de visualiser en un coup d’oeil les ressources utilisées. Je vous recommande de faire apparaître les configurations matérielles (système d’exploitation, processeur, mémoire, stockage, port réseau, …) et les caractéristiques de disponibilité et de résilience mis en oeuvre (réplication stockage, clustering OS,...).
Attention également ici à ne pas vous perdre dans les services communs. A moins que vous utilisiez une infrastructure complètement dédiée pour votre système, vous allez probablement vous appuyer sur des éléments mutualisés (au hasard, le réseau ou le stockage).
Si c’est le cas, n’hésitez pas à renvoyer votre lecteur vers les DAT de ces services en particulier pour les détails, tout en mettant en avant comment vous les utilisez.
Par exemple, un double attachement au réseau ou l’utilisation de service de stockage de sécurisation comme la haute disponibilité des espaces utilisés, à travers des mécanismes de clustering et de replication.
La représentation opérationnelle
Vous avez compris la logique (je l’espère :)), il faut ici montrer comment votre système utilise les différents services d’exploitation. Comme pour la partie infrastructure, la plupart des services d’opération (supervision, métrologie, sauvegarde,...) sont mutualisés.
Par exemple, on mettra en avant un système d’externalisation des sauvegardes permettant de répondre à une exigence réglementaire imposant d’avoir une copie de données hors des murs.
Les offres de services d’opérations
Au delà du schéma opérationnel, il peut être pertinent de préciser à quelles offres de service souscrit votre système :
quelle politique de sauvegarde a été retenue,
quels sont les points de supervision et de métrologie,
quels sont les paramètres de déploiement continus (slots, fenêtres de déploiements, autorisations de certains utilisateurs...)
Les décisions d’architecture
A partir des analyses fonctionnelle, applicative, infrastructure et opérationnelle, vous avez dû faire des choix et privilégier une solution ou une approche.
Voici la structure que je vous propose :
L’intitulé de la décision
Son contexte (pourquoi il y a une décision à prendre)
Les alternatives considérées
La justification pour expliquer la décision et/ou le choix
Plan projet
L’architecte, par sa compréhension transverse de l’ensemble des enjeux techniques, est le mieux placé pour proposer un premier plan projet, qui servira de base au chef de projet pour le compléter avec chacun des experts en charge de la réalisation.
Ce plan va permettre de lister chacune des tâches à réaliser et surtout quelle équipe en aura la charge. Je vous recommande la méthode RACI pour préciser les contributions et responsabilités de chacun. Vous pouvez trouver des détails sur cette méthode dans cette section de cours.
Le calendrier de réalisation
A partir du plan projet, sans aller très profond dans le détail, nous pouvons préciser quelles tâches sont réalisables en parallèle, et lesquelles doivent être réalisées en séquence. Si vous en avez une idée, vous pouvez aussi ici indiquer de façon approximative les charges de réalisation par phase.
Les risques
A travers les phases d’analyse, il arrive souvent qu’on puisse identifier certains risques liés à l’architecture mise en place. Par exemple une sensibilité des performances en fonction du nombre d’utilisateurs, ou encore la capacité à réaliser le projet selon la disponibilité d’intervenants critiques.
Le RACI opérations
J’ai déjà évoqué l’importance d’anticiper qui va exploiter les différents composants applicatifs et infrastructure retenus. Selon les contextes, on mettra l’accent sur l’organisation qui traitera, la distinction entre ressources internes et externes ou encore les périmètres infogérés.
Cette partie est primordiale et mérite d’être mise en avant dans le DAT, en suivant la méthode RACI proposée pour le projet.
Les coûts
Dernier aspect et non des moindres. L’aspect coûts, comme la partie calendrier, est essentiel pour faire émerger une architecture.
On va s'intéresser à la fois à ce que coûtera la mise en place et le récurrent lié à l’usage et l’exploitation.
On y reviendra en quatrième et dernière partie, mais la compréhension fine des modèles économiques du Cloud est absolument indispensable pour un architecte aujourd’hui. Il s’agit de faire le choix des bons services, par le bon fournisseur, en prenant en compte toutes les contraintes techniques et économiques.
Un exemple classique est un service qui utilise un cœur en permanence. On ne bénéficiera pas dans ce cadre d’une optimisation des coûts lié au modèle “paiement à l’usage” du Cloud. Ce sera souvent préférable dans ce cadre d’utiliser des machines en datacenter, ou les offres de “réservation de ressources” que proposent les différents fournisseurs.
A travers ce chapitre, vous avez découvert les multiples aspects que peut prendre l’architecture, de l’application stricte de la méthode vue en deuxième partie, jusqu'à la prise en compte des aspects coûts, risques, calendrier et rôles et responsabilités.
