Assez rapidement, quand on développe un système e-commerce (à ma connaissance, je suis le seul à utiliser ce terme, je devrais le déposer 😉 ), on doit découper le système en plusieurs composants.
Mais le découpage est rarement satisfaisant.
Rarement satisfaisant ?
- La plupart du temps, une bonne partie des fonctions se recoupent entre les différents composants ;
- L’expérience des utilisateurs métier n’est pas cohérente. Chaque composant propose son propre back office, et les équipes métiers, qui travaillent sur ces interfaces, doivent jongler d’un système à l’autre
- Les mises à jours deviennent complexes, avec des coûts et des délais difficile à bien anticiper, parce que, comme chaque composant propose sa propre logique, il faut adapter « profondément » l’évolution à chaque composant
Alors, ou est le bug ?
Est-ce une erreur de découper un problème en sous parties ?
Non, bien sûr, le problème n’est pas là.
Le problème est assez simple en fait :
Les modules qu’on assemble ne sont pas réellement fait les uns pour les autres, tout simplement.
L’assemblage est donc un « bricolage ». Je ne mets pas en doute le travaille technique (c’est un autre sujet). Mais brancher ensemble deux systèmes qui ne sont pas fait pour ça, ça ne peut pas faire une solution de qualité (malgrés les promesses commerciales…). Ou alors, le cout devient rédhibitoire.
Alors, quelle est la solution ?
Il faut être pragmatique. Cette solution n’est pas complètement satisfaisante, mais c’est bien souvent la meilleure qu’on ait sous la main. Cette réflexion est donc plus une réflexion « moyen terme » qu’autre chose.
Pour aujourd’hui, une bonne tactique, c’est bien souvent d’identifier un composant « leader », et d’effectuer un assemblage autour de ce composant central.
Un autre élément de qualité, c’est de monter une architecture SOA. Cela permet au moins de définir des contrats clean entre les composants.
Demain, je suis convaincu que les choses vont/doivent changer…
Un des éléments qui doit bouger, j’en ai la conviction, c’est la couverture fonctionnelle d’un composant.
Pour moi, c’est la base d’une architecture à base de plusieurs « briques » : chaque brique doit répondre à une description fonctionnelle très précise. Et qu’on arrête de mélanger interface et coeur du système !
Je n’invente rien en disant ça, j’applique simplement les fondamentaux de la conception modulaire, qui n’ont pratiquement pas bougés depuis 20 ans :
Un module doit définir clairement son interface métier (son API quoi) : c’est le contrat qui doit être rempli par le module.
D’ailleurs, sur des briques plus anciennes, et donc plus mûres, la promesse est bien plus claire. Exemple : un système de gestion de bases de données… gère des données. Les choses sont bien séparées entre le moteur et l’interface. On devrait avoir ce type de séparation, pour monter notre système e-commerce de demain.
C’est un sujet excitant, parce qu’il y a beaucoup à faire, et beaucoup de valeur à apporter !
Si cela vous intéresse d’en savoir plus sur ce sujet passionnant, que vous avez une expertise d’architecte, vous connaissez bien la technique, et vous vous dites que l’aventure est peut être pour vous, contactez moi !
