Archives par mot-clé : SOA

Des couches avec des API pour avoir une vie plus douce

ça c’est du titre, non ? 😉

Un système d’information e-commerce pour un site ayant de gros volumes gère des sujets très variés : relation client, site e-commerce, logistique, processus de commande, gestion des stocks, comptabilité…

Il n’est pas question de tout mettre dans un seul paquet. ça, ça marche en mode « garage », quand on démarre.

On va donc avoir plusieurs modules, chacun chargé de géré en ensemble « cohérent » de fonctions.

La bonne approche consiste à définir des API métiers pour échanger les informations entre les modules.
Il faut bien voir qu’une API, c’est bien plus riche qu’une base de données.
Une API, c’est un ensemble de fonctions, qui, ensembles, donne une vue sur un module donné.

L’interface API ne doit pas être un mapping direct de la base de données (sinon, ça ne sert à rien, autant se brancher sur la base).
Il faut faire un vrai travail « métier » pour définir la vue… métier justement.

Il faut faire des ateliers, avec quelques interlocuteurs internes métiers, pour définir cette vue (pas trop de monde non plus, sinon, on rentre en « réunionite »)

De mon expérience, il est important de définir cette vue non pas à partir de ce que fait le programme, mais à partir d’une vue idéale sur un sujet donné.

Si, par exemple, on cherche a définir la vue Client, on va se poser toutes les questions sur ce qu’est un client, vu du SAV, du service avant vente, vu comme un client pour un magasin ou un client vu du site e-commerce, vu de l’équipe chargé des programmes de fidélité, …

Ensuite, bien sûr, il faut faire le mapping entre l’API et ce qu’on a « en magasin ». On peut bien sûr avoir des cas ou on demande plus que ce qu’on peut faire. L’API n’est pas forcément réalisable a court terme, avec les modules actuels.

Je pense que c’est normal d’être dans cette situation, et c’est même relativement sain. Cela donne une vision « moyen terme » de ce qu’il faut construire.

L’API doit quand même être utilisable rapidement, et pour ça, on se débrouille : certaines fonctions ne sont pas implémentées (« not yet implemented »).

Mais la plupart du temps, on trouve un moyen pour collecter les données, quitte à aller chercher les informations sources dans plusieurs modules.

Voilà, c’est tout pour aujourd’hui. Il est tard (et oui, les billets sont écrit le soir et programmés, merci WordPress 😉 ). Mais il y aura bien sûr d’autres billets sur ce thème, parce que c’est un sujet majeur, sur lequel il y a beaucoup à faire de mon point de vue 😉

Je me rends compte que le billet ne répond pas vraiment au titre : on ne voit pas vraiment pourquoi on va avoir une vie plus douce ;). ça sera donc l’occasion de faire une suite !

Système d’information – Démêler le « plat de nouille »

Dès qu’une boite a une certaine taille, qu’elle a plusieurs canaux de distributions, un « historique » informatique, nécessairement, le système d’information vieilli, devient de plus en plus compliqué et de plus en plus cher à maintenir et à faire évoluer.

Ce système est pratiquement toujours composé de briques différentes, ERP, Compta, Caisse, Logistique, … et e-commerce 😉

Les connections entre les systèmes se sont faites au fil du temps.

Assez rapidement, on se retrouve avec plusieurs problèmes :

  • Les briques, individuellement, ont vieilli
  • L’interconnection du système est devenu anarchique, n’importe quel brique effectuant des échanges avec n’importe quel autre composant.

Comment faire évoluer un tel système ?

Comment sortir de cette logique infernale ?

On peut se dire : on va remplacer tel brique, par une autre plus moderne. Au fil du temps, on pourra remplacer toutes les briques et avoir un système « comme neuf ».

Cela ne va pas vraiment régler le problème, et le cout de cette greffe va être très élevé.

Et on sait bien que tout remettre à plat, c’est d’une part tellement cher qu’on ne le fera jamais, et d’autre part, même si on avait le budget, ça ne serait un pas une bonne idée, car le projet serait trop gros, avec tous les risques associés à ce type de « big bang ».

Alors, que faire docteur ?

Mon avis est que la seule solution raisonnable est de passer par une approche SOA.

Il faut, déjà, mettre fin aux échanges anarchiques entre les différentes briques.

Il faut donc définir des couches d’échanges, des API, qui déinissent des objets et méthodes métiers.

Les briques ne doivent dialoguer qu’au travers ces nouveaux composants.

Ces couchent doivent être bien faites : il s’agit de modéliser, le plus proprement possible, les objets métiers.

Exemple classique : les informations sur un client.

Dans bien des boites, la logique « full CRM » n’est pas en place (c’est un « graal », en ce sens que ce n’est jamais complètement possible de toute façon), et les infos sur le client sont en fait réparties dans différentes briques : e-commerce, ERP, solution d’emailing, application de call center…

Dans notre approche, on défini une couche abstraite permettant de modéliser le client, et toutes les informations associées à ce client.

En tant qu’utilisateur de cette couche, j’aurais une vision propre, un référentiel unique, cohérent

En fait, c’est cette couche qui doit « se débrouiller » avec l’existant, et aller piocher les infos là ou elles sont

Jusqu’au jour ou l’entreprise décidera de fair évoluer la couche CRM, qui pourra alors se brancher simplement « sous » cette couche.

L’avantage de l’approche, c’est qu’une fois une telle couche en place, les briques utilisatrices sont réellement indépendantes des couches sous jacentes, et les problèmes de modélisations « du dessous » ne remontent plus.

Toute la difficulté de l’approche est qu’il faut définir des objet avec le bon niveau d’abstraction, « comme si » les autres éléments étaient nickel.

Les difficultés de cette approche, c’est qu’elle n’est pas immédiatement rentable : on a un cout supplémentaire, pour définir, développer et utiliser cette couche, ce qui est bien plus long que d’aller chercher l’information directement à sa source.

C’est en fait toujours le cas avec les approches ou l’on recherche la qualité.

Prenons un simple développement web, pour une application quelconque. C’est bien plus rapide de faire un petit développement, sans aucune approche qualité, un petit programme qui pourra allègrement mélanger la couche présentation, les logiques métiers et la couche de données. bien plus rapide à développer (je dirais un facteur 3, pour fixer les idées). Le surcout vien ensuite : le petit programme est rapidement impossible à maintenir.

A mon sens, deux cas de figures : soit les responsables sont « convaincus », et on va pouvoir y aller, vendre cette approche.

Soit ce n’est pas le cas, les responsables n’ont pas de culture SOA. Dans ce cas, je pense qu’on peut quand même avancer, mais par étapes, et sans mettre en avant ce travail. Simplement, à chaque demande d’évolution, on prend un peu de temps pour définir et mettre en oeuvre une couche d’échange.

Bien sûr, le plus simple, c’est quand cette approche est sponsorisée par les chefs 😉

Un excellent article sur le sujet, par un gars qui a bossé chez Amazon, Google ;).