Le concept d'Enterprise Service Bus (ESB) est un des plus obscurs pour les non-initiés.

Une application, OK, ça tout le monde c'est ce que c'est. Connecter deux applications ? Ça fait longtemps qu'on sait faire par traitement batch nocturne !

C'est quoi l'intérêt de l'ESB alors ?

Push vs Pull

Pour moi, l'image qui illustre le mieux le concept d'ESB c'est la différence entre le mail et twitter.

Avec le mail on était en mode push. L'information est poussée aux destinataires. C'est l'expéditeur qui va décider qui est intéressé par son message.

A l'inverse avec twitter on est en mode pull. L'utilisateur diffuse un message, ceux qui sont susceptibles d'être intéressé s'abonnent aux messages.

Un bus, c'est du twitter : l'application diffuse son message, les autres applications intéressées par ce message s'abonnent au flux.

Orchestration

Bien sur, ce serait trop réducteur de limiter l'ESB au mode pull. L'ESB est à voir comme un chef d'orchestre qui va mettre en musique les différentes applications.

Il va par ailleurs être en mesure de réaliser certains mapping lorsqu'il est nécessaire de convertir un fichier csv en xml par exemple.

Orienté Services

Ce qui est intéressant c'est la philosophie d'architecture logiciel apporté par l'ESB.

En 10 ans on est passé d'applications monolithiques à du Service Oriented Application (SOA).

Les applications se sont spécialisées dans le traitement d'une donnée en particulier, dont elles sont le référent et communiquent via l'ESB pour récupérer les autres informations dont elles ont besoin. On évite ainsi les doubles saisies.

Temps réel

L'ESB a apporté également un élément fondamental dans l'amélioration du Système d'Information : le temps réel.

Les applications communiquent des bouts d'information dès qu'elle est disponible plutôt que d'attendre le soir et de traiter une journée de travail. On améliore ainsi la réactivité des applications et donc des métiers de l'entreprise.

Exemples

A la Sogé, nous utilisions MS Bitztalk pour notre projet de dotNet.

Dans le groupe AF/KL, c'est l'ESB de Tibco qui est en place.

Talend, version opensource de l'ESB est très répandu également dans les entreprises.

MQ Series, qui est utilisé à peu près partout peut être considéré comme l'ancêtre de l'ESB.

Si il y a une chose que j'ai apprise en tant que créateur d'entreprise et si il y a un conseil que je peux donner à toute personne voulant se lancer dans l’aventure, c'est bien cette doctrine : FAIL FAST

L’échec de Manolosanctis, c’est de ne pas avoir su faire notre pivot vers l’autoédition assez tôt. Certes c’est plus facile à dire qu’à faire, et dans l’édition les temps sont très longs (1 an entre la signature d’un contrat et les premiers retours sur les ventes).

Pour avoir eu la chance de discuter avec un des co-fondateurs de Criteo, LA startup Française du moment récemment introduise au NASDAQ, je peux vous confirmer qu’il en a été de même pour eux. Avec un business initial centré sur la recommandation de produits culturels, ils se sont rapidement aperçus que le marché de la publicité était plus porteur et qu’ils disposaient d’une technologie assez novatrice dans ce milieu qui leur permettait de lancer le concept de retargeting.

Be the right man, in the right place, at the right moment. Les facteurs de succès sont trop aléatoires pour être prédictibles. Ce qu’on peut faire au mieux, c’est de se tenir prêt et de sauter sur l’occasion lorsqu’elle se présente. Bien sûr il faut savoir forcer son destin, provoquer sa chance, mais ce n’est pas toujours suffisant.

Pour réussir, il faut avoir un time to market très court et une capacité à développer un prototype fonctionnel sans dépenser trop d’argent. Ce n’est que lorsqu’on a pu démontrer le proof of concept que l’on peut réellement investir pour passer au stade industriel et développer son entreprise. Ceci étant dit, ce discours a encore du mal à passer dans la culture française. Contrairement à la culture anglo-saxonne, l’échec est très mal perçu en France. Nous avons ce culte de l’excellence, avec des élites issues des meilleures écoles qui auront pensé dès le départ la meilleure solution. Mais nous avons du mal à reconnaître nos échecs. Fail Fast, ça veut assez dire ne pas s’entêter, couper net lorsque ce n’est pas viable. Combien de fois sommes-nous confrontés à l’évidence qu’une solution ne fonctionnera pas, mais où personne n’osera avouer l’échec ?

Une des Best-Practices qui revient le plus souvent sur nos projets en ce moment c'est "System is leading". C'est à dire que c'est au métier de s'adapter à l'outil et non l'inverse.

C'est une Guideline doublement intéressante, à la fois pour le SI, mais également pour le métier.

Système

L'implementation d'un progiciel est souvent complexe lorsqu'il s'agit d'adapter son outil à son métier. Le développement custom est souvent cher et rend le produit très peu maintenable. À chaque nouvelle version du progiciel, il faudra refaire des tests de non régressions complets, voir redévelopper une partie des fonctions spécifiques.

Sans compter que tordre l'outil pour faire rentrer le process au chausse pied cause généralement des problèmes de performance.

Métier

La mise en place d'une nouvelle application est souvent un moyen d'imposer une nouvelle façon de travailler. Ce change management par les outils peut être désastreux si le management n'est pas impliqué dans son implémentation.

