Construire pour aujourd'hui. Prévoir demain. Prévoir l'échec.

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 5 sur 7 du chapitre Penser comme un architecte de données, le premier chapitre du cours Data Architect. Chaque module se suffit à lui-même. Précédent : L’architecture est l’art des compromis · Suivant : Connaître ses outils : les neuf questions

La question à laquelle répond ce module : comment concevoir pour les exigences d’aujourd’hui tout en prévoyant la croissance et l’échec ?

L’une des erreurs les plus faciles en architecture est de concevoir uniquement pour les exigences qu’on a sous les yeux. Nous avons un projet, un backlog et des exigences. Nous construisons quelque chose qui y répond. Ça fonctionne, et nous crions victoire. Six mois plus tard, le métier change, ou les données grandissent, ou une autre unité veut l’utiliser, ou nous rachetons une société, ou un nouveau système doit s’intégrer, ou quelque chose échoue sans que personne l’ait prévu.

Rien de tout cela ne devrait surprendre un architecte. Nous ne pouvons pas prédire tout ce qui va arriver, mais nous pouvons concevoir en sachant que quelque chose arrivera. C’est pourquoi je regarde l’architecture à travers trois prismes :

Construire pour aujourd’hui. Prévoir demain. Prévoir l’échec.

Il vous faut les trois.

Click to enlarge

Construire pour aujourd’hui

L’architecture commence par le problème que nous avons réellement. Cela paraît évident, mais les architectes peuvent commettre l’erreur inverse de la pensée à court terme : nous pouvons sur-architecturer. Et si nous rachetions douze sociétés, avions un milliard de clients, nous développions dans 40 pays, et que chaque système ait besoin d’une intégration en temps réel ? Peut-être. Mais sont-ce des possibilités réelles, ou inventons-nous des problèmes ? L’architecture ne consiste pas à construire le système le plus sophistiqué qu’on puisse imaginer. Elle consiste à construire le système approprié.

Alors commencez par aujourd’hui : ce dont le métier a besoin, les volumes, utilisateurs et transactions réels, la fréquence à laquelle les données changent et la vitesse à laquelle elles doivent circuler, qui a besoin d’accès, et d’où viennent les données et où elles vont. Et surtout : pourquoi ? Ces réponses nous donnent quelque chose de concret à concevoir.

Cherchez les exigences implicites

Les exigences qu’on vous donne ne sont pas forcément toutes vos exigences. Il y a presque toujours des exigences implicites.

Le métier dit : « Il nous faut les données client dans Salesforce. » D’accord. Alors quelqu’un doit être propriétaire de ces données et décider à quel point elles doivent être fraîches. Il faut savoir ce qui se passe quand le système source est en panne, comment nous remarquerons qu’une synchronisation échoue, et quel côté l’emporte quand Salesforce et la source ne sont pas d’accord. Il faut une durée de conservation, un modèle d’accès, une décision sur les champs sensibles, et un moyen de corriger les mauvaises données.

Rien de tout cela n’était dans la user story. C’est quand même de l’architecture. Une grande partie du métier d’architecte consiste à apprendre à reconnaître les questions que personne n’a encore posées.

Connaissez vos chiffres

Je pousse constamment les architectes à quantifier. Ne me dites pas qu’il y a beaucoup de données ; dites-moi combien. Dix mille, dix millions, cent millions, un milliard ? Ce sont des architectures très différentes. Ne me dites pas que l’intégration tourne fréquemment : toutes les heures, toutes les minutes, mille fois par seconde ? Ne me dites pas que nous grandissons vite. À quelle vitesse ?

Quand je n’ai pas de meilleur chiffre, ma base est 30 % de croissance annuelle. Ce n’est pas une prédiction ; c’est un moyen de forcer la réflexion. Si quelqu’un me dit que nous avons 10 millions d’enregistrements aujourd’hui, je ne veux pas que la discussion s’arrête à 10 millions. À 30 % par an, nous serons à environ 13 millions l’an prochain, 17 millions l’année suivante, et autour de 22 millions l’année d’après. Maintenant, parlons de la conception. Si le métier me dit que 30 % est ridicule, très bien : donnez-moi le vrai chiffre. Le but est de faire de la croissance une partie de la discussion d’architecture.

