Le retour d'expérience du mois
Retour vers le Journal
Olivier FRUY est Leader Architecte d’Entreprise chez KIABI. Pour moderniser l’architecture parfois un peu rigide des applications Back et Front Office, KIABI a enrichi l’architecture Middle Office avec un concept en double couche. Lors de la matinale Architecture d’Entreprise le 25 avril 2024, Olivier FRUY est venu nous en dire plus…
Le monde de la distribution est en pleine révolution, et ceux qui ne parviennent pas à s’adapter se mettent en péril. Aujourd’hui notre modèle de vente est totalement cross-canal, avec en plus de nos 580 magasins Kiabi (dont une dizaine de franchisés ayant chacun leur propre SI) dans 23 pays, notre markerplace kiabi.com, des présences sur des places de marché web comme Myntra (Inde), des corners Kiabi dans des magasins Auchan, Cora ou Coop, mais aussi des corners d’autres marques dans les magasins Kiabi. Ce modèle de vente hétérogène nous oblige à discuter avec beaucoup de partenaires externes, aussi bien en termes de front que de back-office.
Historiquement, nous avions un modèle d’architecture qui se traduisait par une interaction forte entre les applications front-office et back-office, et donc très rigide. Nous avons alors cherché un moyen de rendre le couplage moins étroit, optimisé, ouvert à l’adjonction de nouvelles applications back ou front, et de nouvelles technologies. L’idée nous est venue de décomposer le Middle Office en deux couches, l’une interfaçant les applications front-office et l’autre les applications back-office,
Pour définir le Middle Office, je dirais que c’est un concept d’architecture modulaire, qui se compose classiquement en vertical « d’applications » adressant chacune un « objet métier » (offre, stock, client, commande…). Mais nous avons eu l’idée de découper également en horizontal en une couche « Upper Middle » qui s’interface avec les applications front et une couche « Lower Middle » avec les applications back.
Pour le Lower Middle, les enjeux de disponibilité sont un peu moindres – de l’ordre de 99% - car même en cas de légère dégradation de l’expérience client, les modules Lower Middle n’ont pas d’impact direct sur l’acte d’achat. On retrouvera dans les modules Lower middle les logiques métier parfois un peu plus complexes. On est potentiellement sur du spécifique ou alors sur des solutions packagées en mode SaaS.
En termes d’implémentation, on va avoir 2 implémentations standards. Dans le premier cas (A sur le diagramme) nous allons créer deux applications. Sur la couche Lower, on trouvera, selon les besoins, un progiciel du marché ou un logiciel spécifique. Et sur la couche Upper, on aura une application qui va traiter à la fois les données utilisées par le Front et celles transmises par la couche Lower Middle. L’application Upper Middle peut se comporter un peu comme un cache intelligent, qui va faire le tampon de données, en attendant que le Lower Middle se mette à jour. Le dialogue entre Upper et Lower se fait par échange de messages en mode pub/sub.
En ce qui concerne la 2ème implémentation (B) spécifique pour les progiciels, le choix a été de ne pas utiliser les API standards du logiciel en Lower Middle, pour des raisons de simplicité pour les applications front. En effet, sur certains progiciels, il faut passer par 2 ou 3 appels API pour réaliser une tâche. Dans la partie Upper, on a créé ce qu’on appelle des API façades. Avec un seul appel à cette API façade, les différents appels des API du progiciel seront orchestrés par l’application Upper, afin d’exposer aux applications front un service beaucoup plus simple, plus compréhensible et donc plus facile à implémenter par les applications front. De plus, si jamais nous décidons de changer de progiciel SaaS dans la partie Lower Middle, nous réécrirons une nouvelle API façade, avec les mêmes interfaces Front, pour que ceci ne change rien pour les applications front.
Nous avons fait le choix de GCP pour l’hébergement. Les bases de données se répartissent entre MongoDB et PostgreSQL. MongoDB est utilisé majoritairement sur les couches Upper notamment pour assurer l’ultra haute disponibilité, alors que PostgreSQL sera plutôt privilégié pour les couches Lower ayant un niveau de complexité « métier » plus élevé.
Cette architecture permet une urbanisation beaucoup plus propre et plus simple, et d’assurer la très haute disponibilité afin d’améliorer la fiabilité et la fluidité de l’acte d’achat.
Le Middle Office est événementiel, ou event-driven. L’objectif principal du Upper Middle est d’exposer des API pour les front-office pour un fonctionnement temps réel. Mais il a également besoin de discuter avec les applications Lower, et dans ce cas, on oblige à une utilisation fil de l’eau (Pub/sub). On interdit sur cette couche des traitements de type « batchs » (qui pourraient pénaliser la performance et la disponibilité des API). En revanche, sur la couche Lower, tous les mécanismes d’échanges sont possibles (API, Pub/sub, ESB et ETL).
Le pattern technique a été validé, et ce travail réalisé permet d’aboutir à une vraie cohérence technologique. Cette cohérence technique (en particulier sur la couche Upper) est un enjeu majeur pour l’exploitabilité de ces solutions en 24x7.
Avec d’éviter cet écueil, nous avons introduit le concept « d’inversion de dépendance ». Le principe est que ce sont les applications du Middle Office qui imposent les formats d’échanges. Charge aux applications utilisant ses services de d’adapter à lui. Pour les fronts, ce sont des couches de type « back-for-front » qui réalisent cette tâche. Pour les applications back (souvent des progiciels), l’implémentation de ce concept est parfois plus délicate et parfois plus coûteuse à court-terme, mais reste une cible prioritaire pour conserver un Middle agile et performant.
Quel a été le déclencheur de ce projet Middle Office ?
Le monde de la distribution est en pleine révolution, et ceux qui ne parviennent pas à s’adapter se mettent en péril. Aujourd’hui notre modèle de vente est totalement cross-canal, avec en plus de nos 580 magasins Kiabi (dont une dizaine de franchisés ayant chacun leur propre SI) dans 23 pays, notre markerplace kiabi.com, des présences sur des places de marché web comme Myntra (Inde), des corners Kiabi dans des magasins Auchan, Cora ou Coop, mais aussi des corners d’autres marques dans les magasins Kiabi. Ce modèle de vente hétérogène nous oblige à discuter avec beaucoup de partenaires externes, aussi bien en termes de front que de back-office.Historiquement, nous avions un modèle d’architecture qui se traduisait par une interaction forte entre les applications front-office et back-office, et donc très rigide. Nous avons alors cherché un moyen de rendre le couplage moins étroit, optimisé, ouvert à l’adjonction de nouvelles applications back ou front, et de nouvelles technologies. L’idée nous est venue de décomposer le Middle Office en deux couches, l’une interfaçant les applications front-office et l’autre les applications back-office,
Concrètement, qu’avez-vous mis en place ?
Tout d’abord je voudrais préciser que le Middle Office a été déployé pour traiter un certain nombre de problématiques qui s’adressent uniquement aux activités en lien direct avec la vente. Pour les applications comme la Finance, les RH, les inventaires, etc… le Middle Office n’a pas de raison d’être.Pour définir le Middle Office, je dirais que c’est un concept d’architecture modulaire, qui se compose classiquement en vertical « d’applications » adressant chacune un « objet métier » (offre, stock, client, commande…). Mais nous avons eu l’idée de découper également en horizontal en une couche « Upper Middle » qui s’interface avec les applications front et une couche « Lower Middle » avec les applications back.
Upper et Lower Middle
La couche Upper Middle est au plus près de l’acte d’achat du client. Il faut dont qu’elle ait un niveau de disponibilité très fort, a minima 99,9%, et que les applications aient une très haute performance, c’est la raison pour laquelle nous utilisons principalement des micro-services avec des accès API depuis les applications Front.Pour le Lower Middle, les enjeux de disponibilité sont un peu moindres – de l’ordre de 99% - car même en cas de légère dégradation de l’expérience client, les modules Lower Middle n’ont pas d’impact direct sur l’acte d’achat. On retrouvera dans les modules Lower middle les logiques métier parfois un peu plus complexes. On est potentiellement sur du spécifique ou alors sur des solutions packagées en mode SaaS.
En termes d’implémentation, on va avoir 2 implémentations standards. Dans le premier cas (A sur le diagramme) nous allons créer deux applications. Sur la couche Lower, on trouvera, selon les besoins, un progiciel du marché ou un logiciel spécifique. Et sur la couche Upper, on aura une application qui va traiter à la fois les données utilisées par le Front et celles transmises par la couche Lower Middle. L’application Upper Middle peut se comporter un peu comme un cache intelligent, qui va faire le tampon de données, en attendant que le Lower Middle se mette à jour. Le dialogue entre Upper et Lower se fait par échange de messages en mode pub/sub.
En ce qui concerne la 2ème implémentation (B) spécifique pour les progiciels, le choix a été de ne pas utiliser les API standards du logiciel en Lower Middle, pour des raisons de simplicité pour les applications front. En effet, sur certains progiciels, il faut passer par 2 ou 3 appels API pour réaliser une tâche. Dans la partie Upper, on a créé ce qu’on appelle des API façades. Avec un seul appel à cette API façade, les différents appels des API du progiciel seront orchestrés par l’application Upper, afin d’exposer aux applications front un service beaucoup plus simple, plus compréhensible et donc plus facile à implémenter par les applications front. De plus, si jamais nous décidons de changer de progiciel SaaS dans la partie Lower Middle, nous réécrirons une nouvelle API façade, avec les mêmes interfaces Front, pour que ceci ne change rien pour les applications front.
Nous avons fait le choix de GCP pour l’hébergement. Les bases de données se répartissent entre MongoDB et PostgreSQL. MongoDB est utilisé majoritairement sur les couches Upper notamment pour assurer l’ultra haute disponibilité, alors que PostgreSQL sera plutôt privilégié pour les couches Lower ayant un niveau de complexité « métier » plus élevé.
Cette architecture permet une urbanisation beaucoup plus propre et plus simple, et d’assurer la très haute disponibilité afin d’améliorer la fiabilité et la fluidité de l’acte d’achat.
Un peu de technique
Pour assurer la résilience, la montée à l’échelle, et la très haute disponibilité, le Middle Office s’appuie sur une architecture totalement cloud.Le Middle Office est événementiel, ou event-driven. L’objectif principal du Upper Middle est d’exposer des API pour les front-office pour un fonctionnement temps réel. Mais il a également besoin de discuter avec les applications Lower, et dans ce cas, on oblige à une utilisation fil de l’eau (Pub/sub). On interdit sur cette couche des traitements de type « batchs » (qui pourraient pénaliser la performance et la disponibilité des API). En revanche, sur la couche Lower, tous les mécanismes d’échanges sont possibles (API, Pub/sub, ESB et ETL).
Le pattern technique a été validé, et ce travail réalisé permet d’aboutir à une vraie cohérence technologique. Cette cohérence technique (en particulier sur la couche Upper) est un enjeu majeur pour l’exploitabilité de ces solutions en 24x7.
Le concept de l’inversion de dépendance
Le risque potentiel du Middle Office est qu’il devienne très complexe car devant s’adapter à l’ensemble des fronts et des backs. En devant interagir avec une multitude d’applications (front & back), il y a un vrai risque que ce système devienne une véritable « usine à gaz », difficile à modifier, ce qui serait en contradiction totale avec son ambition initiale.Avec d’éviter cet écueil, nous avons introduit le concept « d’inversion de dépendance ». Le principe est que ce sont les applications du Middle Office qui imposent les formats d’échanges. Charge aux applications utilisant ses services de d’adapter à lui. Pour les fronts, ce sont des couches de type « back-for-front » qui réalisent cette tâche. Pour les applications back (souvent des progiciels), l’implémentation de ce concept est parfois plus délicate et parfois plus coûteuse à court-terme, mais reste une cible prioritaire pour conserver un Middle agile et performant.