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 CRM).
Mettre en place une telle architecture demande donc un vrai investissement, fonctionnel et technique.
Mais c’est à mon sens la seule solution pour avoir un système d’information réellement évolutif.
Si on y réfléchi bien, ne pas faire ce travail de couche métier, cela revient à lier fortement les deux modules, à diffuser des éléments d’implémentation, d’un module vers l’autre.
Avec le temps, les deux modules vont être de plus en plus imbriqués les uns dans les autres, et toute évolution deviendra vite un cauchemard : comment faire une monté de version d’un module, surtout si la nouvelle version impacte la base de données ? …
En fait, si on y réfléchi, c’est la seule solution pour faire une archi un minimum évolutive et stable.
Hello François,
je souhaite soumettre un point de vue différent :
N’y a t’il pas des solutions existantes pour cela?
Chaque « brique » dont tu parles ayant une façon de compter différente (cookie, session, visite), Ne penses tu pas que la question de la validité, du modèle de données, d’indicateurs calculés sur des données hétérogènes ne va pas à un moment bloquer toute intégration de ces données ou au moins leur analyse?
Je crois à tord ou à raison que c’est le job d’un outil d’analyse, site-centric ou customer centric non?: un comptage uniforme de l’ensemble des KPIs qui va servir de référence aux une fois les informations de différentes sources croisées avec des dimensions uniformes.
Bizarrement le sujet de faire du business « number-driven » est rarement abordé sur ton blog…
Ne penses tu pas qu’une société qui a déja le SI cité ci-dessous:
« 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 »
…
n’a pas les moyens et surtout une fondation solide pour tisser ces liens?
Quand tu écris : »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. » le penses tu vraiment ?
Ce sujet est aujourd’hui l’enjeu principal des ecommerçants, pour mesurer leur performance, piloter leur acquisition et surtout gérer les couts…
Je ne rencontre pas ton point de vue sur le marché aujourd’hui, les sociétés qui ont essayé de développer en interne ce type de solution miracle, se sont toutes magistralement plantées, avec des répercutions parfois sur plusieurs années, voire la survie de la boite en question (je parle de multinationales)
« Evidemment, développer une telle couche métier à un coût. Quel est donc l’intérêt alors de faire comme ça ? »
L’évolution du marché dans lequel nous travaillons demande de plus en plus d’expertise dans des secteurs de plus en plus pointus, les anglo-saxons appellent cela le splinternet.
Quel est l’intérêt de bruler son budget ( je ne parle pas de l’impact sur les ressources qui ont autre chose à faire) à développer une couche qui sera obsolète dans 12/24/36 mois?
il y aurait beaucoup à discuter sur ce sujet, dont l’agilité, le time-to-market, la pertinence en termes du secteur concerné…
A+
Loic
@Loic> Hello 🙂
« N’y a t’il pas des solutions existantes pour cela? »
A quoi penses tu précisément ?
@ François AND @Loic « My personnal point of view » comme dirait un pot à moi, c’est que vous avez tout 2 raison et en même temps pas completement.
oui les aspects time 2 market et team burning sont importants d’autant qu’en général, nous parlons ici de eCommerce, les décideurs ont dans la tête des cycles courts de mise en ligne de la boutique. Le web c’est bien connu (theme largement évoqué ici même par François) c’est facile et pas cher – N’est ce pas –
Par contre la connection base à base devient vite « plat de nouilles » car évidemment le CRM doit aussi être connecté à la gestion qui doit être connecté à la gestion du temps et des congés, bref … nous connaissons tous la problématique et aussi les approches par des boites grosses ou moyennes qui vont de l’échange de fichiers à plat à l’intégration SOA la plus noble.
Malheureusement pas de solution miracle, celle dont parle Loic, peut conceptuellement être attirante, malheureusement le modèle qui repose sur de la BA est difficilement pris en main par des opérationnels qui finissent par requêter le systeme sur des samples stockés dans un fichier et donc n’exploitent pas la puissance – car trop complexe – de la solution. L’approche de François est aussi celle que je recommende mais elle demande d’avoir une écoute favorable au départ car malheureusement, passé le concept de départ sur la donnée la ou elle est au moment ou on en a besoin, on tombe vite dans de la modélisation de processus d’entreprise puis la mise en place de middlware qui n’ont rien de « User friendly » et ca c’est plutot techcos pas trop business.
Par contre oui les techno courrent plus vite que les budgets et donc les projets courrent apres les budgets. Donc une justification sur la base de « vous verrez dans 10 ans vous me direz merci de mon approche en couche » je sais pas si qql achète encore ca aujourd’hui.
Comme toujours la vérité est certainement entre les 2 et probablement devra être pragmatique, mettre en place une approche par services quand c’est possible et certainement pour une couverture partielle du scope, mettre en place une intégration de données intelligente lors de la refonte du systeme decisionnel et la aussi certainement pas sur tous les entrepots de data de la maison, bref on fait de bric et de broc à défaut d’un big bang.
Bon c’est vrai aussi qu’en matiere de SSII le « Tout casser pour refaire propre » est passé de mode et soyons honnête a couté cher pour des résultats « moyens » (en dehors des résultats financiers des dites SSII) of course !