J’appelle cela le Nombre de Zéros de Steve (Steve’s Number of Zeros). Un zéro de plus peut changer complètement votre architecture. Dix mille, cent mille, un million, dix millions, cent millions : la fonctionnalité n’a pas changé, l’exigence n’a peut-être pas changé, mais l’architecture, peut-être bien.

Vous vous souvenez des rendez-vous du module 1 ? Mettons les vrais chiffres dessus. Plus de 1 200 sites, 100 rendez-vous par site et par jour, six jours par semaine, environ 305 jours par an. Cela fait plus de 36 millions de rendez-vous la première année. Chaque visite crée deux enregistrements, donc plus de 73 millions d’enregistrements. Gardez maintenant cinq ans d’historique, avec 30 % de croissance par an, et on dépasse 650 millions d’enregistrements. Même fonctionnalité, même exigence. Deux zéros de plus, et une architecture très différente.

Prévoir demain

Une fois que je comprends aujourd’hui, je regarde vers l’avant : qu’est-ce qui a des chances raisonnables de changer ? Le volume en fait partie, mais demain ne veut pas seulement dire plus. Cela peut aussi vouloir dire différent : plus de produits, d’unités et de pays ; d’autres exigences de confidentialité ; de nouveaux canaux et intégrations ; une fusion ou une acquisition ; une nouvelle stratégie de données de référence ou plateforme d’analyse ; un agent d’IA qui consomme des informations conçues uniquement pour des humains.

C’est pourquoi je tiens tant à ce que l’architecture puisse grandir par ajout plutôt que par modification constante. Si le métier ajoute un produit, le modèle peut-il l’absorber ? Si un autre système a besoin des données, pouvons-nous les exposer proprement ? Si le volume bondit, avons-nous de la marge ? Si la structure de l’entreprise change, devrons-nous démonter le modèle de données ? Nous n’essayons pas de prédire parfaitement l’avenir. Nous essayons de ne pas nous enfermer dans un coin.

Ne construisez pas demain aujourd’hui

Il y a un équilibre à trouver. Prévoir demain ne veut pas dire construire aujourd’hui le système de demain. Si nous avons 100 000 enregistrements et en aurons peut-être 100 millions dans cinq ans, cela ne veut pas dire que nous construisons maintenant l’architecture pour 100 millions. Elle peut apporter un coût et une complexité dont nous n’avons pas encore besoin.

La question à laquelle je veux une réponse est : l’architecture d’aujourd’hui peut-elle évoluer vers celle de demain ? Si nous pouvons commencer simplement avec un chemin clair, c’est souvent mieux que de payer le coût de la complexité des années trop tôt. Le danger n’est pas de commencer petit. Le danger est de commencer quelque part sans aucune issue.

Prévoir l’échec

Maintenant, la partie dont personne n’aime parler : les choses échouent. Je n’ai jamais conçu de système où chaque composant est resté disponible pour toujours, où chaque intégration a réussi, où chaque utilisateur a saisi des données parfaites, et où chaque système externe s’est comporté exactement comme documenté. Alors ne concevez pas ce système-là.

Demandez ce qui peut échouer, puis ce qui se passe quand ça échoue. Une intégration expire. Une API rejette une requête. Un chargement de nuit traite 800 000 enregistrements et échoue sur 200 000. Un système source tombe en panne. Un utilisateur saisit des données invalides. Un identifiant externe apparaît deux fois. Un système en amont change le format d’une valeur sans changer le nom du champ. Un processus réussit dans un système et échoue dans un autre. Ce ne sont pas des cas limites inhabituels. C’est à cela que ressemble la production.

Une réussite partielle reste un échec à comprendre

Les échecs partiels sont particulièrement dangereux en architecture de données. Imaginez que vous déplacez un million d’enregistrements, et que le processus indique qu’il est terminé. Parfait. Mais un million sont-ils arrivés, ou 999 997, et lesquels manquent ? Peut-être que 200 000 ont échoué, que certains ont été créés deux fois, ou que tout est arrivé mais que certains champs ont échoué à la transformation.

