Une fois l’objectif fonctionnel compris et décrit, il est temps de regarder comment applicativement le système répond aux besoins. Ici, on va plutôt adresser nos questions aux développeurs et aux experts des différents middleware (j’y reviendrai).
On s’attache ici à comprendre comment les différents éléments capturés dans l’analyse fonctionnelle vont s’instancier :
A quel(s) flux technique(s) correspond un flux métier ?
Dans quelle base sera stockée la donnée ?
Quel serveur d’application porte le traitement identifié ?
C’est aussi l’occasion de faire apparaître des briques supplémentaires permettant de répondre aux contraintes DICT (pour rappel : Disponibilité, Intégrité, Confidentialité et Traçabilité) dont je vous parlais dans le premier chapitre de ce cours. Par exemple pour sécuriser un accès depuis le web, on peut utiliser un WAF (Web Application Firewall), composant applicatif permettant de vérifier dynamiquement les URL.
Ces éléments de sécurité et les zones réseaux traversées apportent beaucoup de valeur aux schémas applicatifs en permettant d’identifier rapidement les contraintes.
Identifiez les flux
En s’appuyant sur l’analyse fonctionnelle réalisée autour des interfaces, c’est l’occasion ici de zoomer sur les aspects plus techniques :
Le protocole réseau—UDP, TCP, SMB, le port utilisé… ;
Le sens de l’initialisation du flux ;
La volumétrie transmise, globale et unitaire ;
La fréquence des envois ;
Le temps qui vous est imposé entre la réception du flux et la restitution du résultat ;
Les zones réseau traversées.
Le sens d’initialisation quant à lui permet de comprendre quels pare-feux ouvrir, et si l’architecture décrite respecte les contraintes de sécurité de l’entreprise.
Prenons un exemple
C’est le bon moment pour prendre un exemple :) Prenez un besoin classique : transférer une facture entre le logiciel de comptabilité dans votre datacenter et un fournisseur accessible via internet.
Fonctionnellement, la donnée va toujours dans le même sens : depuis chez vous vers le fournisseur.
Applicativement, les choses peuvent être un peu plus complexes :
Le fournisseur peut mettre à disposition un site internet permettant de charger votre facture sur sa plateforme. Auquel cas le flux sera de type HTTP, port 80, avec un sens d’initialisation depuis votre datacenter vers son site (flux sortant, donc).
Vous pouvez aussi mettre en place un dépôt FTP où le fournisseur viendra chercher ses factures. Auquel cas, même si la donnée est toujours déplacée dans le même sens, c’est lui qui établit un flux FTP, port 21, avec pour sens d’initialisation fournisseur vers chez vous (flux entrant).
On ne va pas du tout prendre les mêmes précautions dans un cas où on sort de chez nous et dans un cas où on laisse quelqu’un entrer (comme dans votre maison ! ). En l'espèce, dans le cas d’un flux entrant en provenance d’internet, les bonnes pratiques de sécurité imposent en général un double filtrage protocolaire et un rebond applicatif avant de permettre d’accéder à des ressources du datacenter. C’est le concept de Bastion qui mériterait un cours dédié.
Identifier les zones de sécurité
En reprenant le concept de Bastion et de DMZ, il est vital en décrivant les flux d’identifier les différentes zones de sécurité traversées. Selon la politique de sécurité de votre entreprise, certains flux seront possibles et d’autres tout simplement pas.
Heuuu mais comment on fait pour savoir ?
Excellente question !
Je l’avais mis en avant dans la première partie, c’est précisément l’expérience qui permettra à un architecte de progresser et d’identifier en un coup d’oeil l’ensemble des contraintes portant sur l’ensemble des briques composant une architecture.
Certaines propriétés des protocoles vont permettre de répondre aux contraintes de services. Par exemple, la confidentialité des données peut être garantie en partie à travers le chiffrement des flux, via https pour prendre un grand classique.
En effet, ce protocole implémente la couche SSL, qui permet de s’assurer raisonnablement que les divers relais du flux (switchs, firewall, mais aussi serveurs web, caches) ne peuvent pas prendre connaissance du contenu de ce qui passe. C’est particulièrement intéressant quand des identifiants et mots de passe sont transférés, par exemple.
Mais c’est évident non ?
Si seulement… C’est mon quotidien d’architecte de lutter contre une mauvaise compréhension de l’agilité, qui confond vitesse et précipitation. Et de devoir mettre en avant les besoins pour s’assurer qu’on y répond de manière complète et systématique. La méthode, c’est tout le temps !
Un dernier aspect au sujet des flux concerne la partie performance et capacité : en évaluant au mieux les contraintes de volumes et de fréquence, il est possible d’estimer le débit et la latence nécessaires. Cela permet, de placer correctement les différentes briques (en rapprochant les composants des utilisateurs par exemple) et, dans la couche physique, de dimensionner correctement les infrastructures sous-jacentes
Les gisements de données
Comme pour les flux, on s’appuie ici sur l’analyse faite au niveau fonctionnel, et plus précisément à décrire l’aspect gisement :
Quelles sont les données à garder—Faut-il en filtrer une partie ?
Dans quel format ?—Fichier ? Base de données SQL ? NoSQL ?
Pendant combien de temps ?—et quelle sera la politique de purge ?
Qui devra y accéder et comment ?
Vous vous sentez peut-être circonspect par rapport à l’ensemble de ces questions, et comme beaucoup de mes interlocuteurs, vous pensez peut-être « à quoi bon, de toute façon on fera ce que l’éditeur ou les développeurs proposent ! ».
D’un côté, je ne peux pas vous donner tort. Il est rare personnellement que je descende à ce niveau de profondeur dans mes analyses, les besoins de 80% des applications étant très standards et couverts par des solutions standards et très répandues.
Mais, comme précisé dans la première partie, appliquer la méthode, c’est tout le temps : au maximum de votre disponibilité, il est pertinent de se poser les bonnes questions et de pousser l’analyse. Cela permet systématiquement de se rendre compte des limites d’une architecture proposée et d’identifier des points d’amélioration. Parfois ce sera mineur (adapter un format ou un protocole) parfois cela changera complètement l’approche (partager par défaut une donnée qui aurait du rester locale, en ayant identifié des consommateurs externes potentiels) voire remettre en cause la solution existante (volumétrie exceptionnelle donc coût prohibitif).
Dans le cas d’une source de données de type non structurée (fichier ou objet), qui ne nécessite pas de Middleware particulier, on pourra simplement le faire apparaître directement avec son type de protocole de partage (SMB, NFS, CIFS, S3, …).
Les Middlewares
La couche applicative est l’endroit où mettre en avant tous les logiciels permettant d’instancier concrètement ses flux, ses données et ses traitements. Je regroupe l’ensemble de ces applications sous le terme générique « middleware » (intergiciel en français).
Concrètement on parle principalement :
Des logiciels permettant les échanges (MoM, EAI, Bus…), comme RabbitMQ, sftpd, WebMethods...
Des bases de données (Oracle, SQL Server, MySQL, MariaDB, MongoDB, Cassandra, Azure SQL DB, DynamoDB, ...)
Des serveurs d’application (MS IIS, Apache Tomcat, JBoss, …)
Des serveurs web (Apache httpd, Nginx…)
Des services de sécurité réseau type WAF, Firewall niveau 4, Load-balancer, proxy, reverse-proxy, VPN…
Des services d’authentification ou de SSO (MS AD, Openstack Keystone)
...
Ces middlewares peuvent être soit déployés dans votre datacenter ou directement souscrits en tant que service sur le Cloud, sous forme de PaaS (Platform as a Service).
La version d’un middleware est un élément à capturer impérativement. Souvent, les développements et surtout les progiciels sont dépendants de telle ou telle version, ce qui rend les évolutions potentiellement complexes. En identifiant dès le départ ces dépendances, on permet de mettre en avant la dette technique (c’est le coût qu’on est sûr de devoir financer dès lors qu’on a implémenté un composant, ne serait-ce que pour le retirer) et on facilite le travail des futurs architectes qui auront à travailler sur la solution.
Mais… ces versions évoluent, non ?
Bien sûr ! Et ce sera l’occasion de revenir sur l’analyse, en mettant à jour les schémas et surtout en se reposant certaines questions clés : est-ce que je profite des nouvelles fonctionnalités apportées pour mieux répondre à mes besoins fonctionnels ? Est-ce que la technologie sur laquelle j’ai investi reste la meilleure option par rapport à mon cas d’usage ? Est-ce que le cycle de vie de l’application, voire sa fin de vie programmée, justifient l’investissement humain et financier d’une montée de version des middlewares ?
L’analyse de la couche applicative est aussi l’occasion de mettre en avant différents mécanismes offerts par les middlewares : réplication de données, partage de sessions, clustering, chiffrement des données... qu’il peut être pertinent de faire apparaître afin d’expliciter comment l’architecture présentée répond aux contraintes de services. En général, ce sont les mécanismes de la couche applicative, de la couche opérationnelle ET de la couche technique qui vont permettre d’y répondre.