Néanmois la mise en place d'un progiciel peu être une bonne opportunité pour s'aligner sur les standards de l'industrie. C'est d'ailleurs là que réside le vrai avantage d'un progiciel. Ne pas s'éloigner de l'outil permet de bénéficier de process simples et efficaces. Les utilisateurs ont souvent tendance à complexifier inutilement les outils.

Pour autant il est important de bien mener sa préétude et de bien s'assurer en amont que le progiciel sélectionné correspond bien aux besoins du métier. D'expérience, si il y a trop de customisation sur un progiciel, c'est que la phase amont a mal identifié le besoin.

J’assiste actuellement à une conférence de Sabre Airline Solution à Vancouver

Un des thèmes abordé est l'Innovation.

Ce qui est intéressant, c'est que les intervenants sont tous unanimes sur le fait que l'innovation n'a rien à voir avec une invention. L'innovation c'est trouver un compromis entre les hommes, les process et la technologie.

En d'autres termes, l'innovation est un processus qui permet de tirer le meilleur parti d'une technologie existante en l'intégrant dans une organisation.

People

Sans grosse surprise, le Change Management tient une part importante dans ce process. La citation suivante résume bien la situation:

If you want something new, you have to stop doing something old

-- Peter F. Drucker

Souvent l'innovation est freinée par les résistances internes des équipes au changement. Innover c'est être capable de remettre en cause notre travail quotidien.

Process

Un des autres piliers de l'innovation est le process. Une solution informatique reste un Outil, aussi perfectionné soit-il. Un outil est la modélisation la moins imparfaite possible d'un processus métier. Mais l'outil est complètement inefficace s’il n'est pas utilisé correctement. Apporter de l'innovation à son entreprise c'est être capable de bien appréhender les process métier existant et de repérer où injecter de la technologie de façon pertinente.

Technology

Un des thèmes fondamental abordé est la connectivité. En particulier dans l'aérien ou il s'agir de coordonner des pilotes dans un cockpit, des clients à l'aéroport et les opérationnels qui sont au siège de l’entreprise.

La connectivité c'est principalement deux choses:

• La mobilité, à savoir le fait d'intégrer les nouvelles technologies telles que l'iPhone et les tablettes dans le parc applicatif de l'entreprise.
• L'échange d'informations en temps réel, en particulier l'interconnexion des applications.

Cela fait maintenant 9 ans que je défends le concept d'Ubiquitous Computing. La synchronisation de l'information est un processus clé qui prendra de plus en plus d'importance dans le futur. On le constate avec des applications comme Evernote ou Google Drive qui ne proposent pas de réelles nouvelles fonctionnalités, mais qui sont vraiment designées pour permettre la synchronisation.

Lorsqu'on regarde les fonctionnalités proposées par Facebook, Google Now ou Foursquare, on constate que le concept d'Ubiquitous Computing a déjà été dépassé. Il ne s'agit plus uniquement de synchroniser les données, mais aussi de proposer des informations contextuelles à l'expérience utilisateur en prenant compte de la localisation de l'utilisateur, des intérêts de ses amis, de l'agenda de l'utilisateur, etc. Toutes ces fonctionnalités permettent de filtrer l'information pour la recentrer sur l'information la plus pertinente dans le contexte d'utilisation.

Aujourd'hui le plus gros challenge d'un DSI est d'apporter la bonne information à la bonne personne, au bon moment. Toutes les informations sont aujourd'hui disponibles. Au contraire, nous sommes submergés par les informations. Il est donc primordial d'apporter une information pertinente, "prédigérée" et directement exploitable.

La DSI se doit de tirer parti de ces fonctionnalités pour développer les applications métier de demain.

Nous menons actuellement une étude pour améliorer notre application principale. Aujourd'hui l'outil n'est pas jugé satisfaisant par les utilisateurs et pourtant ils se déclarent satisfait de la couverture fonctionnelle. Les discussions ont souvent tendance à tourner autour des fonctionnalités de l'outil, mais ce n'est pas un critère suffisant pour juger de sa qualité.

Pour cela, nous avons découpé le projets en 3 axes:

• fonctionnalités
• qualité
• performance

Pour chacun de ces axes, nous avons déterminé des KPI qui nous permettrons de suivre les améliorations attendues.

Fonctionnalités

Nous allons rédiger des spécifications pour les fonctionnalités clés qui sont aujourd'hui manquantes. L'indicateur de suivi est ici assez simple car il suffit de faire le ratio nbre d'item développés/nbre d'item total.

Qualité

La qualité du logiciel peut se mesurer au nombre de bugs reportés par les utilisateurs. Les bugs sont catégorisés en 3 niveaux de SLA:

• SLA 1: Bug bloquant, à corriger "à chaud" au plus vite. Délai de résolution sous 4h.
• SLA 2: Bug sévère, mais non bloquant. A corriger sous une semaine suivant un process d'Emergency Release
• SLA 3: Bug mineur non bloquant. Ajouté à la liste des bugs et corrigé lors d'un release standard.

L'indicateur ici est le nombre de bug SLA 1 et SLA 2 par mois.

Performance

En plus des tests de non régression, nous allons déterminer des scénarii type couvrant les fonctionnalités clés de l'outil. A chaque scénario nous allons attribuer un délai maximum de réalisation au dessus duquel l'application sera jugée non conforme. L'idéal est de jouer 5 fois le scénario, d'enlever la valeur la plus haute et la plus basse et de faire une moyenne sur les 3 médianes.