Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
Le piège du monolithe composable
Le composable commerce promet flexibilité, rapidité et cycles de vie de services indépendants. Sur le papier, une nette amélioration par rapport au monolithe classique. Dans la pratique, nous observons fréquemment un schéma inconfortable. Une configuration nominalement composable se comporte comme un monolithe. Patrick Friday, CEO d'Alokai, a inventé le terme monolithe composable pour désigner cet anti pattern. C'est l'un des pièges les plus courants pour les clients SFCC qui empruntent la voie du composable. Cet article montre comment le repérer et comment l'éviter.
Qu'est-ce qu'un monolithe composable
Un monolithe composable est une configuration qui, sur le papier, remplit tous les critères du composable. Plusieurs services indépendants. Des API entre les couches. Une architecture headless. Mais dès que vous essayez de remplacer un composant ou d'ajouter une nouvelle fonction, l'opération ressemble à un replatforming classique.
Les symptômes sont sans équivoque. Le remplacement d'un service prend des mois au lieu de semaines. L'optimisation des performances exige des changements sur toutes les couches à la fois. Les initiatives marketing nécessitent des sprints d'ingénierie alors qu'elles sont nominalement composable. Les mises en production restent séquentielles plutôt qu'indépendantes.
Ces symptômes ont une origine commune. Les services ne sont pas vraiment indépendants. Ils sont couplés par les modèles de données, les contrats d'API et des hypothèses implicites, au point que chaque changement à un endroit se répercute sur plusieurs autres.
Comment naît le monolithe composable
Trois causes se combinent pour le produire.
Premièrement. Absence de couche de données unifiée. Si le frontend parle directement à l'API de chaque service, les services sont câblés en dur dans le frontend. Remplacer un service signifie refactoriser le frontend.
Deuxièmement. Dépendances de données implicites. Lorsque des services font des hypothèses sur les structures de données d'autres services sans que ces hypothèses soient documentées ou versionnées, un couplage caché apparaît.
Troisièmement. Absence de responsabilité de plateforme. Sans responsabilité architecturale claire, les services se développent de façon organique et non coordonnée. Personne n'a la vue d'ensemble, personne ne protège contre les mauvais patterns.
Trois symptômes typiques dans les configurations SFCC
Nous observons le monolithe composable particulièrement souvent chez les clients SFCC dans les constellations suivantes.
Symptôme un. La recherche a été externalisée vers Algolia, mais les composants frontend appellent directement l'API d'Algolia. Passer à Constructor implique de modifier des dizaines de composants.
Symptôme deux. Un CMS headless a été introduit, mais les modèles de contenu sont alignés sur les structures de données SFCC. Remplacer le backend implique de migrer aussi chaque modèle de contenu.
Symptôme trois. La personnalisation a été construite sur plusieurs outils SaaS, mais les données clients vivent en silos. Une vue client cohérente ne voit jamais le jour. Chaque nouvelle initiative de personnalisation commence par une discussion sur le pipeline de données.
Comment éviter le monolithe composable
Quatre principes aident à construire une véritable architecture composable.
Principe 1 : la couche de données unifiée comme couche centrale
Le frontend ne parle jamais directement aux services best of breed. Il parle à une couche de données unifiée qui abstrait les services. Remplacer un service ne change que la couche d'adaptation, pas le frontend.
Principe 2 : des contrats de service clairs
Chaque service définit explicitement son contrat d'API. Les autres services ne doivent pas accéder à ses détails internes. Le versionnage des contrats est obligatoire.
Principe 3 : la responsabilité de plateforme
Une personne ou une petite équipe porte la responsabilité architecturale. Les remplacements de services sont coordonnés de façon centralisée. La gestion du cycle de vie est une discipline à part entière.
Principe 4 : des points de contrôle de maturité composable
Au moins une fois par trimestre, vérifiez à quel point les services sont réellement indépendants. Pouvez-vous remplacer un service en quatre semaines ? Si non, il y a un couplage caché.
Ce qu'apporte une plateforme frontend moderne
Une plateforme Frontend as a Service intègre plusieurs de ces principes par défaut. La couche de données unifiée fait partie de la plateforme. Les adaptateurs de service sont versionnés et gérés de façon centralisée. La responsabilité de plateforme est structurellement portée par le produit.
En s'appuyant sur une telle plateforme, on évite en grande partie le piège du monolithe composable. Il faut activement faire quelque chose de travers pour y tomber. Sur une configuration sur mesure, le piège est l'état par défaut.
Une checklist pour les clients SFCC
Six questions aident à repérer si vous êtes en train de tomber dans un monolithe composable.
Premièrement. Votre frontend parle-t-il directement à chaque API de service ou à une couche de données unifiée ?
Deuxièmement. Vos modèles de contenu sont-ils liés au modèle de données du backend ?
Troisièmement. Pouvez-vous remplacer un service best of breed en quatre semaines ou moins ?
Quatrièmement. Les données clients sont-elles dans une couche centrale ou dispersées en silos ?
Cinquièmement. Qui porte aujourd'hui la responsabilité architecturale ?
Sixièmement. À quelle fréquence évaluez-vous la maturité composable ?
Si trois de ces questions ou plus ont des réponses inconfortables, vous vous dirigez vers le monolithe composable.
En résumé
Le composable commerce n'est un progrès que s'il est construit correctement. Le piège du monolithe composable fait partie des erreurs les plus courantes des clients SFCC. Il provient d'une architecture de couche de données absente, de dépendances de données implicites et d'une responsabilité de plateforme absente. Pour l'éviter, il faut des principes clairs et, idéalement, une plateforme qui les soutient structurellement.
Si vous voulez un état des lieux honnête pour savoir si votre configuration composable SFCC est vraiment composable, contactez-nous. Nous livrons une évaluation de maturité claire avec des recommandations concrètes.
Plus sur la plateforme Laioutr
Lecture connexe : Le piège de la vue client unique : pourquoi des données clients « parfaites » ralentissent le composable commerce et Composable vs Monolithe : le cadre de décision honnête pour les clients SAP CC.