Comme vous pouvez le voir dans ma biographie ci-dessous, cela fait 20 ans que je travaille dans le mondes des EAIs/ESBs. Et ca fait 20 ans que je vois des « Request for Proposal», « Request for Information », « Request for Quotation », des appels d’offres, … avec des grandes grilles pleines de critères TECHNIQUES auxquels doit répondre l’ESB proposé. Ces critères techniques sont des protocoles, des spécifications de sécurité, des listes de connecteurs ou de composants, …
J’en ai marre de ces grilles qui n’ont aucun sens et qui sont une fausse expression de besoin. En tant qu’experts dans ce domaine, on ce doute bien du pourquoi du besoin d’un ESB, mais jamais il n’est vraiment exprimé, et donc jamais vraiment évalué pour faire la sélection. Plutôt que ces listes, j’aimerai voir juste ces quelques points :
- agilité :
- respect total des principes de la SOA,
- agilité de déploiement, déploiement à chaud,
- existence :
- de connecteurs supportant les principaux protocoles : SOAP, REST, fichiers, …
- de moteur d’exécution standard : POJO, EIP, BPMN, …
- d’un kit de développement de connecteur,
- administration, monitoring, exploitation,
- engagement sur la pérennité de la solution,
- …
Je vous propose par cette série d’articles de vous faire découvrir ma vision de ce que doit être le monde mystérieux et plein d’ambiguïté des ESBs. J’espère qu’après lecture votre regard changera et que si vous avez besoin d’un ESB, la liste de vos critères sera différente ?
Je sais bien que certains diront que je suis un « pro » Petals ESB, mais cette suite d’articles se veut être impartiale et non partisane. Et j’espère l’être !
Bonne lecture !
Les articles de la série
Voici les différents thèmes que j’aborderai dans les prochains jours et semaines au travers de nouveaux articles sur ce blog. Pour ne pas rater leurs pubications, n’hésitez pas à nous suivre sur Twiter: @ChrisDENEUX, @Linagora ou @petalsesb.
Pour accèder au contenu de l’article, cliquez simplement sur les liens.
- Un peu d’histoire
- L’approche orientée « services »
- Deux natures d’ESB, mais des points communs
- Java Business Integration
- ESB et projet informatique
- Au delà de l’ESB: l’urbanisation de SI et le BPM
- ESB, backbone du SI de l’entreprise
- Agilité de l’ESB
- ESB et sécurité
- SOA et WOA/ROA
- ESB et MDM
- Exploitation des ESBs
- A propos des performances des ESBs
- Gouvernance! Un ESB ça se gère
Ma biographie
Cela va faire 20 ans que j’ai commencé ma carrière dans le monde de l’IT et plus particulièrement dans l’intégration. J’ai fait mes débuts chez Capgemini de 1997 à 2010, où j’y ai développé une expertise dans l’architecture des systèmes d’information et plus spécifiquement les technologies EAI, ESB et SOA. Les logiciels de WebMethods, Tibco, BEA, Oracle étaient alors mes jouets de tous les jours.
Fasciné et convaincu par les logiciels libres alors que j’étais encore à l’école, et suite à une mission de mise en œuvre de Petals ESB où j’en suis devenu contributeur, c’est tout naturellement que je rejoins EBM WebSourcing en 2010 en tant que directeur technique, architecte d’entreprise et technical leader du produit « Petals ESB ». Dans ce milieu libre et innovant, j’ai pu mettre en œuvre ma vision de la SOA, aussi bien en tant que fonctionnalités de l’ESB Petals que dans la définition des architectures de système d’information de nos clients de l’époque.
En 2012, EBM WebSourcing a été reprise par Linagora. Et je continue dans la même voie : « la belle SOA ». En parallèle, je commence à développer une vision d’intégration du SI dans le monde « cloud », en particulier tout ce qui concerne le déploiement. L’idée principale est : « c’est bien beau d’avoir un système d’information agile, ce serait tellement mieux qu’il puisse s’auto-adapter, au niveau de son déploiement, à la charge demandée, et ceci de manière automatique et économique ». Le résultat est la « cloudification » de Petals, en collaboration avec la nouvelle équipe Linagora responsable du produit Roboconf, solution de déploiement élastique multi-IaaS.
