Le document traite de l'intégration des fonctions de qualité des données dans les architectures orientées services (SOA), mettant en avant l'évolution technique et les nouvelles exigences engendrées par ces architectures. Il souligne l'importance de protocoles standard comme SOAP pour garantir l'interopérabilité entre services, tout en présentant des cas d'utilisation concrets où la qualité des données est essentielle pour le bon fonctionnement des processus métier. Enfin, le papier évoque également des alternatives aux services SOAP, telles que les services web RESTful, qui offrent plus de flexibilité pour l'intégration dans des applications modernes.

1. WHITE PAPER: SOA
WHITE PAPER /
Data Quality meets SOA –
la qualité des données mise au
service des processus métier
Les fonctions de qualité des données
étaient déjà mises à disposition comme
services dans les environnements Unix,
Windows et Linux, bien avant que les
analystes de Gartner aient inventé le
concept de la SOA. Le développement
de cette architecture répondait essentiel-
lement à des raisons d’ordre technique.
L’implémentation des architectures orien-
tées services impose par ailleurs de nou-
velles exigences aux services de qualité
des données à mesure qu’augmentent les
possibilités et la valeur ajoutée apporté-
es par ces architectures.
__________________________
Tous les noms d’entreprises, de produits et les logos mentionnés dans cette publication
sont des noms commerciaux et/ou des marques déposées des entreprises respectives.
Page 1

2. WHITE PAPER: SOA
Point de départ :
les services de qualité des données
Pour mieux appréhender l’importance des architectures orientées services dans
la mise à disposition et l’utilisation des fonctions de qualité des données, il
convient d’abord de jeter un coup d’œil sur les fonctions typiques de qualité
des données.
APPLICATION A: Une application classique est, par exemple, la validation d’une adresse postale en utili-
sant des données de référence comportant les noms de rues et de localités ainsi que les dépendances
des codes postaux des villes, des rues et des numéros des maisons. Contrairement au simple accès à
la base de données, le système doit dans ce cas trouver l’adresse correcte même si les données saisies
sont incomplètes ou contiennent des erreurs d’audition ou de frappe. Le but étant d’atteindre une haute
exactitude des résultats pour corriger automatiquement – autant que possible – les adresses erronées.
APPLICATION B: Une autre application est la recherche de doublons dans le stock de données. Dans ce
cas aussi, l’objectif est d’assurer une identification sûre et rapide même si les données saisies – objet
métier, partenaire commercial, produit ou opportunité de vente – sont incomplètes, divergentes ou erro-
nées. Cela permet, d’un côté, d’augmenter la productivité de l’utilisateur en simplifiant la recherche et,
de l’autre, d’éviter la création de doublons, c’est-à-dire la présence d’enregistrements doubles se rap-
portant au même objet dans le monde réel. Ainsi, on obtient une représentation cohérente, complète et
univoque des objets réels dans la base de données.
Un objectif important dans le cadre de l’optimisation Outre le temps de réponse, la possibilité d’intégrer
de la qualité des données est d’éviter, dès le les services de qualité des données dans divers
départ, l’enregistrement de données incomplètes environnements informatiques revêt également une
ou erronées dans la base de données. Les anoma- importance primordiale. Pour atteindre cet objectif,
lies éventuelles doivent être détectées au moment il est indispensable de découpler les services de
de la saisie des données, puis éliminées auto- qualité de données des consommateurs du service
matiquement ou notifiées à l’utilisateur pour qu’il et d’utiliser un protocole client/serveur. C’est pour
procède lui-même à leur élimination. Grâce à des cette raison que cette fonctionnalité a été dévelop-
index de recherche spécialisés, la recherche dans pée et utilisée dans le domaine de la qualité des
une base de données contenant entre 1 000 000 données, du moins pour les applications exigean-
et 100 000 000 enregistrements ne dure qu’une tes, avant même que les architectures orientées ser-
fraction de seconde, même en cas d’utilisation vices ne furent inventées. De cette manière, il a été
d’orthographes différentes. De tels temps de répon- possible à la fois de répondre aux hautes exigences
se requièrent toutefois une mise en cache intelligen- en matière de temps de réponse et d’assurer la mise
te des index. Une solution efficace pour atteindre à disposition d’une série de fonctionnalités pour les
cet objectif serait d’implémenter le logiciel comme multiples environnements existants.
service central mis à disposition par l’un de vos
propres serveurs.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 2

