Quand on fait le schéma d’un système d’information (un système informatique pour gérer un site e-commerce par exemple), on fait souvent des schémas avec des blocs et des traits.
L’idée est simple : l’important, ce qui doit être étudié, ce sont les blocs.
Ils contiennent les fonctions qui doivent faire vivre le système, et apporter la valeur attendue.
On se retrouve à faire un beau « légo » avec des blocs super sympa, un CRM par ci, un ERP par là, un moteur e-commerce bien sûr…
Méfiez vous !
Tous les « urbanistes » de systèmes d’informations savent que dans la vrai vie, un vrai sujet de complexité se cache dans les traits du schéma.
Les raisons ?
Elles sont nombreuses :
Les différentes briques ainsi assemblées ne parlent pas nécessairement le même langage. Il va donc falloir définir des « traducteurs », pour que tout le monde se comprenne.
Qui dit « lien » dit en fait protocole d’échange. Il faut spécifier ce protocole, en détail ;
Ce protocole doit définir :
- Le support pour échanger les données (fichier FTP, Web Services, …) ;
- Le contenu des échanges (XML, CSV, …) ;
- Le modèle de données des échanges ;
- Le mode de synchronisation :
- Synchrone (le client fait une demande, et à la réponse en temps réel) ;
- Asynchrone, soit de manière évènementiel, soit sur intervalles de temps réguliers ;
- Le traitement des erreurs. Souvent oublié, alors que les raisons et les types d’erreurs sont nombreux (panne d’un des serveurs, bug, évolution d’un des systèmes non répercuté sur les autres, …
Tout cela est sympathique, mais ce n’est pas fini, il faut également penser évolutivité !
Cela veut dire que notre protocole d’échanges doit être capable d’évoluer, sans tout avoir à refaire.
Enfin, un tel système d’échange doit pouvoir s’administrer, se « monitorer ».
Bien sûr, pour un petit site, on doit faire simple,…
Mais « petit site deviendra grand » (c’est tout le mal que je lui souhaite 😉 ) et si on ne prend pas le temps de bien concevoir le nouveau système d’information…
C’est pourquoi dès qu’un site est suffisemment grand, je propose de mettre en place un véritale système d’échange, pour « remplacer les traits » par un module, bien identifié, dont la fonction est de faciliter tous les échanges entre les différentes briques du système d’information.
Le grand avantage de cette architecture, c’est qu’on factorise, on regroupe les différents besoins d’échanges au même endroit.
Enfin, il me semble raisonnable d’ajouter : c’est vraiment l’un des métiers d’Araok de vous accompagner dans ce type de réflexion…
Après 10 années de projet informatique pour le retail, après un certains nombre de remplacement de gestion commerciale, de solutions d’encaissement, de gestion de pilotage d’entrepôt, d’interfaçage avec des SI divers et variés (un client avait 5 gestions commerciales, 5!!, dont SAP), les « traits » du SI sont très souvent une des variables les plus … variable du projet, et quasiment toujours à la hausse (chiffrage 30 jours ? comptez 60 …)
C’est un poste universellement négligé, surtout par les commerciaux … et les patrons de produits chez les éditeurs, car c’est toujours à « l’autre » de s’adapter.
Alors face à ça, la méthode classique est effectivement de mettre en place un EAI. Ma
Flute ! Un clic trop vite. Je continue.
Alors face à ça, une méthode est effectivement de mettre en place un EAI. Ce n’est pas une composante du projet, c’est véritablement un projet à part entière
(Pour les lillois, il y a un atelier technique de découverte de TALEND STUDIO, EAI open source, le 19 mai 2009 de 14h00 à 17h00, inscription ici : http://www.surveymonkey.com/s.aspx?sm=iI3aM6m77dGL4zWwfZ1prw_3d_3d)
Face à ça, et cela fait déjà l’objet de pas mal de littérature, les éditeurs et les DSI des grandes entreprises entreprennent de plus en plus une refonte de leur SI avec une démarche SOA. Chaque composante du SI est mise en œuvre sous forme de services métiers, interopérable, réutilisable, et proposant à l’extérieur une interface clair et « officielle », dialoguant via XML. Exit les EAI, bonjour l’orchestration.
Par exemple, la brique « référencement » (ou catalogue centralisé) délivre les informations produits à l’entrepôt, à l’encaissement, au décisionnel … et au site marchand de ma même manière, et, cerise sur le gâteau, le service métier qui permet de manipuler un produit … est le même partout ! Il a été développe pour le référencement et réutilisé dans les autres briques du SI. L’information est unique, dans sa forme et dans son contenu.
Enfin, en théorie. Le pragmatisme reprend en effet le dessus, et, pour l’instant, la démarche SOA est plus un guide de bonne pratique qu’un réel objectif. Le moteur d’orchestration ne sont pas (à priori) très au point, ou exploitable facilement et une vision à 10 ans c’est bien, mais faut que ça marche dans 8 mois.
Alors hop! un bon EAI et tout le monde se parle.
@Wizeoo> Merci pour ces commentaires 😉
Oui, EAI… Je n’ai pas cité ce nom là parce que je pense que l’approche sur le papier est bien, mais qu’on trouve beaucoup d’usines à gaz derrière. Je reste très méfiant donc sur les solutions du marché.
Mais c’est bien l’idée, on est d’accord !
François