L'architecture est l'art des compromis

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · 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) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

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

Module 4 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 : Le test de réversibilité · Suivant : Construire pour aujourd’hui. Prévoir demain. Prévoir l’échec.

La question à laquelle répond ce module : quand plusieurs solutions pourraient fonctionner, comment un architecte choisit-il, et comment explique-t-il son choix ?

Si l’architecture consistait simplement à trouver la bonne réponse, ce serait beaucoup plus facile. Apprenez la plateforme, apprenez les modèles, apprenez les limites, choisissez le bon, terminé.

Ce n’est pas ainsi que fonctionne l’architecture réelle. Les décisions difficiles ne se jouent généralement pas entre une solution manifestement bonne et une solution manifestement mauvaise. Elles se jouent entre plusieurs solutions qui pourraient fonctionner, chacune avec ses avantages et ses inconvénients, chacune emmenant l’architecture dans une direction légèrement différente. C’est là que l’architecte gagne sa place à la table.

De nombreuses façons de résoudre le problème

J’ai utilisé une version de cet exemple de nombreuses fois pour former des architectes.

Il peut y avoir de nombreuses façons de résoudre un problème dans Salesforce. Je mets parfois un chiffre dessus, disons dix, mais c’est une analogie, pas un décompte. Beaucoup d’options posent problème dès le départ : elles se heurtent à une contrainte de la plateforme, manquent une exigence critique, ou créent un problème de sécurité ou de performance que nous ne pouvons pas accepter. Nous pouvons les écarter rapidement. D’autres fonctionnent aujourd’hui mais poseront problème quand les données grandiront. Elles fonctionnent techniquement, mais ne tiendront pas face à la croissance que nous savons déjà venir.

Il reste un petit nombre d’options capables de répondre à vos besoins à l’avenir, et c’est là que cela devient intéressant. Chacune peut fonctionner, passer à l’échelle et satisfaire les exigences. Alors, laquelle est correcte ? Peut-être toutes. Le travail de l’architecte est de comprendre les différences.

Même quelque chose d’aussi simple qu’une liste de sélection fonctionne aujourd’hui et peut poser problème à mesure que les données grandissent. Une liste de sélection est facile pour les utilisateurs. Mais demandez d’où viennent les valeurs, et combien il peut y en avoir. Les listes de sélection fonctionnent mieux avec moins d’une vingtaine de valeurs. Il nous arrive de monter à 50, comme les États américains, et rarement au-delà de 100, comme les pays, et celles-là deviennent encombrantes. Pour chaque liste de sélection, connaissez donc la limite haute. Et changer les valeurs d’une liste de sélection est un changement de métadonnées, pas un changement de données.

Utilisez plutôt une relation de référence, et l’interface utilisateur devient un peu plus complexe. Mais la liste peut continuer de grandir sans limite haute, et de nouvelles valeurs peuvent arriver par une intégration. C’est un compromis avec la facilité d’utilisation. C’est l’équilibre.

Click to enlarge

Optimal ne veut pas dire parfait

J’emploie le mot optimal avec prudence. Une architecture optimale n’est pas une architecture où chaque décision individuelle est parfaite ; cette architecture n’existe probablement pas. C’est une architecture où la solution d’ensemble est équilibrée.

Supposons que la solution A offre les meilleures performances mais soit chère et difficile à maintenir. La solution B coûte moins cher et est plus facile à exploiter, mais sacrifie un peu de performance. La solution C est plus souple pour l’avenir mais ajoute de la complexité aujourd’hui. Laquelle est optimale ? Je ne peux pas répondre avec ces seuls éléments. Il me faut connaître le métier, les exigences et les priorités, et savoir quelles contraintes sont réelles et lesquelles sont des préférences. L’architecture dépend du contexte. C’est pourquoi le modèle qui était juste pour un client peut être complètement faux pour le suivant.

Et votre travail d’architecte de données est d’équilibrer ces décisions. Vous en prendrez des dizaines, seul ou avec votre équipe. Sachez lesquelles, et sachez quand une décision a un impact plus grand, sur le coût, le délai ou les fonctionnalités, et doit remonter aux principaux décideurs.

Une décision sous-optimale peut faire partie d’une architecture optimale

C’est l’une des idées les plus importantes de ce chapitre. Il m’arrive de prendre sciemment une décision sous-optimale dans une partie de l’architecture parce qu’elle améliore la solution dans son ensemble.

Peut-être que je duplique une petite quantité de données, parce que supprimer la duplication créerait une complexité d’intégration inutile. Peut-être que je choisis un modèle de données plus simple, parce que le modèle théoriquement plus propre rendrait les rapports et l’usage quotidien beaucoup plus difficiles. Peut-être que j’accepte un petit coût en performance, parce que l’alternative ajoute une infrastructure que l’organisation n’est pas prête à exploiter.