3. WHITE PAPER: SOA
Du « client lourd »
à l’architecture trois-tiers
Layered Architecture LAYERED ARCHITECTURE
L’architecture typique au début du monde client/ FAT CLIENT
serveur se composait d’une base de données qui,
outre l’enregistrement des données de transac- ROLE
tion et des données de base, permettait d’établir Name Customer
une communication asynchrone entre les différents Street Supplier
composants du système, rendant ainsi possible Postcode Reseller
leur découplage. Les messages étaient écrits sur
la base de données par l’émetteur, puis lus à
partir de cet emplacement par le récepteur. Cette
méthode exigeait toutefois une scrutation (polling)
périodique de la table pour savoir s’il y avait des
messages nouveaux ou non traités. La logique
métier était implémentée en grande partie sur des
clients « lourds ». Les tâches pouvant être exécutées
en mode batch étaient implémentées via des pro-
cessus tournant en arrière-plan qui avaient accès à
la base de données.
Par ailleurs, les fonctions interactives destinées à
la validation des adresses ou à l’identification des
doublons lors de la saisie étaient, en règle géné-
rale, intégrées dans l’interface graphique. L’appel
des fonctions s’effectuait habituellement via des
interfaces propriétaires. Des spécifications telles que
DCE1 ou CORBA2, dont le but était la standardisa-
tion des interfaces pour assurer la communication
entre les différents composants distribués, sont res-
tées limitées et n’ont pas pu prendre l’essor souhaité.
1 http://en.wikipedia.org/wiki/Distributed_Computing_Environment
2 http://en.wikipedia.org/wiki/CORBA
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 3

4. LAYERED ARCHITECTURE WHITE PAPER: SOA
FAT CLIENT CLIENT
Cette situation a totalement changé dans les der-
nières années. Le point de ROLE
départ fût surtout la mise ROLE
Name Customer Name Customer
au point de plusieurs standards dans le cadre de
la spécification JEE (Java Enterprise Edition)3 et, par
Street Supplier Street Supplier
Postcode suite, le développement d’implémentations plus
la Reseller Postcode Reseller
performantes de ces standards comme solutions
commerciales ou Open Source.
APPLICATION SERVER
LA SIMPLE INTÉGRATION DANS LE
SERVEUR D’APPLICATIONS
– QUE CE SOIT SUR LA BASE D’UNE
ARCHITECTURE JEE OU .NET – EST AINSI
PASSÉE AU PREMIER PLAN.
Ce fut ensuite Microsoft qui suivit en développant,
pour le monde Windows, une plate-forme indé-
pendante des langages (.NET), ainsi que les ser-
vices d’entreprise .NET4. L’on disposait ainsi d’un
logiciel d’infrastructure performant qui permettait,
indépendamment de la plate-forme choisie (JEE,
.NET), de découpler dans une large mesure la
logique métier de la couche présentation et de
l’implémenter sur le serveur dans une couche indi-
viduelle. Ceci a entraîné un changement des exi-
gences envers les services de qualité des données.
Ces derniers étant désormais largement acces-
sibles depuis la logique métier, du côté serveur.
La simple intégration dans le serveur d’applications
– que ce soit sur la base d’une architecture JEE ou
.NET – est ainsi passée au premier plan.
3 http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
4 http://en.wikipedia.org/wiki/.NET_Framework
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 4

5. WHITE PAPER: SOA
SOAP, protocole clé
pour une SOA optimale
Pour pouvoir tirer le meilleur parti de la SOA, il Proprietary Protocol
fallait d’abord établir un protocole standard pour
la mise à disposition et l’utilisation des services.
Cette condition a été parfaitement remplie avec la
création du protocole de services Web « SOAP5 ».
Pris en charge pratiquement par tous les compo-
sants d’infrastructure et middleware, ce protocole
assure une complète interopérabilité entre fournis-
seurs de services, middleware et consommateurs
de services. Ainsi, on évite la nécessité de mettre
en place des liaisons pour utiliser des protocoles
non libres dans les middleware propriétaires, ce
qui ouvre la voie au déploiement de composants
middleware puissants. Dans cette catégorie, on
trouve le concept de l’Enterprise Service Bus (ESB)6
qui permet un couplage lâche entre les différents
composants avec un fort accent sur le routage des
messages, tout comme les moteurs qui peuvent
directement exécuter les flux de travail définis
dans un langage d’exécution de processus métier
(BPEL)7 .
Les services Web basés sur SOAP sont ainsi deve-
nus un instrument incontournable pour la mise à dis-
position de services interactifs de qualité des don-
nées dans les Architectures d’Entreprises modernes.
Il s’agit là surtout de services qui fonctionnent selon
le modèle requête/réponse, où le consommateur
de service initie une requête (par ex. « valider
l’adresse indiquée ») et le service répond directe-
5 http://en.wikipedia.org/wiki/SOAP
6 http://en.wikipedia.org/wiki/Enterprise_service_bus
7 http://en.wikipedia.org/wiki/BPEL
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 5

