Quand on conçoit un système d’information, en général, ou pour le e-commerce, on définit des modules, et des liens entre les modules.

Quand je travaille sur ces sujets, je dis souvent que ces liens peuvent représenter un enjeux au moins aussi important que les modules eux même.
Quelques exemples de connexion de modules :

Brancher la brique e-commerce avec un module CRM Brancher la brique e-commerce avec un ERP Brancher la brique e-commerce avec le logiciel de comptabilité Dans le cas d’un front office séparé du back office, synchroniser le front office et le back office …

Donc, comment connecter les modules ?
En fait, la plupart des modules sont structurés à partir d’un système de gestion de bases de données.

Il peut être tentant de réaliser le branchement directement de base de données à base de données.

C’est d’autant plus tentant qu’il existe des solutions pour synchroniser les bases de données (solutions type ETL).

L’avantage de cette solution est qu’elle est relativement rapide à mettre en oeuvre, et qu’elle n’est pas « prise de tête » : on se branche, on va chercher l’info et zou, c’est bon.

L’autre solution, c’est de développer une vrai couche de connexion, basé sur des web services.

Evidemment, développer une telle couche métier à un coût. Quel est donc l’intérêt alors de faire comme ça ?

Les avantages sont multiples :
Cela permet de définir une vrai couche abstraite, orientée métier. Cette couche doit être indépendante des deux modules en fait. Elle permet donc d’ajouter de la flexibilité, de l’évolutivité dans le système.
On peut en particulier ajouter des traitements sur les données, et « servir » des données bien plus synthétiques que ce que propose les bases de données natives.

Remarque : une couche métier peut très bien communiquer vers plusieurs modules pour générer une donnée de synthèse (exemple : aller chercher, pour une info client, des éléments sur la brique e-commerce et dans un système