Regardez n’importe laquelle de ces décisions isolément et vous direz qu’elle n’est pas optimale. C’est exact. Mais l’architecture ne consiste pas à optimiser chaque composant séparément ; elle consiste à optimiser le système. Une décision localement sous-optimale peut faire partie d’une architecture globalement optimale, tant que nous comprenons le compromis que nous faisons. Ce qui est dangereux, c’est de faire le compromis sans savoir qu’on le fait.

Sachez à quoi vous renoncez

Chaque fois que quelqu’un me dit « c’est la meilleure solution », ma question suivante est « la meilleure pour quoi ? ». La plus rapide ? La moins chère ? La plus simple ? La plus évolutive, la plus sûre, la plus souple ? La plus facile à exploiter, la plus rapide à livrer, la moins dépendante de compétences spécialisées ? Il y a presque toujours une autre dimension où la réponse n’est pas « la meilleure ». C’est le compromis. Je veux savoir ce que nous obtenons, et je veux aussi savoir à quoi nous renonçons.

Prenons deux options pour un grand ensemble de données d’entreprise. L’une copie les données dans Salesforce, ce qui rend les fonctionnalités natives de Salesforce plus faciles à utiliser, mais nous voilà responsables de les déplacer, de les stocker, de les synchroniser, de sécuriser une copie de plus et de gérer la latence. L’autre laisse les données là où elles sont et y accède au besoin. Nous avons supprimé une partie de la duplication, mais la disponibilité, les performances des requêtes, les dépendances réseau et les capacités du système distant comptent davantage. Aucune de ces descriptions ne nous dit laquelle choisir. Elles nous disent quelles questions poser.

Les exigences ne se valent pas toutes

Les compromis nous obligent aussi à voir que toutes les exigences n’ont pas le même poids.

Quelqu’un dit : « Les données doivent être disponibles instantanément. » D’accord, que veut dire instantanément ? Une seconde, dix secondes, une minute ? Et pourquoi ? Peut-être s’agit-il de détection de fraude, où les secondes comptent. Peut-être que quelqu’un n’aime simplement pas attendre le chargement de nuit. Ce sont des exigences très différentes, et l’architecte continue de poser des questions jusqu’à savoir laquelle nous avons.

J’aime les exigences qui résistent aux questions : combien, combien de fois, à quelle vitesse, à quelle fréquence, pour qui, et que se passe-t-il si nous ne le faisons pas ? « Rapide » n’est pas une exigence d’architecture. « 95 % des mises à jour client doivent être disponibles pour l’agent de service en moins de 30 secondes » s’en rapproche beaucoup plus. Maintenant, nous pouvons évaluer des compromis.

Les contraintes changent la réponse

Parfois, l’architecture n’est pas du tout contrainte par la technologie. Elle l’est par l’argent, les personnes, le temps, les licences ou la maturité de l’organisation.

Une architecture techniquement excellente qui exige une équipe d’exploitation que l’entreprise n’a pas n’est pas une bonne architecture. Une fonctionnalité qui résout élégamment le problème mais exige des licences que le client n’achètera pas n’est pas non plus la solution. Et la transformation parfaite sur trois ans n’aide pas une entreprise qui doit se lancer dans huit semaines.

Rien de tout cela ne veut dire que nous abandonnons une bonne architecture à cause d’une échéance. Cela veut dire que nous comprenons ce que nous sacrifions, pourquoi, et quelles conséquences nous acceptons, et idéalement comment nous passerons du compromis d’aujourd’hui à l’architecture de demain.

L’architecte a besoin d’une image de « l’optimal »

Voici une tension intéressante. Je vous dis qu’il n’y a souvent pas une seule réponse parfaite, et je veux aussi que vous gardiez en tête l’image de ce à quoi ressemble une solution optimale. Ce n’est pas contradictoire. Il vous faut un point de référence.

Quand je regarde un modèle de données, je veux savoir ce que je construirais si je pouvais optimiser pour les exigences sans contraintes inutiles. Ensuite, quand des contraintes réelles nous éloignent de cette conception (on aplatit une partie du modèle, on duplique des données, on reporte une intégration, on accepte un processus manuel temporaire), je ne fais pas des compromis au hasard. Je sais dans quelle direction je m’éloigne de l’optimal, et pourquoi. C’est l’art de l’architecture, et cet instinct demande de la pratique.

Dessinez-le

L’une des meilleures façons de comprendre un compromis est de le dessiner. Les schémas d’architecture ne sont pas des décorations pour un diaporama ; ce sont des outils de réflexion. Si nous hésitons entre deux approches, dessinez les deux. Où vivent les données, et où circulent-elles ? À qui appartiennent-elles ? Où sont les frontières, et où la sécurité est-elle appliquée ? Que se passe-t-il quand quelque chose échoue, et qu’est-ce qui change quand le volume grandit ?