« Tâche terminée » n’est pas la même chose que les données sont correctes. Un architecte de données pense au rapprochement : comment savons-nous ce qui aurait dû se passer, ce qui s’est réellement passé, et la différence ? Et qu’est-ce que nous faisons à ce sujet ?

Voici ce que je fais quand les systèmes deviennent complexes. Les enregistrements vont de A vers B, de gauche à droite. Puis B renvoie quelque chose : une confirmation pour chaque enregistrement reçu et enregistré. A peut maintenant comparer ce qu’il a envoyé avec ce qui a été confirmé. Si chaque enregistrement a sa confirmation, l’exécution a réussi. S’il manque des confirmations, elle a échoué, quoi qu’en dise le statut de la tâche, et nous savons exactement quels enregistrements traiter : les réessayer, les confier à une personne, ou déclencher une alerte.

Click to enlarge

Échouer proprement

Quand l’échec arrive, je veux savoir ce que fait ensuite le système : s’il réessaie, et si c’est automatique ou non ; ce qui se passe si la même transaction est traitée deux fois ; où vont les enregistrements en échec, et si les bons enregistrements continuent de passer à côté d’un mauvais ; qui est alerté, avec quelles informations, et comment il rejoue l’échec ; et comment un utilisateur apprend que quelque chose s’est mal passé.

Et surtout : pouvons-nous reprendre sans aggraver le problème ? Une stratégie de nouvelle tentative qui crée des doublons n’est pas vraiment une stratégie de reprise. Une bonne architecture suppose l’échec et nous donne un chemin de retour.

Surveillez ce qui compte

Prévoir l’échec sans surveillance, ce n’est pas vraiment prévoir. Si une intégration échoue à 2 h du matin et que personne ne le remarque avant qu’un client appelle trois jours plus tard, nous n’avions pas d’architecture d’exploitation. Nous avions de l’espoir.

Décidez de ce qui doit être observable : le processus a-t-il tourné, combien de temps a-t-il pris, combien d’enregistrements ont été traités, combien ont réussi et échoué ? Les volumes sont-ils soudain différents de la normale ? Le retard s’accumule-t-il, les erreurs augmentent-elles ? L’architecture ne s’arrête pas quand le déploiement réussit. Quelqu’un doit exploiter ce système demain, et cela fait partie de la conception.

Pensez dans les trois directions

Continuez d’appliquer les trois prismes dans le reste de ce cours. Quand nous concevons un modèle de données : fonctionne-t-il aujourd’hui, peut-il grandir demain, et que se passe-t-il quand les données sont fausses ou incomplètes ? Une intégration : déplace-t-elle les données d’aujourd’hui, peut-elle absorber le volume et les systèmes de demain, et que se passe-t-il quand un côté est en panne ? Les gros volumes de données : qu’avons-nous aujourd’hui, où vont les chiffres, et comment reprendre quand une grosse opération ne réussit qu’en partie ?

La technologie change d’un chapitre à l’autre. Les questions, non.

L’architecture existe dans la durée

Un développeur peut parfois regarder une exigence et se demander : « Est-ce que ça marche ? » L’architecte doit en demander plus : est-ce que ça marche aujourd’hui, est-ce que ça marchera encore demain, et que se passe-t-il quand ça ne marche pas du tout ? Ces trois questions nous emmènent au-delà de la mise en œuvre, dans la vie du système.

Vous ne prédirez pas toutes les exigences futures et n’éviterez pas tous les échecs. Ce n’est pas le but. Le but est de construire quelque chose d’adapté à ce que nous savons aujourd’hui, de nous laisser une issue pour demain, et d’avoir un plan pour quand la réalité ne coopère pas.

Construire pour aujourd’hui. Prévoir demain. Prévoir l’échec. Nous utiliserons ces trois prismes encore et encore.

Ce que l’architecte décide ici

• Quels sont les volumes et la croissance réels, et quels chiffres changeraient la conception.
• Quelles exigences implicites le métier n’a pas encore exprimées.
• Comment la conception d’aujourd’hui peut évoluer vers celle de demain, sans construire aujourd’hui le système de demain.
• Ce qui se passe quand quelque chose échoue : reprise, rapprochement et surveillance.