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 ;).