6. WHITE PAPER: SOA
ment avec une confirmation, une proposition de SOAP Protocol
rectification ou une série d’adresses considérées
correctes. Cette façon de procéder correspond
au caractère interactif de la validation, dont le but
est d’assister l’utilisateur lors de la saisie d’un objet
métier tout en lui offrant des possibilités d’interven-
tion en cas de problèmes. Toutefois, cette fonction-
nalité n’est plus implémentée de façon isolée dans
la couche présentation, mais plutôt intégrée dans
un processus métier d’ordre supérieur.
LA RELATION ENTRE L’IMPLÉMENTATION
DES PROCESSUS MÉTIER ET LES
FONCTIONS DE QUALITÉ DES DONNÉES
DEVIENT AINSI TRÈS CLAIRE, DE MÊME
QUE LE RÔLE IMPORTANT DE CES
DERNIÈRES DANS LE SUCCÈS DU
PROCESSUS MÉTIER EN QUESTION.
Ceci est le cas , par exemple, pour l’implémenta-
tion d’un processus de commande dans une appli-
cation e-business ou bien pour l’implémentation
d’un processus pour la conversion et qualification
de leads dans une application CRM ou tout autre
processus similaire. La relation entre l’implémenta-
tion des processus métier et les fonctions de qualité
des données devient ainsi très claire, de même
que le rôle important de ces dernières dans le suc-
cès du processus métier en question.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 6

7. WHITE PAPER: SOA
Cas clients
Orange
Les clients de l’opérateur de télécommunications C’est également dans cet environnement qu’Uniserv
Orange peuvent prendre contact avec l’entreprise met à disposition ses services de qualité des don-
par l’intermédiaire de divers nées pour la validation, restructuration et normalisa-
canaux. Ils peuvent visiter le site tion des adresses clients. Cette approche orientée
Internet de l’entreprise, appeler services permet d’utiliser les mêmes services dans
le centre d’appel ou se rendre divers processus et différents canaux de commu-
à une boutique d’un opérateur nication. Qu’il s’agisse de la saisie d’un nouveau
partenaire d’Orange. Mais, client Orange ou de la modification d’une adresse
indépendamment de la méthode de contact choi- existante, et quel que soit le canal de contact utilisé
sie par le client, il est impératif que les processus pour le lancement d’un processus, l’architecture
correspondants gardent toujours le même niveau de orientée services mise en place garantit une ges-
qualité. L’exactitude des adresses clients constitue à tion cohérente des processus en cours et l’accès
cet égard un élément très important pour garantir la de ceux-ci aux mêmes services. Un haut niveau de
qualité des processus. qualité des données d’adresses est ainsi garanti à
l’échelle de toute l’entreprise.
Sur le plan technique, on trouve un serveur d’appli-
cations libre JOnAS (Java Open Application Server).
Ce serveur JEE joue un rôle central dans la mise en
œuvre des services nécessaires à l’implémentation
des processus métier d’Orange.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 7

8. WHITE PAPER: SOA
Customer Cases
WinGroup AG
L’allemand WinGroup AG, groupe prestataire de
services dans le domaine Ventes et Marketing offre
à ses clients une vaste palette
de services dans une multitude
de domaines : centres d’ap-
pels, sociétés de publipos-
tage, dialogue marketing et services informatiques.
Afin d’assurer un niveau élevé et constant de quali-
té des processus pour l’ensemble des domaines de
services et des applications spécifiques au client,
WinLogic – filiale du groupe WinGroup AG – a
développé, sur la base d’un ESB, une architecture
orientée services. Cet ESB représente un intergiciel
servant à connecter toutes les applications de l’en-
treprise aux services centraux disponibles. Dans le
domaine de la qualité des données, cette liaison
concerne les solutions Uniserv pour la recherche
de doublons et la validation d’adresses.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 8

