Maintenant que vous avez une idée du métier de l’architecte, prenons un peu de temps ensemble pour comprendre ce qu’est une « bonne » architecture, c’est-à-dire les caractéristiques principales auxquelles elle doit répondre : la sécurité (au sens large), l'élasticité, le couplage faible et surtout : la simplicité.
La sécurité
C’est l’une des premières questions à poser et à se poser : Comment sécuriser mon application, mon infrastructure ?
Mais c’est quoi la sécurité ?
Vaste question aux réponses multiples, mais dans notre cas, appuyons nous sur l’acronyme DICT : Disponibilité, Intégrité, Confidentialité, Traçabilité en y ajoutant la PDMA, acronyme barbare indiquant la Perte de Données Maximum Admissible (RPO en anglais).
Détaillons alors ce qu'implique chacun des termes de la DICT, puis la PDMA.
Disponibilité
C’est le reflet de la capacité d’une application à être résiliente (pensez à résistante) à tout événement pouvant générer un arrêt de service.
Elle doit répondre aux exigences exprimées par le demandeur : combien de temps peut-on s’arrêter en cas de sinistre mineur (l’arrêt d’une machine par exemple) ou de sinistre majeur (une météorite s’écrasant sur un datacenter ou encore une inondation) ?
Ce double besoin est souvent exprimé sous forme de DIMA ou Durée d’Interruption Maximum Admissible (RTO en anglais) en heures ou encore sous la forme d’un objectif de service (SLO en anglais) en pourcentage du type 99,999% du temps soit 5,26 minutes d’interruption par an.
Intégrité
Comme son nom l’indique, il s’agit de s’assurer qu’une donnée n’est pas modifiée indûment, encore une fois le plus souvent dans un cadre sensible ou légal. Pour reprendre notre exemple précédent, vous pourrez vous assurer que notre recette n’a pas pu être modifiée par quelqu’un d’autre que le chef cuisinier.
Confidentialité
Vous trouverez dans la plupart des entreprises une classification de la sensibilité de leurs données, en fonction de l’impact de leur publication. On peut distinguer deux types de données confidentielles : celles très sensibles qui touchent au métier de l’entreprise et dégraderaient sa capacité à continuer son activité en cas de fuite ou de corruption et celles, réglementaires, qui légalement doivent être protégées, gardées secrètes ou supprimées (on pense à la RGPD, notamment).
Par exemple la recette du célèbre gâteau à la fraise qui fait la réputation d’un restaurant ou, côté légal, les dossiers du personnel.
Traçabilité
C’est la capacité à garder une preuve de l’accès ou de la modification d’une donnée, dans le temps. Cette notion est particulièrement pertinente pour les données réglementées ou celles, souvent confidentielles, qui ne doivent être consultées que par peu de personnes.
Dans notre restaurant, vous pourrez ainsi vérifier que seuls les cuisiniers ont pu consulter la recette, et pas les serveurs, mêmes s’ils peuvent accéder à la cuisine.
PDMA – La Perte de Données Maximale Admissible
Sous ce nom barbare se cache le dernier pan de la sécurité dans l’architecture, c’est l’existence même de la donnée qu’il faut pouvoir assurer. En effet, les cas de corruption et surtout de suppression accidentelle sont assez courants et nécessitent d’être envisagés en amont lors de la conception d’un système.
Afin de mitiger ces risques, on s’appuie en général sur des mécanismes de réplication, de sauvegarde et d’externalisation des données. A noter, seule la politique de sauvegarde permet d’assurer réellement une PDMA.
L’élasticité
Composante majeure des architectures modernes, l’élasticité (aussi appelée scalabilité en bon franglais) est la capacité d’un système à répondre à des contraintes changeantes. On distingue en général deux types d’élasticité : une « verticale » dans laquelle on ajoute des ressources supplémentaires aux éléments existants (plus de processeurs, plus de mémoire, plus de disques…), l’autre « horizontale » où l’on ajoute de nouveaux éléments (un serveur web supplémentaire, un switch additionnel).
Le couplage lâche
Notion d’urbanisme (qui est connexe mais bien différente de l’architecture), le couplage est la nature de l’adhérence qu’ont deux systèmes entre eux. Une architecture moderne et bien pensée doit permettre une adhérence faible avec ses interfaces externes (les autres applications utilisées) et internes (ses propres services, par exemple sa base de données).
Pour reprendre l’exemple de notre restaurant, s’il se fournit directement dans l'entrepôt de son producteur de fraises, il est en couplage fort avec lui (le moindre changement côté producteur l’oblige à revoir tout son processus). Si au contraire le fournisseur lui apporte ses fraises au travers d’un contrat (d’interface), le maraîcher peut évoluer en toute tranquillité de son côté sans impacter notre restaurant favori.
Sans forcément aller dans cet extrême, fournir par exemple des alias DNS à chacun des services utilisés dans votre système peuvent aider à son évolutivité, en permettant des changements d’IP très simplifiés.
Autre exemple : mettre le nom du PDG devant sa place de parking est un couplage fort, mettre sa fonction (PDG) est un couplage faible qui permet de changer le PDG sans changer la plaque...
La simplicité
J’ai travaillé un moment pour un cabinet de conseil dont le slogan à l’époque était « ce qui est simple est fort ». Au delà du marketing, la simplicité est une valeur forte de ma conception de l’architecture : un système simple sera par essence compréhensible donc opérable, extensible et stable dans la durée.
J’ai souvent croisé dans ma vie des systèmes magnifiques, longuement réfléchis, superbes sur le papier mais terriblement complexes dans la réalité, qui au final ont été mis de côté ou mal exploités car ingérables au quotidien par le commun des mortels.
Mais du coup, tous les clients demandent des architecture simples, parfaitement sécurisées, sans interruption, extensibles à l’infini et parfaitement découplées ?
En effet, c’est souvent le début de la discussion : on part d’expressions de besoin brutes et on les affine par la suite, l’architecte apportant les contraintes de temps, de budget et de complexité, afin de permettre au demandeur de préciser ses exigences. On en a parlé en introduction, le métier de l’architecte consiste avant tout à poser les bonnes questions et à démarrer un échange. La question qui doit être posée en premier est toujours « Quel est le besoin ? ».
En résumé
Dans ce chapitre, vous avez appris les grandes caractéristiques qui composent une architecture : la sécurité, l’élasticité, le couplage et la simplicité.
La maîtrise de chacun de ces aspects et le recul nécessaire pour poser les bonnes questions permettant de qualifier les besoins vous permettra de penser des architectures pertinentes, durables, exploitables et dans le budget !