Un schéma oblige l’ambiguïté à sortir au grand jour, et il donne à tout le monde la même image à montrer du doigt.

J’ai compris à quel point cela compte sur un projet pour un fournisseur d’énergie. Revue après revue, je me retrouvais à réexpliquer les mêmes concepts et à ramener la conversation vers la conception d’origine. J’ai donc changé la façon de mener ces réunions : chaque revue commençait avec le modèle de données à l’écran. Pas le modèle détaillé avec tous les champs. Un modèle résumé : un compte a des contacts, cet enregistrement a des enfants, voici où s’accroche le travail. La salle était surtout composée de dirigeants, et cela prenait deux ou trois minutes.

Comme c’étaient les mêmes personnes de réunion en réunion, le schéma est devenu notre langage commun. Les gens ont commencé à utiliser ses noms. Les questions répétées se sont estompées, et les réunions sont devenues beaucoup plus faciles. J’appelle cela ancrer la réunion : un schéma simple, montré à chaque fois, valait bien plus que ce qu’il avait coûté à faire.

Le but n’est pas la perfection artistique. Parfois, c’est un schéma détaillé pour des ingénieurs, parfois cinq boîtes et six flèches pour un dirigeant. Le but, c’est la clarté.

Expliquez le compromis

Un bon architecte présente les choses dans l’ordre : voici les options que nous avons envisagées, voici ce que chacune nous apporte, voici ce que chacune nous coûte, voici l’option que je recommande, et voici pourquoi.

Remarquez que la recommandation vient après les compromis. Je ne veux pas que l’architecture devienne « j’ai déjà fait ça, faites-moi confiance ». L’expérience compte énormément ; elle aide à reconnaître les modèles plus vite et à voir les problèmes plus tôt. Mais votre expérience doit améliorer votre raisonnement, pas le remplacer. Notre travail n’est pas seulement de comprendre l’architecture. C’est d’aider l’organisation à comprendre la décision, surtout quand ceux qui tranchent au final ne sont pas architectes.

Penser juste. Penser vite.

Vous n’aurez pas toujours trois semaines pour analyser chaque option. Parfois, vous aurez trois minutes. Une exigence change en réunion, quelqu’un nomme une contrainte que vous ignoriez, ou un dirigeant demande : « Et si on en a besoin en Europe l’année prochaine ? »

J’ai utilisé la formule Think Correct. Think Fast. (penser juste, penser vite). La vitesse ne vient pas de sauter la réflexion. Elle vient d’avoir assez réfléchi avant que le moment arrive : vous avez appris les modèles, vous connaissez la plateforme, vous avez vu des échecs, vous savez quelles questions poser et quelles décisions sont difficiles à défaire. C’est pourquoi nous travaillons sur des scénarios tout au long de ce cours. Plus vous analysez de décisions, plus vite vous reconnaissez la forme de la suivante.

J’avais un client qui avait besoin de saisir des formulaires. Mais il y avait de nombreux formulaires, et les questions pouvaient changer avec le temps. J’ai rapidement reconnu le besoin d’un modèle de données d’enquête, un modèle sur lequel nous reviendrons plus tard dans le cours. Parce que j’ai reconnu le modèle et la solution, j’ai pu apporter un modèle de données plus complet, qui prenait en charge les exigences encore à venir, pas seulement celles que nous avions sous les yeux.

L’architecture est une affaire d’équilibre

En allant plus loin dans l’architecture de données, vous rencontrerez des choix pour lesquels je refuse de vous donner une règle simple. Normaliser ou aplatir ? Copier les données ou les fédérer ? Synchrone ou asynchrone ? Objet standard ou personnalisé ? Archiver ou garder en ligne ?

Il y a des principes, des modèles et des limites, et parfois des réponses clairement fausses. Mais souvent, le travail de l’architecte est de trouver le bon équilibre pour ce système, ce métier et ce moment.

Sachez à quoi ressemble l’optimal. Comprenez les contraintes. Identifiez les options viables. Rendez les compromis visibles. Puis prenez la décision.

Ce n’est pas de l’indécision. C’est de l’architecture.

Ce que l’architecte décide ici

• Quelles options sont viables, et lesquelles sont fausses dès maintenant ou le deviendront dans un an.
• Ce que chaque option viable gagne et sacrifie, mesuré par rapport à des exigences qui résistent aux questions.
• Quelles contraintes sont réelles et lesquelles ne sont que des préférences.
• Quelle option recommander, après avoir exposé les compromis, et comment l’expliquer.