9. WHITE PAPER: SOA
REST :
une alternative légère à SOAP
Même si les protocoles basés sur SOAP semblent inadéquats pour ce scénario d’utilisation en raison
être la solution idéale pour l’intégration dans les de l’overhead inhérent au protocole SOAP. Les ser-
middlewares d’entreprise classiques, il existe néan- vices Web RESTful offrent à cet égard beaucoup
moins des applications pour lesquelles l’utilisation plus de souplesse. L’appel des services s’effectue
d’autres alternatives comme les services RESTful8 via le protocole http et les arguments d’appel sont
est plus avantageuse. Ceci est surtout le cas si ensuite encodés dans les URL. Lors d’un appel à
l’accès aux services de qualité des données doit partir de JavaScript, le résultat est fourni – dans le
s’effectuer directement au niveau de la couche cas idéal – au format JSON9. Il en résulte un code
présentation (basée sur HTML/AJAX). Un scénario JavaScript que l’interpréteur JavaScript du navi-
typique est celui des outils d’aide à la saisie qui
complètent automatiquement les données en cas LES SERVICES AINSI ÉLABORÉS PEUVENT
de saisie partielle ou offrent des propositions sur la ÊTRE PARFAITEMENT UTILISÉS DANS
base des informations partielles saisies. Les outils LES APPLICATIONS WEB 2.0 TYPIQUES.
d’aide à la saisie sont naturellement intégrés dans
la couche présentation. Cependant, ils ont des
exigences beaucoup plus élevées concernant les gateur peut directement interpréter pour fournir le
temps de réponse, étant donné qu’ils sont appelés résultat de l’appel sous forme d’objets JavaScript.
avec fréquence lors de la saisie (en général après Les services ainsi élaborés peuvent être parfai-
la saisie de chaque caractère). tement utilisés dans les applications Web 2.0
typiques.
Bien que les services utilisés à cet effet dans le
domaine de la saisie d’adresses soient les mêmes
que ceux utilisés pour la validation d’adresses, les
services Web basés sur SOAP s’avèrent parfois
8 http://en.wikipedia.org/wiki/REST
9 http://en.wikipedia.org/wiki/JSON
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 9

10. WHITE PAPER: SOA
SOAP –
les différences subtiles
Même en adaptant les interfaces propriétaires à La spécification SOAP offre deux possibilités pour
la communication basée sur SOAP, il reste à sur- définir, dans WSDL, la liaison entre la structure XML
monter les obstacles liés à l’apprentissage. La du paquet et les constructions du langage de pro-
description des paquets échangés dans le cadre grammation qui interprète ou met à disposition le
d’une communication basée sur SOAP se fait en paquet. Le « style rpc » correspond – comme l’acro-
utilisant le méta-format appelé WSDL (Web Service nyme l’indique – au classique appel de procédure
Description Language). distante (RPC). Il modélise les opérations comme
des appels de méthodes qui ne diffèrent pas des
LORS DU DÉVELOPPEMENT DU WSDL10, appels locaux. Ceux-ci constituent une solution
IL FAUT VEILLER À CE QUE LES TYPES DE idéale si on veut appeler le service Web en utili-
DONNÉES UTILISÉS SOIENT RÉELLEMENT sant un langage de programmation orienté objet tel
PRIS EN CHARGE PAR TOUS LES LANGA- que Java ou C#. Le « style Document » est, quant
GES ET SYSTÈMES CIBLES DANS […] à lui, approprié pour modéliser des contenus com-
DOIT ÊTRE CONSOMMÉ plexes. Ces derniers pouvant être représentés dans
un document XML avec son schéma XML associé.
Lors du développement du WSDL10, il faut veiller Ceci permet, d’un côté, d’effectuer la validation
à ce que les types de données utilisés soient réel- par rapport au schéma XML à l’aide d’outils XML
lement pris en charge par tous les langages et standard et de l’autre, d’utiliser ces outils ou des
systèmes cibles dans lesquels le service doit être frameworks appropriés pour traiter ultérieurement
consommé. Cet aspect n’est pas si important quand le document, le modifier ou le préparer pour la
il s’agit de tâches de développement réalisées au couche de présentation. Les deux variantes ont leurs
sein de l’entreprise avec une infrastructure logicielle avantages et leurs inconvénients. Dans le cas où les
homogène (par ex. JEE ou .NET). Mais il devient services doivent être appelés depuis plusieurs envi-
essentiel si l’on veut utiliser un service de qualité ronnements, l’utilisation des deux variantes pourrait
des données dans plusieurs environnements dont même s’avérer nécessaire.
certains étaient peut-être inconnus jusqu’à présent.
10 http://en.wikipedia.org/wiki/Web_Services_Description_Language
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 10

