|
Interviews |
|
Nick Earle
|
CEO
|
StreamServe
|
"Nous
rendons possible l'intégration many-to-many" |
|
Né en 1995 en Suède, StreamServe
compte aujourd'hui plus de 3 000 clients, moyens
ou grands comptes, de ses solutions d'intégration
évoluées. Ni complètement ETL, ni
broker de messages de type EAI, celles-ci constituent
un genre nouveau que l'éditeur qualifie lui-même
de couche d'échange de services (Exchange Service
Layer). Une opportunité nouvelle en matière
d'interopérabilité que d'aucuns parmi les
analystes voient prendre une place importante dans l'avenir.
Pour en savoir plus, nous nous sommes tournés vers
le grand patron de StreamServe, alias son CEO (Chief executive
officer ou pdg). Ancien de HP et de Ariba nommé
dans ses fonctions en septembre 2001, Nick Earle
répond à nos questions.
|
Propos recueillis par François Morel le 21
mars 2002
. |
JDNet
Solutions : A quoi correspond l'Exchange Services Layer
(la couche d'échange de services) dont vous dites
être l'acteur principal ?
Nick Earle :
Peut-être pourrais-je commencer par décrire
les problématiques métiers que nous résolvons.
Ce terme est issu d'un document d'AMR Research paru en
janvier. Leur rapport parle d'architectures multiples
et proprétaires, de systèmes ERP hétérogènes.
Or, il est rare de rencontrer un seul progiciel de gestion
intégré dans les grandes entreprises. Résultat,
celles-ci dépensent beaucoup d'argent pour les
connecter entre eux. Il faut savoir que le coût
de cette interconnexion représente de 25 à
30 % du budget que l'entreprise consacre aux technologies
de l'information. Et lorsqu'il s'agit de connectivité
externe avec les clients et les fournisseurs, le problème
est encore pire. Nous avons remarqué qu'en moyenne,
moins de 5 % des communications de données
entre les entreprise étaient électroniques.
Ce que nous voyons donc est que l'intégration de
type EAI ne marche ni dans l'entreprise, ni entre les
entreprises. C'est pourquoi nous avons voulu, en tant
qu'éditeur, créer une couche indépendante
qui supporte toutes les communications entre une application
avec ses modules, et le système d'informations
d'un fournisseur, par exemple. La seule solution est d'abandonner
les connexions point à point et de créer
une nouvelle couche d'abstraction. Il s'agit de permettre
à n'importe quelle application de dialoguer avec
n'importe quelle autre application, même au delà
des frontières de l'entreprise.
N'est-ce pas le propos des offres
ayant pour but de fournir une conversion des spécifications
standards décrites en XML de l'une à l'autre
?
Certains tentent d'introduire ces spécifications
XML dans des packages EAI, mais cela ne marche que si
chacun parle le même XML. D'une part, moins de 5 %
des entreprises sont "XML enabled" et beaucoup
utilisent encore les EDI (échanges de données
informatisés) l'e-mail et le fax. Il faut savoir
que pour plus de 90 % des entreprises, les échanges
se font au format papier. D'autre part, il existe plusieurs
centaines de spécifications XML. C'est pourquoi
notre position est différente. Elle est de dire
"nous ne nous occupons pas de savoir si vous communiquez
en XML, en EDI, en EDIFact, par fax, en HTML ou même
en SMS. Nous prenons tout ce que vous voulez et le transformons
en tout ce que vous voulez à l'intérieur
de notre couche de communication indépendante."
Comment vous proposez-vous d'aider
les entreprises à réduire leurs coûts
?
Prenons un simple problème de facturation dans
un compagnie manufacturière. Par exemple, un client
reçoit une facture par semaine. S'il y a 10 000 clients,
ce sont 10 000 factures qui sont envoyées
chaque semaine. Si vous les postez, vous devrez payer
deux dollars par personne, soit 20 000 dollars
par semaine. Si nous faisons le calcul à l'année,
cela revient à au moins un million de dollars rien
que dans le fait d'envoyer les factures. Le progiciel
SAP est livré avec plus de 470 états
différents, et seulement l'un d'eux correspond
aux factures. Nous proposons donc à nos clients
de réduire ce coût de façon significative
en optant pour le format de communication de leur choix.
Mais en même temps, n'oublions pas que c'est le
récepteur qui conduit la personnalisation, pas
l'émetteur.
Ce discours ressemble à
ceux de webMethods ou même Tibco. En quoi votre
solution est-elle différente des leurs ?
Ce que font webMethods, Tibco, etc. c'est de l'intégration
point à point. En ce qui nous concerne, nous fournissons
un hub (concentrateur) pour de l'intégration many-to-many.
Le point à point est cher, lent, et moins de 5 %
du monde peut être connecté. Si vous voulez
communiquer avec 10 000 fournisseurs, cela peut
supposer des centaines de milliers de connexions point
à point. Or, nous voulons que chacun puisse communiquer
avec n'importe qui.
Je peux vous fournir un exemple chez l'un de nos clients
en Europe, à savoir Posten, la poste suédoise.
Grâce à nous, ils peuvent envoyer un document
électronique de n'importe quel format vers n'importe
quel format, sans avoir besoin de savoir ce que veut le
récepteur. Leur métier fait qu'ils traitent
plus d'un milliard de documents par an. Du moins, c'est
le volume qui transite par notre système. Nous
sommes positionnés sur ce que AMR Research appelle
la "communication services layer", ce que les
analystes prédisent comme étant la prochaine
grande tendance en matière d'interopérabilité.
Et pour couronner le tout, nous sommes une entreprise
européenne.
Votre technologie n'est-elle pas
tout simplement un super-outil d'ETL (intégration
de données) qui extrait, transforme et injecte
des documents formatés dans des environnements
d'échanges b-to-b ?
En quelque sorte, oui. Certaines personnes parlent de
document trading exchange, c'est à dire une place
d'échanges pour les documents. Nous appelons cela
une couche de transformation, et c'est une couche indépendante
qui laisse le récepteur décider du format.
L'émetteur, de son côté, prend le
format qui lui convient.
Oui, mais peut-on parler d'ETL
b-to-b, hors des frontières de l'entreprise ?
La réponse est oui. Nous fournissons en même
temps une couche ETL externe à l'entreprise et
un hub ETL en interne. Par rapport à l'ETL, il
y a cependant une partie que nous ne faisons pas de la
même façon : l'extraction. Un outil ETL classique
n'extrait pas de multiples formats de communication comme
nous le faisons.
Cela signifie-t-il que vous développez
des web services particuliers ? Comment procédez-vous
d'un point de vue technologique ?
Actuellement, nos produits sont écrits en C++ et
nous sommes en pleine transition vers J2EE. Nos fonctionnalités
modulaires s'appuient sur des web services. D'autre part,
notre position est celle d'un facilitateur à l'égard
des web services applicatifs. Quand vous allez dans un
catalogue et que vous voulez commander quelque chose sur
le Net, le résultat tient dans un échange
de documents d'affaires. Dans ce cadre, nous allons être
le service qui transfère le document entre le demandeur
et le fournisseur. Chez StreamServe, nous pouvons aider
les différents éditeurs d'ERP à participer
aux mêmes affaires. Dans un monde de web services,
l'idée est de passer par un répertoire UDDI.
Et là, pas besoin d'intégration point à
point. Nous pensons être en mesure de fournir la
technologie clef qui rende possible les traitements de
documents à travers ce répertoire. Or, il
faut savoir que le nombre de documents va s'accroître.
Soit. Mais pour vous connecter
aux ERP, vous avez toujours besoin de connecteurs spécifiques
?
Notre solution est livrée avec un choix de connecteurs,
mais il ne s'agit pas d'intégration transactionnelle
comme le permet l'EAI. Nous avons un choix de 22 connecteurs
vers du SAP, Oracle, Siebel, J.D.Edwards, etc. Nous pouvons
aussi écrire des connecteurs spécifiques
pour les besoins de nos clients qui sont sur des systèmes
centraux particuliers.
Il faut bien comprendre une chose. Vous pouvez changer
votre application sans changer StreamServe. Par exemple,
si vous passez à la version supérieure de
SAP, il n'est pas nécessaire de changer le connecteur.
Quand SAP introduit une nouvelle version d'un module,
il effectue des changements dans la logique métier.
Si vous pratiquez une intégration point à
point un peu profonde, vous allez rencontrer des problèmes.
Mais nous ne sommes pas situés au niveau de la
couche d'enregistrement. Certes vous pouvez changer SAP,
mais une facture reste une facture, et son format de sortie
ne change pas.
D'accord. Mais qu'en est-il des
centaines de spécifications XML que vous évoquiez
au début de l'entretien ? Faut-il que vous les
supportiez d'avance ?
Il n'y a aucun problème concernant le format de
XML, car nous importons la DTD (Document definition type)
du destinataire pour nous conformer à l'enveloppe
de présentation. Et en entrée, nous importons
la DTD de la même manière pour nous conformer
au système de balises. Là aussi il n'y a
aucun problème à partir du moment où
nous savons interpréter la DTD. Le gros avantage
est que la mise en oeuvre est très courte par rapport
à une solution purement EAI. Par ailleurs, nous
avons intégré un moteur EDI dans StreamServe.
A quelles évolutions faut-il
s'attendre de la part de StreamServe ?
Nous avons trois grandes orientations prévues concernant
notre offre. La première est d'intégrer
StreamServe comme un outil dans des offres de fournisseurs
d'applications tiers. Nous sommes déjà en
OEM dans les progiciels de Intentia, IFS, et Generix en
France. Notre deuxième orientation consiste à
adopter un modèle de vente directe auprès
des grands comptes. C'est pourquoi nous recrutons des
personnes capables de les servir et de leur venir en aide.
Enfin, nous avons déjà parlé un peu
des web services qui ouvrent vers de nouvelles catégories
de documents échangés, dans des contextes
comme le traitement des modes de paiement et la compensation
financière. Or ce sont 7 millions de transactions
quotidiennes qui vont transiter par notre place d'échanges
de documents. Nous avons déjà signé
avec Swift en Belgique pour nous occuper du traitement
des paiements en Europe.
|
Arrivé en septembre 2001 pour prendre les rênes
de StreamServe, Nick Earle a rejoint il y a 18 ans
Hewlett-Packard chez qui il a occupé des positions
telles que directeur marketing puis président des
activités Internet au niveau mondial. Ce "HP
radical E-vangelist" tel que l'avait surnommé
le magazine américain Fortune a notamment co-rédigé
et publié un ouvrage intitulé "From
Dot Com to Dot Profit". Au cours de l'été
2000, il quitte les rangs de HP et son continent d'adoption
pour retourner en Europe prendre la présidence
des opérations d'Ariba sur la zone EMEA. |
|
|
|
|
|