11. WHITE PAPER: SOA
De par leur nature, les services Web sont sans état. sont requises, il ne faut en aucun cas procéder à
Cela signifie que, dans le cas idéal, ils ne fournis- une implémentation ad hoc de la gestion et de la
sent pas de résultats partiels. Le résultat de l’appel synchronisation de l’accès aux ressources pour le
est donc un résultat total : les appels consécutifs service Web correspondant. Au lieu de cela, il faut
sont toujours indépendants l’un de l’autre. utiliser les pools de ressources fournis par la plupart
des applications serveur ou disponibles en tant
CES DEUX DERNIERS POINTS DOIVENT, qu’extensions Open Source. Un pooling efficace et
EN PARTICULIER, FAIRE L’OBJET D’UN configurable sera ainsi assuré.
REDESIGN – DU MOINS PARTIEL – Ces deux derniers points doivent, en particulier,
SI L’ON VEUT METTRE À DISPOSITION LA faire l’objet d’un redesign – du moins partiel – si
FONCTIONNALITÉ EXISTANTE COMME l’on veut mettre à disposition la fonctionnalité exis-
SERVICE WEB. tante comme service Web.
Les services Web doivent être extensibles.
L’absence d’états précédemment décrite constitue à
cet égard une condition indispensable. De plus, le
service Web ne doit avoir accès qu’à un nombre
très limité de ressources globales (voire même à
aucune ressource). Dans le cas où ces dernières
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 11

12. WHITE PAPER: SOA
L’architecture SOA estompe la
différence entre le mode
« On Premise » et « On Demand »
La mise à disposition de services logiciels et d’ap- interventions doivent être réalisées pour chaque
plications sur Internet – connue sous les appella- pays dont les adresses doivent être validées.
tions « Software on Demand11 », « Software as a L’utilisation de telles solutions ne devient alors inté-
Service » (SaaS) ou « Cloud Computing » – est un ressante que si le volume de données est assez
thème qui gagne de plus en plus d’importance. important. Cette restriction peut être contournée via
On tend souvent à souligner les différences pro- la mise à disposition du service en mode SaaS.
fondes et fondamentales entre les logiciels ins-
tallés localement « On Premise » et ceux utilisés
LA MANIÈRE DONT UN SERVICE EST MIS
via Internet « On Demand ». Or, ceci n’est pas
À DISPOSITION NE JOUE AUCUN RÔLE
le cas du point de vue de la SOA. En effet, la
DANS LE CADRE D’UNE ARCHITECTURE
manière dont un service est mis à disposition ne
ORIENTÉE SERVICES.
joue aucun rôle dans le cadre d’une architecture
orientée services. La mise à disposition d’un ser-
vice via Internet – en alternative au serveur local Dans ce cas, seules les transactions réellement réa-
– offre des possibilités d’utilisation intéressantes, lisées sont facturées. L’utilisation d’une architecture
notamment dans le domaine des services de qua- orientée services permet de combiner librement
lité des données destinés à la validation et à la les services installés localement avec ceux utilisés
rectification par comparaison avec des données via Internet ou de les interchanger. Cette utilisation
de référence. combinée permet de trouver la solution optimale
pour chaque utilisateur et de la modifier par la
Les données de référence requises pour le service suite pour l’adapter aux nouvelles conditions envi-
doivent être actualisées régulièrement. Cela exige ronnantes
une intervention manuelle régulière et le paiement
de frais d’abonnement aux fournisseurs des don-
nées. En cas d’utilisation de répertoires de codes
postaux spécifiques aux pays, ces dépenses et
11 http://en.wikipedia.org/wiki/Software_as_a_Service
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 12

13. WHITE PAPER: SOA
Conclusions
Sur la base des expériences précédemment décrites, on peut tirer les conclusi-
ons suivantes en tenant compte de deux aspects :
ASPECT UN: Quelles sont les exigences qui doivent
être remplies pour que les fonctions de qualité des
données puissent être intégrées dans un environne-
ment SOA ?
– Les fonctions doivent être accessibles via SOAP. – De plus, il faut vérifier s’il y a moyen d’obtenir
Ainsi, elles pourront être intégrées dans pra- des avantages économiques ou techniques en
tiquement toutes les infrastructures pour une utilisant un scénario alternatif dans lequel le
implémentation orientée services des processus service est mis à disposition via Internet, et si le
métier. Toutefois, il faut veiller à ce que le map- fournisseur de services supporte un tel scénario.
page entre les éléments XML de la description
du service et les constructions correspondantes
de l’environnement serveur soit applicable.
– Si l’utilisation est prévue dans la couche présen-
tation, il faudra vérifier si l’implémentation d’un
service RESTful est nécessaire.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 13

14. WHITE PAPER: SOA
ASPECT DEUX: Quels sont les aspects à tenir en
compte si l’on veut que des fonctions de validation,
d’enrichissement et de mise en forme des données
deviennent compatibles avec l’architecture SOA ?
– Les scenarii d’utilisation doivent être clairement – L’extensibilité du service doit être assurée. Si le
définis. La question importante ici est de savoir service Web a besoin de ressources globales
si les services seront utilisés dans le cadre de (par. ex. une connexion à la base de données),
la logique métier ou de la logique de présen- celles-ci doivent être gérées dans le conteneur
tation. Dans le premier cas, l’intégration s’ef- du serveur en utilisant un pool de ressources
fectue dans le serveur d’applications, dans le adéquat. Autrement, ces ressources risquent de
bus de services d’entreprise (ESB) ou dans un se transformer en un véritable obstacle à l’ex-
moteur BPEL. Dans le deuxième, l’intégration se tensibilité du service.
fait dans l’interface graphique qui peut avoir
des exigences spécifiques. C’est en fonction – Le service doit être accessible sur le réseau. Il
de ces facteurs que l’on pourra décider de la doit donc fonctionner indépendamment du fait
solution la plus appropriée (services basés sur qu’il soit mis à disposition sur un réseau local
SOAP et/ou services RESTful). ou sur le réseau Internet. Ceci étend énormé-
ment les possibilités d’utilisation.
– Les systèmes et les langages cibles dans les-
quels le service sera utilisé doivent être définis.
Sur la base de cette définition, on pourra déci-
der du degré de complexité de la modélisation
(en relation avec les structures XML utilisées et Pour de plus amples renseignements
les types de données XML des résultats d’ap- n‘hésitez pas à consulter la page web suivante
pels). www.uniserv.com ou à nous contacter directement:
– Le service doit être conçu sans états, c’est-à-
dire qu’il doit fonctionner sans mémorisation
d’états internes entre deux appels. Si un état est
requis entre les appels, celui-ci devra être remis Nous sommes heureux de vous conseiller et vous
lors de l’appel suivant ou rendu persistant de accompagner tout au long de votre projet.
manière appropriée.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 14

15. WHITE PAPER: SOA
Uniserv
Uniserv est le plus grand fournisseur européen spécialisé en solutions de qualité
des données à travers un portefeuille de logiciels utilisables au niveau internati-
onal ainsi que des services pour la qualité des données dans le domaine de la
BI et des applications CRM, Data Warehousing, eBusiness et Markting direct et
de données.
Avec plusieurs milliers d’installations dans le monde entier,
Uniserv soutient des centaines de clients dans leurs efforts
visant à reproduire une vision d’ensemble du client dans MIGRATION
DE
leurs bases de données clients. Uniserv emploie plus de DONNÉES
110 personnes en son siège de Pforzheim ainsi que dans E-BUSINESS
sa filiale de Paris et dessert, dans tous les secteurs et à
échelle internationale, de nombreux clients de renommée ERP
comme, par exemple, ADAC, Allianz, BMW, Commerz-
bank, DBV Winterthur, Deutsche Bank, Deutsche Börse COMPLIANCE
Group, France Telecom, Greenpeace, GEZ, Heineken, CRM
Johnson & Johnson, Nestlé, Payback, PSA Peugeot Cit-
roën ainsi que Time Life et Union Investment.
Pour en savoir plus, SOA
consultez www.uniserv.com MARKETING
DIALOGUE & MDM/CDI
DIRECT
ON PREMISE/
ON DEMAND
BI/BDW
CPM
Expérience: Position sur le marché: Employés:
PLUS DE 40 ANS LE PLUS GRAND PLUS DE 110 PERSONNES
FOURNISSEUR EUROPÉEN
UNISERV SARL Contact:
Bât. Le Sisley PARIS NORD 2 • 23 Allée des Impressionnistes +33 1 48 63 91 91
BP 53421 VILLEPINTE • 95944 ROISSY CH DE GAULLE CEDEX •France
E contact-france@uniserv.com • www.uniserv.com
© Copyright Uniserv • Pforzheim / Allemagne • All rights reserved.
© UNISERV GmbH / +33 1 48 63 91 91 / All rights reserved. Page 15