Livre Blanc WP Gouvernance Donnee

Architecture de Systmes dInformation Gouvernance de la donne Livre Blanc
Mai 2004
Architecture de Systmes dInformation - Gouvernance de la Donne
Table des matires

I. Introduction ..........................................................................................................................................................4 1.1 Un ROI pour la Gouvernance de la donne ........................................................................................................4 1.2 Nouveaux besoins, nouveaux usages .................................................................................................................5 1.3 Les leons de lhistoire.........................................................................................................................................6 1.4 La donne, un lment de la gouvernance du SI................................................................................................7 1.5 Une vision organique du Systme dInformation ...........................................................................................9 1.6 Conclusion : cycles courts, cycles longs............................................................................................................10 II. III. Les enjeux : Qualit et Interoprabilit des donnes ....................................................................................11 La modlisation des donnes du SI ................................................................................................................13 3.1 Modlisation des donnes : relationnel ou document ? ....................................................................................13 3.1.1 Modlisation relationnelle ...........................................................................................................................13 3.1.2 Modlisation oriente Document ................................................................................................................14 3.1.3 Une reprsentation hirarchique pour les donnes du SI..........................................................................15 3.2 Identification des invariants dentreprise............................................................................................................16 3.3 Le cas particulier de la donne rfrentielle......................................................................................................18 IV. La proprit des donnes : une ralit organique ...................................................................................19 4.1 Axe des invariants du SI ....................................................................................................................................20 4.2 Axe Gographique .............................................................................................................................................20 4.3 Axe Organisation................................................................................................................................................21 4.4 Matrice de proprit ...........................................................................................................................................21 V. Structurer les changes : la Data Supply Chain ......................................................................................22 5.1 Producteur..........................................................................................................................................................22 5.2 Consommateur...................................................................................................................................................22 5.3 Validateur ...........................................................................................................................................................23 5.4 Agrgateur..........................................................................................................................................................23 5.5 Distributeur.........................................................................................................................................................24 VI. Des patterns pour urbaniser les Data Supply Chains .............................................................................25
6.1 Urbaniser les changes bilatraux.....................................................................................................................25 6.2 Urbaniser les changes multilatraux................................................................................................................26 VII. Une organisation pour la Gouvernance de la Donne...................................................................................31 VIII. Exemples dimplmentation .............................................................................................................................32
8.1 Des outils pour la modlisation..........................................................................................................................33 8.2 Emergence dun missaire ................................................................................................................................34 8.2.1 Architecture gnrale dun missaire EAP .................................................................................................35 8.2.2 Les frameworks utiles aux missaires........................................................................................................36 8.3 Une approche plus industrielle de lmissaire .............................................................................................38 8.3.1 EAI, ETL : Diffrences et complmentarits...............................................................................................39 8.3.2 Un missaire bas sur un socle EAI ..........................................................................................................40 8.3.3 Un missaire bas sur un socle ETL..........................................................................................................42 IX. A propos dOcto Technology............................................................................................................................46
2004 OCTO Technology. Tous droits rservs......................................................................................................47 Auteurs :...................................................................................................................................................................47 Bibliographie OCTO Technology :............................................................................................................................47
I. Introduction
Gouvernance de la donne ? Quel bien trange sujet en pleine euphorie des architectures orientes services ! Et pourtant, comme toute nouvelle thorie informatique (idologie serait le terme adquat), SOA1 surestime sa proposition de valeur en faisant table rase des expriences du pass. Lurbanisme ? Has been : faites du SOA. Les moniteurs transactionnels, le dveloppement dapplications ? SOA. Lintgration ? SOA. La scurit, les pannes de serveurs, la mto pourrie ? SOA.
Pas darchitectures de services sans continuit de la donne.
Tout devient simple et forcment comme en politique, la rduction abusive fonctionne, car elle donne au quidam lillusion de comprendre. Malheureusement, btir des architectures orientes services, cest--dire o chaque sous-SI interopre avec ses voisins selon une charte de services, est une ide vieille comme linformatique. Rien de nouveau sous le soleil, on a remplac le terme urbanisme, au parfum surann et relents de vieilles casseroles, par un SOA, plus hype , XML-enabled . Or, on sait bien que si lon souhaite crer une continuit de services, il faudra sinterroger en premier lieu sur la continuit des donnes. Quel intrt pour un getCustomerInfo() qui renvoie un type de client indchiffrable, une rfrence sibylline un contrat, un identifiant unique qui ne lest pas ?
1.1
Un ROI pour la gouvernance de la donne
Dans lentreprise, chaque division consomme de linformation et en produit en retour. En corollaire, tout bloc du SI produit et consomme de la donne que nous qualifierons de publique . Cette donne va bien au-del des simples rfrentiels de lentreprise : clients, produits, structure organisationnelle, etc. Il sagit aussi des donnes dactivit qui concernent plus dune entit dans lentreprise : contrats en cours, ordre de fabrication, stocks, etc.
Toute division dune organisation produit et consomme de la donne et est confronte des problmes de disponibilit, consistance, utilisabilit et scurit de linformation.
Ce problme semble simple lchelle dun cabinet mdical ou dune PME, mais prend en revanche toute sa dimension au sein des grandes entreprises, o linformation partager est complexe et son primtre vaste. Ceci pose quatre grands problmes. La disponibilit de la donne en premier lieu bien sr. Qui na jamais pest ou t oblig de contourner un problme faute de disposer de la bonne donne, quelle existe ou non de manire numrique du reste. La consistance. X dit blanc, Y dit noir. A se conforme telle nomenclature, B telle autre. Qui a tort, qui a raison ? La stratification organisationnelle, voire la concurrence pure et simple de services, aboutit souvent du doublonnage de donnes de rfrence et donc de lincohrence. Lutilisabilit : la forme, la fracheur doivent tre adaptes aux usages des consommateurs. Une donne trop agrge, ou linverse pas assez ; une donne pas assez frache ou linverse trs frache, mais manquant pour le coup dun ncessaire niveau de validation de son intgrit, de sa consistance. Pour une mme donne, les besoins sont souvent diffrents selon les consommateurs.
1 : Service Oriented Architecture
La scurit : fiabilit de lmetteur, confidentialit de lchange, voire principe dopt-in2 dans les administrations, la scurit de la donne peut devenir un vrai casse-tte. Nous sommes tous confronts ces problmes puisque nous sommes tous la fois des producteurs et des consommateurs de donnes. Nous verrons que dans cette Data Supply Chain existent dautres rles, comme le validateur, lagrgateur, et surtout le distributeur. La part de valeur ajoute affecte aux relations extrieures dans linformatique dune organisation est variable mais toujours significative. Dune manire gnrale, les projets multilatraux impliquant plusieurs divisions souffrent de problmes de productivit, cause de distorsions de mthodes et de donnes. Augmenter la productivit de la Data Supply Chain savrera rentable dans la construction du SI mais aussi dans son utilisation. En effet, la mise disposition scurise par chaque acteur de sa part de donnes publiques permettra de gnraliser le concept dinfocentre et ainsi crer des usages encore indits. Un institut danalyse amricain indpendant, le Data Warehousing Institute, estimait en 2002 600 milliards de dollars le cot annuel de la non-qualit des donnes dans les entreprises US. Cette analyse est fonde sur un panel de plusieurs centaines dentreprises. Loin de cautionner le chiffre en lui-mme (quels critres de non-qualit ? quelle pondration de cot ?), cest bien lordre de grandeur quil est intressant de mettre en avant. Plus spcifiquement, la Securities Industry Association, un organisme de standardisation ddi aux milieux boursiers, estime que 80 % des cots de transactions sont dus la gestion dexceptions, dont prs de la moiti sont lies des distorsions de donnes de rfrence. Cela fait rflchir.
Une meilleure gestion de la data supply chain amliore la productivit informatique et autorise des usages indits pour les oprationnels.
1.2
Nouveaux besoins, nouveaux usages
La consistance de linformation pose des problmes de productivit au sens large dans les projets informatiques, elle peut aussi constituer un levier de comptitivit, voire une obligation lgale. Ces usages peuvent se dcliner selon les diffrents axes de lcosystme de lentreprise : Les clients : la matrise de linformation sur le client est la cl de vote des projets de GRC3. Pourtant force est de constater que cette vidence a t mal perue dans les entreprises o lon a cru par simplisme (marketing et manichisme vont souvent de pair-) quun progiciel intgr pouvait absorber la complexit des interactions du client avec tous les canaux de lentreprise. Or inutile, par exemple, de rver historique client quand on le repre dans le SI avec des cls instables ou isoles : nom, n de carte SIM, compte bancaire, nCB, adresse mail Rsultat : des cots faramineux pour des intgrations au rabais- et au final les fonctionnalits dun Outlook.
Des gains dans les quatre dimensions stratgiques de lentreprise : clients, fournisseurs et partenaires, employs, rgulateur.
Les fournisseurs et partenaires : de la comptabilit analytique lvaluation formelle des fournisseurs, le besoin en donnes consistantes et la capacit les partager sont vitaux pour grer au mieux ces relations privilgies : rentabilit, fidlit, qualit. Les employs : indpendamment des donnes purement ressources humaines (formations, valuations, rmunrations), la gestion de lidentit des employs est le challenge auquel sont confrontes les grandes entreprises pour augmenter leur niveau de scurit et simplifier laccs aux ressources physiques et virtuelles de la compagnie : badge, tlphone, identifiants informatiques, permissions, etc.
2 : Il appartient lusager final de dcider de la donne quil souhaite rendre accessible. 3 : Gestion de la Relation Client, ou CRM en anglais (Customer Relationship Management)
Le rgulateur : on a souvent limpression que les conventions internationales sur lenvironnement ou le blanchiment dargent ne servent rien. Cest parfois vrai, en revanche elles imposent aux bons lves une hygine particulirement consommatrice en donnes de qualit. Pour les institutions financires, les normes IAS4 et Ble II imposent la mise en place dindicateurs de risque homognes et assortis dune matrise totale de la chane informationnelle qui conduit au calcul du risque, y compris pour le swap de change book au fin fond de lAsie. Ces besoins se retrouvent dans tous les secteurs extrmement rglements comme lindustrie pharmaceutique, lagro-alimentaire ou encore larmement (non je plaisante).
1.3
Les leons de lhistoire
La qualit de la donne, un problme ne pas adresser ponctuellement, mais dans la dure, en y impliquant chaque projet.
Le mythe du modle de donne dentreprise na pas survcu trs longtemps face la douloureuse et complexe ralit. Le systme dinformation nest pas une application monolithique au cycle de vie uniforme. Que cela soit dit. Pour autant, nous avons dmontr le besoin dun certain niveau de cohrence dans la donne quil manipule. Lhistoire va donc nous aider positionner correctement le curseur de la rationalisation entre lanarchie et la cristallisation abusive. La plupart des projets dcisionnels se sont heurts aux problmes de qualit de la donne. Mais plutt que de standardiser et mettre niveau les systmes sources, toute lnergie a t dpense pour crer du systme supplmentaire, afin dobtenir une vision commune en central. Programmes de chargement, contrles, transcodification, enrichissement Comble de lironie, ces programmes oeuvrant uvrant une soit disant interoprabilit cristallisent encore plus ldifice en prennisant des concepts locaux ou dsuets. Le dcisionnel na donc que trs faiblement particip la normalisation de la donne dans les Systmes dInformation. Fort de ce constat, lenjeu sera donc de crer de la qualit sur la donne beaucoup plus en amont que nont pu le faire de tels entrepts.
Normes fonctionnelles, outillage technique et organisation de soutien : les trois piliers de la gouvernance.
Pour cela, le problme devra tre adress sous trois angles : un angle fonctionnel (normalisation des donnes, matrice de proprit, urbanisation de la Data Supply Chain ), technique (outillage de modlisation, de gestion des flux, de stockage..), et surtout organisationnel, de manire maintenir une dynamique de cohsion dans la dure. Ces trois axes que nous allons dvelopper par la suite constituent gouvernance5 de la donne dans lentreprise. les fondements de la
4 : International Accounting Standards 5 : Au sens large, on entend par gouvernance lensemble des processus et organisations mis en uvre pour gouverner sur un primtre donn.
1.4
15 cases pour dcrire une application.
La donne, un lment de la gouvernance du SI
Nous pouvons inscrire cette gouvernance de la donne dans celle, plus globale, de la gouvernance du Systme dInformation. Partons dune application, celle que vous pourriez crire vous-mme et dployer sur votre PC ou votre tlphone portable. Pour la dcrire, il est possible de dcouper le sujet en trois plans de cinq thmes chacun. Chaque plan correspond un acteur particulier (ici vous seul), de haut en bas : lanalyste, le dveloppeur et lexploitant.
Scurit Analyste Spcifications de la scurit : identification, habilitations
Accs
Services
Donnes Spcifications des donnes publiques et des donnes prives
Processus Cas dusage internes et externes
Spcifications de Spcifications linterface des services homme machine externes, des services internes selon la complexit Fondations techniques IHM : gestion des formulaires, des enchanements, des contrles Environnement dexcution client (PC) Fondations techniques des traitements : concurrence, gestion des erreurs Environnement dexcution serveur (Unix)
Dveloppeur
Fondations techniques scurit : annuaire, module dauthentification Dploiement physique du module de scurit
Fondations techniques de la persistance : lecture, criture, concurrence
Fondations techniques des changes : emballage, mission, rception Serveurs dchange
Exploitant
Serveur de stockage (cluster + SAN)
Le lecteur avis constatera que les deux lignes du bas sont potentiellement mutualisables entre applications du SI, le dernier tage de la fuse, correspondant au spcifique mtier, lest beaucoup moins.
Considrons maintenant cette grille de lecture de chaque application dans la gouvernance plus large du SI :
Matrice darchitecture de SI
Rien ninterdit de distiller des concepts fonctionnels dans un cadre structur propice la rutilisation.
Nous voyons apparatre au dernier tage, celui des matres douvrage oprationnels, un certain nombre de normes quil est possible de partager malgr tout. Loin de lurbanisme lgaliste , la mode schma directeur, dont lingrence nave na eu pour effet que de discrditer ce type de dmarche, il sagira danimer les cercles danalystes mtier, de capitaliser leurs expriences, et de proposer des outils adapts au partage du savoir. Le cur de cet ouvrage se situe donc la ligne 1, colonne 4 ... le SI est une matire premire complexe, quon se le dise.
1.5
Une vision organique du Systme dInformation
La gouvernance de la donne sintresse la gestion de la donne lchelle de lentreprise. Il sagit dorganiser et structurer les changes lchelle du systme dinformation. Cette chelle macroscopique englobe lensemble des projets et applications informatiques de lentreprise. Le Systme dInformation se dfinit donc par lensemble des applications de lentreprise. Une application est essentiellement un logiciel, dvelopp en interne ou achet sur tagre, associ au matriel ncessaire son fonctionnement (serveurs, rseaux).
Le Systme dInformation est une somme dapplications indpendantes. Lapalissade ? Pas forcment
Mais comment figer les limites dune application, lorsque tout le monde communique avec tout le monde ? Certains essaient de tendre de plus en plus vers des applications intgrant des services rpartis travers toute lentreprise, et parfois mme au-del. Restons proches du terrain : une application se dfinit comme un systme pouvant voluer un rythme homogne. Autrement dit, une application dlimite un ensemble de logiciels et matriels qui peuvent tous voluer simultanment lors dun passage en production. Sil nest pas possible de faire voluer deux systmes, ou deux composants, la mme vitesse, cest quils appartiennent deux applications diffrentes. Cette vision du SI est fondamentale. Nous voyons ici que deux visions antagonistes du Systme d Information saffrontent : Une vision lgaliste du SI, qui le considre comme une super application unifie qui pourrait tre gouverne comme un bloc homogne. Une vision plus organique qui le considre comme un amalgame de blocs voluant chacun de manire relativement autonome, qui il nest pas possible dimposer les mmes objectifs et contraintes. La cohrence de lensemble du SI passera alors par linteroprabilit entre ces diffrents blocs autonomes.
La vision organique, promouvant lautonomie des applications du SI, ne soppose pas aux exigences de pilotage stratgique.
Lexprience et le pragmatisme nous recommandent dadopter plutt cette deuxime vision, car elle est raliste et nest pas incompatible avec une exigence de pilotage stratgique. La vision organique du SI fait de l Application Informatique un systme autonome, tant sur la logique mtier quelle porte et sur les donnes quelle produit, que sur son rythme dvolution. Ainsi, une rgle de gestion ne devra pas se grer lchelle du SI mais localement, au niveau dune application : par exemple, une contrainte dintgrit sur un modle de donnes ne doit pas tre rplique dans plusieurs applications du SI, cela reviendrait considrer le SI dans sa globalit comme une application et non pas comme un amalgame de blocs autonomes.
1.6
Linsoutenable lourdeur du SI : Kundera premier aptre du refactoring.
Conclusion : cycles courts, cycles longs
Lextrapolation du SI comme somme dapplications, se heurte la dimension temporelle. En effet, nos blocs de SI ne sont pas des applications sinscrivant dans la matrice explicite plus haut, mais plutt des strates de projets. Cette stratification induit progressivement une perte de sens dans les systmes. On ne comprend plus qui fait quoi ni pourquoi, et encore moins comment. Incidemment, il est ncessaire de reconsolider rgulirement ces blocs. En langage sociologique, la reconsolidation consiste rinscrire des souvenirs acquis dans un tat de conscience antrieur dans le cadre de la conscience prise linstant prsent. On les actualise, et les repositionne dans les cases dans lesquelles ils font sens. En informatique, le terme refactoring issu du monde du dveloppement est utilis comme synonyme de reconsolidation. Notre propos est dtendre ses vertus la dimension du SI. Les vertus dune dmarche de reconsolidation ne sont probablement plus dmontrer, seule lest la manire dy parvenir. Les dmarches durbanisme cycle long ont largement chou dans cet objectif. LeXtreme Programming et le rationnement ambiant remettent les cycles courts au got du jour. Certains thoriciens de linformatique qui tentent de modliser notre environnement en ont redcouvert les vertus en dmontrant leur pertinence grands coups doptions (au sens financier). Souhaitons que cette caste de mathmaticiens sen tienne ses travaux sur leau tide La stratification des organisations et des systmes doit en effet nous pousser une certaine humilit quant nos capacits dvaluation prcise des situations et daction sur celles-ci.
Notre action sinscrit donc, fatalement, dans les deux temps : le temps court des projets, des analystes et dveloppeurs oprationnels qui sont les seuls vrais acteurs de la cration de SI, de la pression du rsultat laquelle ils sont soumis, et le temps long de lintrt collectif, du dveloppement durable. Lintrt collectif ntant que rarement gal la somme des intrts locaux, notre dmarche sintressera systmatiquement la recherche dquilibre entre ces deux parties.
10
II. Les enjeux : Qualit et Interoprabilit des donnes

Que voulons nous exprimer lorsque nous disons cette donne est de mauvaise qualit ? Comme toujours en matire de qualit, la difficult rside autant dans la dfinition de ce que nous voulons mesurer que dans la mise en place des mesures damlioration des mtriques observes. Nous estimons que la qualit dune donne ne peut sestimer que par comparaison avec une observation faite sur une autre donne. Dans certains cas, il sagira dobservation dans le monde rel , hors Systme dInformation : M. Dupond scrit-il bien avec un d ?
Lamlioration de la qualit de la modlisation ne peut passer que par une meilleure connaissance du domaine. Ce processus de distillation du savoir peut tre amlior. La qualit dune source de donne ne peut se mesurer que par rapport une autre source de donne.
Lenjeu ce stade est donc essentiellement la modlisation des donnes de ce monde externe au SI de telle manire quil soit raliste de parvenir les capturer, et quelles puissent surtout alimenter les processus de lentreprise afin de produire de la valeur. Nous ne pourrons augmenter la qualit de ces modles que si lon dispose dune bonne connaissance des mtiers et des contextes dvolution de lorganisation. La solution en la matire passera finalement par les hommes, et leurs comptences, et aucun outil mme les plus sophistiqus ne pourra apporter de solution systmatique et automatise. En revanche, ils pourront tre utiliss comme support du processus de distillation de la connaissance mtier pour faire merger les concepts cls de lentreprise. Nous reviendrons sur cette approche dans les chapitres suivants de notre analyse. Dans dautres cas, il sagira de comparer nos donnes avec dautres sources issues dun Systme dInformation, quil sagisse de celui de lentreprise ou bien dun de ses partenaires. Lenjeu de la qualit de la donne concernera alors la dtection et la rsolution de conflits entre sources de donnes. Nous donnons ici une classification des conflits entre sources de donnes : Conflit didentit Le mme objet possde des identits diffrentes selon les sources de donnes. Le client X est identifi par la cl X1 dans un rfrentiel et X2 dans un autre. Conflit de schmas Le mme concept est modlis de manire diffrente. - Noms de champs diffrents - Constructions diffrentes Le client est modlis par le champ customer dun cot, et par les deux champs nom et prnom par ailleurs. Conflit smantique Le mme concept est interprt de manires diffrentes. Un compte est un compte courant bancaire dans une application et un identifiant utilisateur permettant de grer la scurit des accs pour une autre. Le mme objet a des valeurs diffrentes selon les sources. La balance dun compte courant apparat diffrente suivant les bases dans lesquelles on le consulte.
Conflit de valeur
11
Les conflits proviennent souvent des rythmes dvolution diffrents des applications et des organisations.
Ces conflits sont autant de rvlateurs de la difficult dintgration entre applications. Les origines des distorsions peuvent tre varies, mais elles dcoulent souvent du caractre organique du Systme dInformation : - Rythme dvolution des schmas de donnes diffrents ; - Spcialisation des applications dans des domaines mtier diffrents, volution darchitectures centralises vers des architectures distribues ; - Difficult organisationnelle propager linformation. Ces applications doivent malgr tout dialoguer entre elles, et donc changer de la donne. Ce besoin dinteroprabilit induit : des cots de construction et de maintenance des interfaces de plus en plus levs, car lvolution des blocs des rythmes diffrents impose le plus souvent aux producteurs et aux consommateurs de fonctionner en ajout uniquement et rarement en refactoring, o les modles seraient allgs ; des cots cachs, hrits des distorsions de donnes, qui imposent la cration de programmes (rustines) spcifiques au sein de nos applications pour raligner des sources de donnes : deux systmes sources utilisent deux nomenclatures diffrentes pour exprimer une mme notion, par exemple une typologie client, le systme cible doit prendre sa charge la conversion de lune vers lautre pour fournir un service cohrent portant sur les deux populations de clients. Nous reviendrons plus loin sur le retour sur investissement (ROI) de chantiers destins amliorer cette situation. Pour linstant, raisonnons dans labsolu : quel formalisme devons-nous mettre en place pour faire en sorte que des applications indpendantes se comprennent, tout en garantissant leur niveau dindpendance ? Comment organiser ces applications pour faciliter ces changes ?
12
III. La modlisation des donnes du SI

3.1 Modlisation des donnes : relationnel ou document ?
Deux approches se compltent pour formaliser les donnes : lapproche oriente donnes, essentiellement reprsente par le modle relationnel, et lapproche oriente document, reprise et normalise par le format XML et ses drivs. Toutes deux sont issues dune histoire diffrente et cherchent rpondre des besoins et contraintes diffrents.
Le modle relationnel est bti autour de lobjectif principal dviter la redondance de reprsentation de linformation.
3.1.1 Modlisation relationnelle

Pour le modle relationnel, lobjectif est avant tout de garantir lintgrit et la qualit des donnes. Ce modle sest impos au cours du temps, car il est le seul capable de capturer la smantique associe aux donnes manipules par les applications informatiques, tout en garantissant leur intgrit. Le modle relationnel est articul autour des concepts entits et relations, ventuellement enrichi de quelques notions issues de la modlisation objet (par exemple lhritage, cher aux bases orientes objet). Les donnes sont reprsentes selon une organisation quasi parfaite, sur laquelle nous pouvons ensuite btir nos requtes de manire efficace en fonction des vues que nous souhaitons obtenir des donnes. Toute une thorie fut donc cre pour dmontrer le pouvoir expressif du modle et les mcanismes permettant de le manipuler. De plus, le modle relationnel garantit la cohrence des donnes au travers de ses fameuses formes normales . Celles-ci constituent finalement les meilleures pratiques de modlisation de la donne en nous garantissant mathmatiquement la non-duplication de donnes dans les bases. Cette chasse systmatique la duplication de donne est dailleurs au centre du modle relationnel. Cest grce elle que nous pouvons tre certains de la qualit de la donne, puisque chaque donne est reprsente une et une seule fois dans le modle.
Lclatement de linformation en entits atomiques complexifie les mcanismes de mises jour et ncessite lintroduction de contraintes dintgrit.
En revanche, la granularit fine des donnes complexifie dautant les mcanismes de mise jour des donnes. Dans la plupart des cas, en fonction des contraintes dintgrit attaches au modle relationnel, la mise jour dun ensemble de donnes lmentaires devra se faire au sein dune transaction et le systme devra garantir laspect ACID6. Par exemple, pour crer une nouvelle facture, nous devrons mettre jour la table facture , la table commandes avec tous les produits commands, et peut tre aussi dautres tables de positions comptables, attaches au client. En termes dimplmentation, les moteurs de base de donnes relationnels ont connu le succs que nous savons, en sappuyant sur le langage SQL que tous les informaticiens connaissent et manipulent quotidiennement. Les fournisseurs ont bien entendu enrichi leurs offres de tous les mcanismes de garantie de lintgrit de la donne laide de systmes transactionnels efficaces.
6 : Atomicit, Consistance, Isolation, Durabilit : les quatre proprits garantes de lintgrit des processus transactionnels
13
Le modle relationnel a tabli depuis plus de 20 ans une position de quasi monopole de la conception des bases de donnes dentreprise.
Depuis maintenant plus de 20 ans, le modle relationnel sest impos tel point quaucune approche concurrente ne semble mme de le dtrner. Mme la tentative des bases de donnes objet, qui auraient peut tre reprsent lvolution naturelle du modle relationnel, na pas rellement convaincu la majorit des producteurs et consommateurs de donnes, et loin sen faut ! Plus que jamais, les bases de donnes relationnelles sont les matres de la gestion de la donne au sein de lentreprise. Nous ne dcrirons pas ici les bonnes pratiques de la modlisation relationnelle au niveau dune application. La littrature sur le sujet est abondante et ce sujet a t largement tudi, rationalis et industrialis depuis maintenant plusieurs dcennies dHistoire de lInformatique.
3.1.2 Modlisation oriente Document

En dehors de la sphre des applications dentreprise, sur lesquelles reposent nos prcieuses donnes stratgiques, nous pouvons constater quune autre approche sest dveloppe. Lapproche oriente document fut prdominante dans les travaux autour de lEDI, du SGML, et plus rcemment de lXML. Pour ce modle, on ne cherche plus manipuler un ensemble de donnes lmentaires, et uniques, mais un ensemble de documents regroupant de manire smantiquement homogne des donnes lmentaires. On ne sinterdit pas davoir la mme donne lmentaire reprise au sein de plusieurs documents. Par exemple, si nos documents reprsentent des factures, il est probable que ladresse dun client donn sera reprise sur plusieurs documents. Cette dnormalisation de la donne au sens relationnel a un cot : la mise jour de ces donnes dupliques peut devenir complique sil faut retrouver tous les documents contenant ladresse du client, et les mettre jour lors dun dmnagement.
La modlisation oriente documents dXML permet de vhiculer des donnes naturellement intgres. Elle sadapte donc bien aux exigences de lintgration entre blocs du SI.
En revanche, lapproche oriente document prsente aussi certains avantages. Les donnes tant vhicules avec leur contexte, il devient trs simple de valider leur intgrit fonctionnelle. Il suffit de fournir un schma reprsentant lorganisation que devrait avoir le document et nimporte quelle application recevant le document pourra facilement valider que son exemplaire est cohrent. Par extension, une modification dun document a une tendue parfaitement identifie : elle se fera dans les limites du document ! La gestion des mises jour sen trouve largement facilite puisque une transaction de mise jour sera gnralement limite un document, contrairement un ensemble de tables dans le cas du modle relationnel, orient donnes.
14
Un document XML peut tre normalis au mme titre quun ensemble de tables relationnelles.
Il est remarquer que le succs des formats orients documents tels que XML pousse aujourdhui les thoriciens des bases de donnes retrouver dans les modles hirarchiques les notions de formes normales issues du monde relationnel. Lobjectif est ici davoir chaque document sous une forme normale sans redondance interne. En revanche, comme nous lavons dj voqu, lensemble des documents prsentera ncessairement des redondances les uns par rapport aux autres.
3.1.3 Une reprsentation hirarchique pour les donnes du SI

Les modles relationnels constitueront donc pour longtemps le cur de nos applications. En revanche, lexprience a montr que lon y trouve plat des informations de nature trs diffrentes : aussi bien des donnes dentreprise telles que des informations clients, des commandes et autres positions comptables. On peut galement y trouver des donnes de rfrences : code devises, table de correspondances entre rfrentiels htrognes, par exemple. Enfin, on retrouve aussi parfois des donnes finalement trs techniques : contenu de choix multiple pour des interfaces graphiques, des libells multilingues pour de laffichage cran ou des rapports papiers, etc. Or partir du moment o une application existe en tant que telle, et fait donc partie dun systme dinformation, nous pouvons estimer que tt ou tard, elle devra communiquer avec lextrieur, cest--dire dautres applications du SI. Se pose alors la question de ce qui devra tre publi et ce qui restera privatif. De toutes ces tables, parfois trs fonctionnelles, parfois trs techniques, lesquelles devront tre structures pour tre publies la communaut du Systme dInformation ? Une fois ce sous-ensemble dtermin, pouvons-nous imposer notre modle relationnel public la communaut ou passerons-nous par un intermdiaire dnormalis au sens relationnel ? Est-il raliste dessayer de concevoir le modle conceptuel des donnes de toute lentreprise ?
Le modle relationnel est trop complexe pour tre utilis lchelle du Systme dInformation.
Un modle relationnel est un rseau complexe de relations entre entits. Au niveau dune application dentreprise, il nest pas rare de croiser des modles de donnes comportant plusieurs centaines de tables. A lchelle dun SI, la complexit devient telle, que ce rseau de relations est quasiment impossible reprsenter. Nous devons donc revenir un mode de reprsentation plus simple qui serait un sous-ensemble de ce modle de donnes du SI, la partie merge de liceberg visible de tous en quelque sorte. Nous proposons dadopter une reprsentation hirarchique pour ce sous-ensemble.
15
3.2
Identification des invariants dentreprise
La modlisation des donnes est un art difficile. Crer un schma UML ou mme simplement relationnel efficace et exhaustif nest pas un exercice simple et ncessite lui seul des comptences spcifiques. Nous venons de voir quau niveau dun projet, on est souvent amen crer le dialogue entre informaticiens, organisateurs et utilisateurs pour parvenir formaliser simplement le sujet , en principe crucial que lapplication devra traiter. Inutile de dire quau niveau dun Systme dInformation, la tche qui consisterait crer le super Modle des Donnes de lentreprise est demble voue lchec. Simplement du fait des rythmes de vie diffrents des applications composant le SI, il est utopique desprer pouvoir capturer et figer dans le temps ce modle.
A lchelle du SI, il sagit de partager un langage commun autour dinvariants dentreprise, concepts stables dun domaine.
Malgr tout, il est indniable quil existe des invariants : nous aurons par exemple toujours besoin dun fichier client, dune liste de produits, dune base des contrats en cours, de la liste des employs, etc. Plutt que de parler dobjet mtier, nous introduisons donc la notion dInvariant dEntreprise . Les anglo-saxons parlent parfois de Core Domain . Leur identification ncessite davoir une comprhension globale de lorganisation et des enjeux de chacun. Aucun a priori ne peut tre pos pour les identifier, et seule une connaissance et une exprience approfondie des mtiers (de tous les mtiers) permettront de les reconnatre. Pour nous aider dans cette qute , il est intressant dutiliser ce que nous considrons comme un invariant des invariants, le pattern acteurs*actifs*positions. Il permet de structurer hirarchiquement les premires branches de larbre de linformation de lentreprise, ce qui permettra une meilleure lisibilit des modles dans le contexte global du SI, et donc une meilleure diffusion dans les communauts danalystes : Sous la branche Acteurs, se retrouveront les acteurs internes et externes lentreprise : employs, fournisseurs, partenaires, structure de lorganisation, etc. Sous la branche Actifs nous trouverons le catalogue de produits de lentreprise dune part (les actifs internes), et dautre part ce qui a servi le crer (les actifs externes). La branche Positions va contenir les relations contractuelles que tisse lentreprise ou ladministration entre acteurs et actifs : le permis de construire est une position entre un actif externe de type immobilier (les actifs de la sphre publique sont trs golocaliss) et un acteur personne physique ou morale ; une feuille de soin lectronique est une position entre un actif de type prestation de sant (les fameux Kxx, les mdicaments) et un acteur personne physique. La figure suivante illustre cette structure sur le primtre dune banque dinvestissement
Ces invariants assurent la cohrence des donnes lchelle du SI, et serviront de guide aux projets pour la spcification dtaille des modles de donnes. Nous pouvons nous appuyer sur des patterns gnriques pour nous aider dans notre tche de modlisation de la donne publique.
Les analystes mtier des projets au cur de la dmarche didentification des invariants.
La dmarche permettant lidentification de ces invariants et leur formalisation dans un arbre de donne publique passe par la capitalisation du savoir mtier accumul au niveau des projets et des applications. Cette dmarche ne peut donc pas se faire sans le support des projets. Bien entendu, un architecte mtier ayant une relle vision du domaine fonctionnel peut largement aider et acclrer le processus de distillation de la connaissance, mais finalement, il devra toujours sappuyer sur les expriences passes, quelles soient bonnes ou mauvaises.
16
Chaque branche de larbre va ensuite hberger les schmas de donnes dtaills dcrivant les objets quelle possde.
A titre dexemple, nous avons repris un extrait de la dfinition FpML7 dun produit de taux, qui sinsre donc dans notre modlisation des invariants comme une sous-branche des actifs internes.
7 : Financial Product Markup Language
17
3.3
Le cas particulier de la donne rfrentielle
Parmi les applications productrices de donnes, il en existe certaines particulirement sensibles puisquelles sont le support de la qualit globale de la donne : les rfrentiels dentreprise. Lobjectif dun rfrentiel dentreprise est de matrialiser un langage commun pour lensemble de lorganisation. Certains lments de ce langage sont utiliss tels quels par tous les acteurs, sans quasiment aucune adaptation ou enrichissement : inutile de rinventer sa propre nomenclature de devises, ou dimaginer des codes dimplantations diffrents de ceux en cours par ailleurs. On parlera de nomenclature pour ces petits rfrentiels : de 3 1.000 entres.
Les rfrentiels sont des gisements de donnes particuliers, ils doivent supporter une co-gestion tendue et gagnent centraliser leur distribution.
Certains autres rfrentiels sont en revanche davantage sujets modification et enrichissement. Il est probable que la classification des produits peut tre diffrente au sein dun grand groupe de distribution suivant quil sagira daliments frais dans un supermarch ou de portes-fentres armature mtallique. Dans ce cas, les applications spcialises utiliseront leurs propres rfrentiels qui contribueront ensuite au format de donne publique, et le simplifiant ou non selon les besoins de la communaut. Nous verrons plus loin quil est tout fait pertinent de mettre en place un distributeur unique de ces nomenclatures, largement utilises ou spcialises. Le distributeur na pas pour rle de servir de dpositaire de ces rfrentiels, il ne fait que les diffuser ses abonns. Enfin, les rfrentiels ont tendance se multiplier du fait de leur caractre mono-propritaire. Or, nautoriser quun mode de gestion centralis est insupportable pour des nomenclatures tendues comme une structure organisationnelle ou une typologie produit. Un rfrentiel de porte tendue doit permettre une gestion distribue de son contenu. En particulier, il supportera la sgrgation par entit (organisationnelle, gographique) et souvent un workflow de cration/modification/suppression de ses lments.
18
IV. La proprit des donnes : une ralit organique

Le chapitre prcdent a illustr la problmatique donnes et a insist sur un point : la modlisation structure et partage des donnes publiques de lentreprise. Ces modles peuvent ensuite tre exploits dans les changes de donnes et de services entre blocs du SI. Le problme se corse dans la ralit o lon va devoir adresser des environnements changeants, des frontires floues, des historiques varis : la filiale Japonaise dont le primtre client croise celui de la holding sans compatibilit des rfrentiels, lannuaire de scurit de ladministration X qui contient des utilisateurs de ladministration Y, les nomenclatures client de la filiale de tlphonie mobile incompatibles avec celles du reste du groupe, etc. Pour grer la problmatique de la donne lchelle des grands groupes, nous aurons donc besoin dun second outil de pilotage : la matrice de proprit. Nous venons de voir que notre Systme dInformation est un ensemble dapplications relativement indpendantes les unes des autres, et que nous le considrons comme un rseau de producteurs et consommateurs dinformation relis par des supply chains de la donne. Il nous faut localiser ces acteurs afin de qualifier leur rle au sein de ces supply chains : - Quelles donnes consomment-ils ? Quelles donnes produisent-ils ? - Avec quelle frquence ? Quel volume ? Quel format ? - Avec quel niveau de qualit ?
La localisation des acteurs permettra de mieux comprendre les rles et responsabilits de chacun au sein du SI, une vision multi dimensionnelle est ncessaire.
On pourra dailleurs au besoin formaliser des contrats de service entre les acteurs cls tels que les distributeurs et leurs consommateurs. A charge pour eux de grer la relation ventuelle avec les producteurs concerns, en respectant le niveau de contribution que ceux-ci peuvent apporter la communaut. Nous rejoignons ici des besoins proches de la cartographie du Systme dInformation ou de lurbanisation. En revanche, nous devons aller plus loin quune vision simplement gographique dun Systme dInformation dcoup en zones et quartiers. Il sagit l dune vision mono-axe du dcoupage du SI qui nest pas forcment suffisante pour localiser concrtement les acteurs.
19
Nous indiquons ici titre dexemple quelques axes gnralement rcurrents pour la caractrisation des primtres de proprit des producteurs de donnes : axe des invariants du SI (structure des objets manipuls), axe gographique (localisation gographique des producteurs), et axe organisationnel (localisation organisationnelle des producteurs).
4.1
Axe des invariants du SI

Axe Invariants du SI
Laxe des invariants du SI (ou invariants dentreprise) reprend les lments issus de la modlisation des concepts mtiers cls de lentreprise qui nous ont conduit la dfinition dun format de donne publique, tel que nous lavons vu dans les sections prcdentes. On retrouve ici un dcoupage fonctionnel qui rejoint le mme besoin que celui issu des travaux des Urbanistes, Matrise dOuvrage ou Analyste Mtier. A titre dexemple, nous reprsentons donc ici sous la forme dun axe invariants du SI les concepts issus de notre modle de donnes publiques dune banque dinvestissement, tel que nous lavons expos prcdemment dans le pattern acteurs*actifs*positions.
Acteurs/Contrepartie/Client Acteurs/Contrepartie/Emetteur Acteurs/Contrepartie/Custodian Acteurs/Interne/Employ Acteurs/Interne/Structure organisationnelle Positions/Deals Positions/Comptes cash Positions/Comptes titres Positions/Limites Positions/Engagements Actifs/Devises Actifs/Actions Actifs/Dettes Actifs/Dettes/Obligations
4.2
Axe Gographique
Axe Gographique
Il sagit dun axe hirarchique, reprenant la localisation gographique de la donne, quelle soit produite ou consomme. Une organisation multinationale telle quune grande banque dinvestissement pourrait reprendre les niveaux continent, pays, rgion, ville, etc :
Europe/France/Paris Europe/UK/Londres Amrique/USA/New York Amrique/USA/Chicago Asie/Japon/Tokyo
20
4.3
Axe Organisation
Axe Organisation Business/Equities/Achats Ventes dactions Business/Equities/Drivs Business/Money Market/Trsorerie Business/Money Market/Dette Risques/Contrepartie Risques/March Risques/Oprationnels Comptabilit
Il sagit ici de faire le lien avec lorganisation de lentreprise en reprenant les lments les plus stables et reprsentatifs de son organigramme. Dans le cadre dune banque dinvestissement, nous aurions par exemple :
4.4
Matrice de proprit
Finalement, en dfinissant nos axes de localisation des acteurs de linformation, nous avons simultanment modlis les axes de reprsentation dun Hypercube des producteurs et consommateurs de la donne. Nous pouvons lui appliquer les manipulations issues du monde des Data Warehouse. Nanmoins, il ne faut pas oublier que notre objectif est de fournir des outils exploitables au final par des humains, afin de les aider concevoir et suivre la production et la consommation des donnes qui sont au cur du Systme dInformation de leur Entreprise. La modlisation multidimensionnelle est certes un outil trs puissant, mais il faudra au final revenir sur une reprsentation en deux dimensions, sous la forme typiquement dune matrice, pour pouvoir lutiliser comme outil de pilotage. A titre dexemple, nous exposons ci-dessous une matrice qui pourrait tre issue dun processus de modlisation tel que nous venons de le dcrire.
La matrice de proprit : un puissant outil de pilotage pour la gouvernance de la donne.
Axe gographique Europe Axe Invariants SI Paris Client

Lgende : Chaque cellule identifie un acteur de la donne : Rle : P = producteur, C = consommateur Frquence : T = temps rel, Q = batch quotidien, M = batch mensuel
USA N.Y P/Q
Japon Tokyo P/Q
Londres P/T
P/T P/M C/M P/Q C/Q P/T C/T P/Q
Acteurs
Emetteur Equities
Actif Money Market Deals Positions Limites P/Q P/T C/Q C/Q P/M C/Q
21
V. Structurer les changes : la Data Supply Chain

Nous avons modlis la donne publique de lentreprise, puis cartographi les producteurs et les consommateurs de cette donne. Il se trouve quentre producteurs et consommateurs, un certain nombre de services doit tre garanti : dcouplage, agrgation, contrle, enrichissements, sont des fonctions que peuvent endosser diffrents acteurs de la supply chain. Nous proposons donc de classifier les acteurs impliqus dans la chane de la donne, de sa production sa consommation.
5.1
Producteur
Le producteur de la donne est celui qui cre la donne, ou lenrichit en lui donnant davantage de valeur, de dtail. Il est tout fait envisageable que plusieurs producteurs existent dans le SI pour la mme donne. Par exemple, une application base Paris pourra disposer de son propre rfrentiel client, et une autre application base New York disposera galement du sien. Elles seront toutes deux productrices de la donne client , mais sur des primtres diffrents. Cette autonomie des deux applications peut tre ncessaire pour garantir la ractivit face au besoin de cration ou de mise jour des fichiers clients, si les liens rseaux transatlantiques ne permettent pas nos deux applications de partager la mme base de donnes.
Il peut exister plusieurs producteurs de la mme donne au sein du SI mais un seul propritaire garant de la cohrence.
En revanche, il sera trs certainement ncessaire de rconcilier ces deux fichiers, en dtectant et en liminant au passage les doublons, cest--dire les clients internationaux qui auraient t enregistrs la fois Paris et New York. On devra donc ncessairement nommer un propritaire de la donne client qui sera charg de ce travail, et fera ensuite redescendre sur nos deux applications le fichier client fusionn et nettoy des donnes ventuellement incohrentes.
5.2
Au del des problmatiques de formats, les consommateurs devront pouvoir identifier et qualifier les donnes qui leur sont proposes.
Consommateur
Il sagit de celui ayant besoin de salimenter en donnes provenant dautres applications. La trs vaste majorit des applications dun Systme dInformation organique sont donc consommatrices de donnes. Comme dans un supermarch, le consommateur de donnes doit rsoudre plusieurs difficults pour trouver son bonheur au sein du SI : Identifier les sources de donnes qui le concernent et lintressent ; Si plusieurs choix se prsentent, faire la bonne slection suivant les quatre axes de qualification de la donne et leurs enjeux pour le consommateur : disponibilit, consistance, utilisabilit et scurit ; Adapter les donnes slectionnes son propre besoin. Lorsque les sources de donnes sont nombreuses, lnergie dpense pour rpondre ces trois besoins peut devenir importante.
22
5.3
Validateur
Nous lavons vu ds le dbut de notre expos : la qualit est lenjeu clef de notre gouvernance de la donne. Cette qualit passe dans bien des cas par le respect des normes et nomenclatures en vigueur dans lentreprise. Il est trs difficile voire inutile de garantir de manire gnralise la qualit de toutes les donnes prsentes dans lentreprise, mais nous pouvons nous appuyer sur les formats de donnes publiques pour assurer nos contrles. Ds lors, le suivi de la qualit ne se fera plus sur lensemble des modles relationnels, ncessairement fortement htrognes, mais sur un format de donnes publiques parfaitement matris de manire transverse. Il nous faudra ainsi des gendarmes au sein du SI chargs de mettre en uvre ces contrles et dempcher la propagation de la donne ne rpondant pas aux critres attendus.
Le rle du validateur est essentiel pour faire merger la donne rpute fiable.
Le validateur sintressera aux aspects de la qualit que nous avons dj voqus, concernant la rsolution de conflits entre plusieurs sources de donnes : Conflit de schma lorsque les producteurs ne fournissent pas les donnes selon les formats attendus ; Conflit didentit par exemple si la mme entit apparat avec deux identifiants diffrents au sein de deux sources parallles ; Conflit de valeur lorsque, par exemple, ladresse dun client apparat diffremment selon deux producteurs. Nous constatons que selon les cas, le validateur devra purement et simplement rejeter la donne de mauvaise qualit ou bien se retourner vers les producteurs pour essayer de dterminer qui a raison. On comprend bien que lInformatique ne pourra pas rsoudre tous les cas, et que lintervention de lhomme sera souvent ncessaire.
Plus son travail est ralis la source, plus il sera efficace.
Le validateur sera ce responsable, la fois gendarme et huissier. Il peut globalement opter pour deux politiques : soit imposer la qualit la source, soit crer son propre systme aval de mise en cohrence. La premire approche est privilgier, mme si la seconde a prvalu jusqu aujourdhui, avec pour rsultat la cration de systmes de gestion complexes faible valeur ajoute.
5.4
Agrgateur
Lagrgation de donnes est bien entendu un rle essentiel dans un environnement multi producteurs et multi consommateurs. On peut dailleurs estimer que la plupart des applications participant aux changes de donnes devront assumer ce rle, ne serait-ce que pour leurs propres besoins de consolidation de donnes issues des producteurs auxquels elles sont relies. Par ailleurs, dans bien des cas, les producteurs de donnes vont mettre des donnes issues de leurs propres domaines de comptences, mais enrichies ou compltes de donnes issues dautres producteurs, agissant ainsi comme des agrgateurs.
Les fonctions dagrgation se retrouvent la fois chez le producteur et chez le consommateur.
Par exemple, un calculateur de risque financier pourra contribuer en diffusant les rsultats de ces calculs statistiques, mais enrichis par la description des contreparties concernes, les notations provenant des agences spcialises ou bien les limites dengagements assignes par les analystes de crdit.
23
Ces donnes agrges seront diffuses sous la forme de documents dont le format importe finalement peu. Il pourra sagir selon les cas denregistrements de fichiers plats, de fichiers XML, de documents lisibles par un humain ou tout autre format existant ou venir.
5.5
Distributeur
Lorsque le nombre de consommateurs et de producteurs est important, les contraintes techniques des changes deviennent prpondrantes. Certains acteurs du SI vont alors se spcialiser dans la distribution de la donne, cest--dire dans la gestion de la localisation des acteurs et lorchestration des changes de manire optimale en prenant leur compte une grande partie des contraintes de performances. Dans la pratique, les distributeurs seront souvent galement agrgateurs. Au-del de leur rle technique, ils prennent alors un rle fonctionnel. Ils deviennent de facto des acteurs ayant un fort besoin de localisation des gisements de donnes et de leurs consommateurs afin de prendre en compte une vision de bout en bout des supply chain de la donne dEntreprise.
24
VI. Des patterns pour urbaniser les Data Supply Chains

6.1 Urbaniser les changes bilatraux
Toute application du SI produit et consomme de la donne publique. Mais comment la propager correctement ? Une rponse simple serait de dire : communiquons ce que lon nous demande . Mais cette approche ractive prsente plusieurs risques dans la dure : En rpondant chaque demande, on cre autant de liens dapplication application, participant ainsi laccroissement de la complexit du Systme dInformation au risque de voir la qualit des donnes diminuer et les cots de maintenance augmenter ; Au niveau de lapplication, la maintenance des interfaces dextraction de donne devient un peu plus difficile chaque nouveau flux mis en place. Il deviendra rapidement impossible de modifier le modle de donnes publiques sans de lourds investissements. Une application ne peut pas, et ne doit pas, tout communiquer vers lextrieur. Elle devra donc choisir les donnes quelle rendra publiques, les formater et les documenter pour quelles soient exploitables par leurs consommateurs. Le pattern Royaume Emissaire est une rponse efficace ce besoin. Il consiste isoler dans une couche logicielle Emissaire lensemble des traitements techniques et fonctionnels permettant de traiter des changes avec lextrieur.
25
Un missaire permet de prserver la libert dvolution dune application tout en facilitant sa contribution au Systme dInformation.
Ce pattern semble facile mettre en uvre sur une application nouvellement cre, mais dans la pratique, on rencontre souvent des applications stratifies sur plusieurs annes dvolutions fonctionnelles et techniques. Dans ce cas, il nest pas rare de constater que chaque gnration de code introduit dans lapplication a galement mis en place sa mcanique dchanges avec lextrieur. Il devient alors ncessaire didentifier lensemble de ses changes avant de les reporter dans lmissaire, et de prserver le cur de lapplication (le royaume) de la mise en uvre des changes avec lextrieur. Le royaume pourra alors voluer son rythme, en modlisant en interne les donnes dont il a besoin de la manire la plus pertinente pour lui. Son missaire se chargera de lalimenter en donnes provenant de lextrieur et ventuellement dadapter les donnes internes au format dchange public.
6.2
Il peut y avoir une pertinence mutualiser certaines fonctions redondantes dans les missaires de chaque producteur et consommateur.
Urbaniser les changes multilatraux
Lobjectif de la gouvernance de la donne est daccrotre la fluidit et la qualit des changes entre les applications composant le Systme dInformation de lentreprise. A ce titre, nous devrons donc organiser les chanes dapprovisionnement depuis les producteurs de donnes vers leurs consommateurs. On peut en quelque sorte parler de supply chains de la donne. Ces supply chains vont faire intervenir un certain nombre dacteurs depuis la cration initiale de linformation jusqu son exploitation par un consommateur. Nous avons vu au paragraphe prcdent le cas simple dune supply chain producteur/consommateur, structure au travers du pattern royaume missaire. Intressons nous maintenant au cas o lon a plusieurs producteurs et plusieurs consommateurs simultans de la donne. Il sagit donc de faire communiquer un nombre, ventuellement important, dapplications. Bien entendu, il serait pertinent que ces applications disposent de leurs propres missaires afin que chacune dentre elles facilitent leurs changes leur niveau. Aujourdhui, ces rles ne sont pas distincts, et dans la plupart des cas, les producteurs et consommateurs assument tout ou partie de ces rles, avec de fortes redondances bien entendu :
26
Les diagrammes suivants proposent une architecture fonctionnelle pour cet Emissaire des missaires . Il sagit en quelque sorte dun hub dintgration de la donne lchelle du SI, et qui peut aider mutualiser les fonctions de validation, dagrgation et de distribution, auparavant dupliques au sein des diffrents producteurs et consommateurs :
Lmissaire des missaires industrialise le processus de mise en place des supply chains de donnes lchelle du SI, en respectant le caractre organique des applications.
27
Il est important de remarquer que ce hub peut potentiellement prendre en compte tout type de donne en implmentant les supply chains correspondantes. Il peut sagir selon les cas de donnes lmentaires diffuser en quasi temps rel, ou bien de gros fichiers plats contenant, par exemple, des rfrences clients, et qui seraient mises jour une frquence hebdomadaire, voir mensuelle. Dans les faits, il est souvent raisonnable de limiter la porte de tels hubs en les rapprochant des sources, et donc en les spcialisant, augmentant de fait leur nombre. Comme nous lindiquions, la proximit permet de mieux assumer le rle de validateur notamment.
28
Chaque royaume est bien isol de ses pairs grce son missaire. Ils possdent chacun leurs propres modles de donnes, probablement relationnels, qui ne nous intressent pas lchelle du SI. En revanche, le dialogue quils tablissent avec lmissaire des missaires, en production et consommation de donnes, est structur selon la formalisation de donnes publiques oriente document que nous avons prcdemment expose. Le hub dintgration concrtise pour sa part les Data Supply Chain en implmentant les fonctions correspondant aux rles assums par les acteurs de la donne : acquisition et publication, normalisation et moteur de requte. Acquisition et publication Il sagit dabsorber les flux de donnes provenant des producteurs. Il faut donc sadapter la version de format propose par lmissaire producteur, ainsi qu son canal de communication :
Le Hub doit tre en mesure de sadapter tous les mondes dchanges imposs aussi bien par les producteurs que par les consommateurs.
- batch ou temps rel ; - orient gros fichiers ou au fil de leau : - par mode update ou en annule / remplace On retrouve les mmes problmatiques de manire miroir dans le sens de la publication vers les consommateurs. L aussi, le hub devra sadapter aux possibilits des missaires quil a en face de lui. Normalisation Cette fonction concerne la transformation et ladaptation des formats de donnes. Elle sera implmente autour dun dictionnaire incluant aussi bien un historique des formats changs (par exemple sous la forme de schmas XML), que lhistorique des interfaces disponibles pour les acqurir et/ou les publier (par exemple un annuaire UDDI dans le cas dune infrastructure Web Services). De plus, puisque nous savons que linformatique ne pourra pas rsoudre tous les conflits de formats ou de valeurs, des consoles conues pour des oprateurs de nettoyage de la donne doivent tre prvues. Moteur de requtes Le moteur de requtes sera plus spcialement charg du filtrage et de lagrgation des donnes et de leur assemblage sous la forme de documents. Les requtes sexcuteront pour la plupart de manire automatise en fonction, soit de sollicitations provenant dmissaires autorises en mode pull , soit en mode push vers des listes dabonnements. En revanche, il ne sagit pas ici de crer un super Data Warehouse dentreprise disponible en mode infocentre pour une kyrielle dutilisateurs quips en outils de reporting sophistiqus. Si ce Data Warehouse doit exister dans lEntreprise, il sera un consommateur de notre hub, mais nen sera pas lpine dorsale.
29
Mettre en place ce type douvrage dans le SI ncessitera une justification conomique. Elle est complexe, et comme nous lindiquions en introduction, elle stend au primtre des mtiers o la non qualit de la donne gnre des cots oprationnels (rapprochements, ruptures de charge et manualisation au sens large) et inhibe des opportunits. Nous pouvons cependant insister sur plusieurs points :
Le Hub amliore la qualit mais doit galement rduire les cots de mise en uvre et de maintenance des supply chains de donnes.
le hub dinteroprabilit doit pouvoir justifier, par construction, dune garantie de service en production (SLA) bien sr, mais aussi en tudes : les cots et dlais de cration ou de maintenance des flux doivent tre matriss un rapport qualit/prix au moins gal aux cots unilatraux en vigueur avant la mise en place du hub ; le Hub dinteroprabilit nest pas forcment un ouvrage unique : selon les organisations, le pattern peut tre dploy plus aisment au travers dune fdration de Hubs, plus proches des exigences du terrain (regroupements par affinits fonctionnelles, organisationnelles, gographiques) ; le calcul dun ROI grosse maille est possible, et cest bien un niveau macroscopique quil faudra sen tenir tant lincertitude pse la fois sur lvaluation des cots actuels (oprationnels et informatiques, aucune comptabilit analytique ntant mme de les isoler), et sur lvaluation des bnfices.
30
VII. Une organisation pour la Gouvernance de la Donne

Avant de nous soulager par une partie technique des plus consensuelles, penchons-nous sur les problmes dorganisation que soulve lindustrialisation de la production et de la consommation de la donne dans lentreprise. Nous utilisons le terme gouvernance pour dcrire un ensemble de personnes qui composent une autorit pour administrer un thme donn. En ce sens, rien de trs nouveau par rapport au concept dorganisation matricielle, nous verrons seulement que cest la structuration de la donne qui impose les lignes de gouvernance.
Le processus de distillation de la modlisation des donnes publiques doit tre anim par des spcialistes mtiers proches des projets.
LONU reprsente une structure de gouvernance politique internationale centre sur le thme des Droits de lHomme. Notre sujet est la donne de lentreprise. Pour ladministrer nous aurons donc besoin de responsables de modles et sous-modles tels que dfinis dans la structure de modlisation. Nous appellerons ces responsables des data stewards . Ce sont des profils de type analystes mtier, comptents sur une zone donne de lorganisation et du SI laquelle ils sont attachs hirarchiquement : data steward structure analytique, clients corporate, feuille de soin, procurement, donnes didentit, etc. Au sein de leur division, ils sont responsables de la production et de la promotion des schmas de donnes publiques dans les projets. Aujourdhui rien ne relie ces personnes dans la plupart des organisations. Or leur travail doit manifestement tre homogne pour esprer crer une structure compatible. Nous aurons donc besoin dune autorit de liaison qui structure le travail des data stewards disperss dans lorganisation.
Une autorit pour supporter la cohrence du processus distribu de distillation.
Nous appellerons data board ce comit de gestion oprationnel qui exerce une autorit fonctionnelle sur les stewards. Le board est responsable du suivi de la propagation des standards dune part, mais aussi de la fourniture des mthodes et outils en support : structure principale de la donne, modlisation XML dtaille, outillage XML. Nous dvelopperons cette partie outil design time et outils runtime (EAI, ETL, cache de donnes, etc.) au dernier chapitre. Le rle de pilotage du board, le conduira se positionner sur un axe complmentaire celui de la modlisation, celui de la production effective de la donne. En effet, ce nest pas parce quun data steward est responsable des schmas de fiches identit reprsentatives des donnes de scurit sur les employs que ces donnes sont cohrentes mondialement dans les diffrents annuaires de scurit de lentreprise.
Au-del du recensement des modles, il est primordial didentifier les acteurs de la donne au sein du SI. Qui produit ? Qui consomme ?
Cest ici quintervient la notion de gisements de donnes et leur localisation. Notre volont tant de les rapprocher dans des fdrations consistantes, et pas forcment les fusionner tout prix, lubie souvent nave de lurbaniste informatique. Nous devons donc identifier partir des diffrents modles les gisements disponibles, leur primtre (ex. clients anglais uniquement), leur fracheur (donnes temps rel, donnes mensuelles valides), etc. Cette matrice de proprit dcrite au 4.4 permet un pilotage effectif de la production de donnes dans des fdrations cohrentes. Grce cet outil de pilotage, le data board dispose dindicateurs factuels sur la qualit de linformation de lentreprise. Il peut mener sa politique de dveloppement, rpressive ou incitative. Notre exprience tend prouver que le volet incitatif est rarement mis en place, alors quune simple prime linteroprabilit pourrait dbloquer beaucoup de situations
31
Les solutions techniques doivent nous permettre daugmenter notre productivit la fois en tudes et en production.
VIII. Exemples dimplmentation

Nous venons de voir dans les chapitres prcdents les enjeux de lintgration par la donne lchelle du Systme dInformation et les solutions fonctionnelles que nous devrons mettre en uvre pour y rpondre. Nous allons dsormais nous intresser aux solutions techniques disponibles aujourdhui, ou bien dans un futur proche, permettant dimplmenter ces architectures. Notre objectif est de positionner ces solutions par rapport au niveau de service quelles proposent leurs utilisateurs producteurs et consommateurs de donnes, tant au niveau Etudes quau niveau Production : SLA Etudes Nous ne devons pas oublier que le besoin fondamental de cette architecture est de permettre plusieurs applications ayant des rythmes dvolutions diffrents de maintenir des interfaces dchanges cohrentes, pour un cot rduit. Nos outils devront donc offrir une productivit significative pour la mise jour des formats dchanges ou la mise en place de nouveaux canaux de communication, et la maintenance de tous les dveloppements raliss. SLA Production Lintgration de donnes telle que nous ltudions ici concerne les activits stratgiques de lentreprise. Nous devrons donc prendre soin de mettre en uvre autant que possible des solutions prouves ayant dmontr le niveau de service quelles sont en mesure dapporter : disponibilit, temps de rponse, gestion des gros volumes
Dans les sections suivantes, nous tudierons successivement selon ces deux angles les outils disponibles pour rpondre nos besoins : Modlisation de la donne publique ; Mise en place dun missaire dchanges intgr une application, bti sur un socle de type EAP (Enterprise Application Platform) comme J2EE ou .Net ; Mise en place dun missaire dchanges ddi, bti sur un socle dchanges de type EAI ; Mise en place dun missaire dchanges ddi, bti sur un socle dchanges de type ETL.
32
8.1
Des outils pour la modlisation
Nous avons vu que la modlisation de la donne publique par lmergence dinvariants dentreprise est au centre de la dmarche de rationalisation de lintgration du SI. Il sagit de permettre la modlisation aise de structures de donnes orientes document, cest--dire XML. Les diteurs de schmas XML offrent aujourdhui des fonctionnalits avances dans ce domaine. Un outil tel que XML Spy dAltova sest positionn en leader grce sa facilit de prise en main dune part, mais galement par les diffrentes vues proposes pour diter les schmas et fichiers XML : Edition native XML, faon diteur de texte ; Edition XML oriente document ; Edition de schma XML, hirarchique.
Edition dun fichier XML en mode document dans XML Spy
33
Edition dune modlisation de donnes publiques (FpML) dans XML Spy Au niveau des applications, les outils de modlisation relationnelle ou objet classique peuvent tre utiliss pour faciliter la conception des bases de donnes privatives des applications. En revanche, dans le contexte dun systme dinformation organique , il serait utopique desprer concevoir un modle des donnes dentreprise relationnel ou objet lchelle de lentreprise. Dune part, la tche serait si complique que le rsultat serait dj obsolte ds que ce projet pharaonique aurait t achev. De plus, comme nous lavons dj expliqu, la modlisation oriente donne nest pas adapte la conception des formats publics, puisquelle oblige exporter entre applications la logique mtier qui permet de valider lintgrit de linformation.
8.2
Le pattern royaume/missaire sapplique aussi aux petites applications : on utilisera le mme socle technologique entre royaume et missaire, par exemple un serveur dapplication, ou mieux un progiciel dinfrastructure intgr.
Emergence dun missaire
Nous avons expos dans les chapitres prcdents le pattern royaume/missaire et les bnfices en attendre du point de vue de lintgration par la donne. Il existe bien entendu toute une palette doutils plus ou moins spcialiss qui permettent de nous aider dans limplmentation de cet missaire, cot de notre royaume applicatif. Nanmoins, pour bien des applications de taille modeste, ou bien en phase de stabilisation avant de passer en phase de croissance, il est tout fait envisageable dimplmenter lmissaire sur la mme plateforme technologique que lapplication. Dans bien des cas, lmissaire sera en fait la couche de communication de lapplication et sera donc inclus dans le mme cycle de dveloppement et de mise en production que le royaume contenant les rgles de gestion et la valeur ajoute mtier de lapplication.
34
Dans ce cadre, lmissaire sera instrument partir des outils mis disposition par les fournisseurs de plateforme technologique de type EAP8 : J2EE, .Net, AGL, 4GL, Mainframe, etc.
8.2.1 Architecture gnrale dun missaire EAP

Le schma suivant dcrit larchitecture gnrale dun missaire intgre une application J2EE ou .Net. Le cur de lapplication (le royaume) est constitu des couches classiques Prsentation, Domaine et Accs aux Donnes. Lmissaire, ddi la gestion de la complexit des changes entre le royaume et lextrieur, reprsente un module part entire, distinct des couches dimplmentation du domaine mtier de lapplication. En revanche, royaume et missaire partagent la mme couche de persistance des donnes.
Architecture gnrale dun missaire bti le socle EAP du royaume
8 : EAP : Enterprise Application Platform
Architecture de
35
Au niveau de la couche Donnes , il sera judicieux didentifier clairement les bases et tables associes aux donnes publiques donnes pouvant tre distribues lextrieur du royaume - des donnes prives, rserves lusage propre de lapplication. En effet, les donnes publiques seront de fait davantage contraintes dans leur volution, et il faudra donc prendre un soin tout particulier leur modlisation. On distinguera deux types de donnes publiques : Les donnes faisant partie du cur du domaine mtier de lapplication, et pour lesquelles lapplication sera probablement identifie comme un producteur potentiel pour la communaut. Les donnes externes, provenant dautres applications. Celles-ci peuvent tre aussi bien des donnes rfrentielles que des donnes oprationnelles servant alimenter les chanes de traitement de lapplication.
8.2.2 Les frameworks utiles aux missaires

Les diteurs ont bien compris que lintgration de donnes publiques est un des axes sur lequel nos Systmes dInformation peuvent encore samliorer. Sous le vocable Architecture Oriente Service , ils placent souvent toute une palette doutils et de technologies que nous pouvons utiliser avantageusement pour nous aider dvelopper nos missaires. Nous ne devons pas hsiter les utiliser, mme si les belles plaquettes publicitaires nous laissent parfois perplexes lorsque, pris par la pression du marketing, lditeur essaie de rinventer de nouveaux buzzwords qui finalement se ramnent toujours adresser la problmatique de lintgration au SI, linnovation portant surtout sur la souplesse amene par ces outils Nous donnons par la suite quelques exemples dutilisation de ces frameworks. Implmentation de la couche change : La couche dchange des donnes devra supporter les trois modes dchange suivants : requtes, notifications, changes de fichiers. Ces paradigmes de communication pourront simplmenter au dessus de diffrentes connectivits (SOAP, MOM, SQL, FTP..) adaptes aux diffrents producteurs et consommateurs externes. Par les facilits dintgration quils amnent, nous pourrons avantageusement utiliser les Web Services pour publier linformation aussi bien que pour la rapatrier : requtes, change asynchrone de documents, notifications de mises jour des donnes Il ne faudra pas non plus hsiter recourir aux mthodes de transfert de fichiers classiques que nous utilisons et matrisons depuis toujours, en particulier pour les changes de gros volumes ou traitements batchs : FTP, fichier partag par NFS ou SMB...
Le mapping relationnel vers objet est trs bien adapt limplmentation du domaine, mais moins pour celle de lmissaire.
Mapping Objet : Les diteurs ainsi que la communaut open-source travaillent sur de nombreux frameworks permettant labstraction du modle relationnel de la base de donnes, en modle objet utilisable par lapplication. La norme JDO dans le monde J2EE dispose dj de plusieurs implmentations. Dans le monde .Net, Microsoft devrait nous fournir le framework ObjectSpace remplissant le mme type de service.
36
Lapproche objet est par nature tout fait adapte limplmentation du domaine cur de lapplication. En revanche, pour la mise en uvre de lmissaire, elle peut introduire un niveau de complexit en ncessitant de faire la double transformation relationnel vers objet et objet vers XML . Moteur de requte XML intgr au SGBDR : En rponse ce besoin de transformation directe en relationnel et format orient document, on voit apparatre galement des frameworks permettant de simplifier le mapping des donnes relationnelles vers XML. Ceux-ci sont de plus en plus bas sur le langage de requte XML normalis par le W3C : X-Query.
Les tnors des SGBDR travaillent activement la mise en uvre de moteurs de requtes XML en complment de leur offre SQL.
Les principaux fournisseurs de SGBDR offrent aujourdhui des modules intgrs permettant daccder la base de donne relationnelle en la considrant comme un ensemble de documents XML. Ces systmes sont disponibles mais toujours en cours de maturation lheure actuelle. Nanmoins, ce que nous pouvons entrevoir des laboratoires des SGBDR tnors du march tels que Oracle ou Microsoft laisse penser que dici un trois ans, nous aurons notre disposition de vrais moteurs X-Query performants au dessus des bases relationnelles. Pour Microsoft, cette offre, connue sous le nom de code Yukon , fera partie intgrante de la future version de Windows Longhorn . Cette disponibilit au plus prs de lutilisateur final laisse envisager tout un nouvel univers dintgration transparente de la donne, depuis la donne dentreprise disponible sur les serveurs mtiers centraux et stratgiques, jusquaux documents non structurs disponibles sur le poste de travail et usage privatif. Framework dabstraction XML : Certains fournisseurs dEAP investissent galement le monde de lintgration de la donne par X-Query. Dans le monde J2EE, BEA propose par exemple via son offre Liquid Data une premire version de couche dabstraction de donnes par XML.
Loffre Liquid Data de BEA permet la mise en uvre rationnelle dun missaire intgr sur socle J2EE.
Lobjectif est dagrger de multiples sources de donnes, relationnelles ou non, pour les voir comme une source unique de documents XML accessible par X-Query. Cet agrgateur XML nous permet alors dimplmenter facilement un missaire qui serait charger dinterroger plusieurs producteurs de donnes en vue dalimenter notre application. On peut galement lutiliser en sens inverse pour publier au format XML les donnes mtier du cur de lapplication. On notera que BEA, tout comme les diteurs EAP leaders du march (Microsoft, Oracle, IBM), est particulirement actif pour amliorer ce type de produit, conscient quil sera lun des composants essentiels dune offre dinfrastructure intgre, incluant entre autre son serveur dapplication, son serveur EAI et son serveur de scurit.
37
8.3
Une approche plus industrielle de lmissaire
Les outils prsents prcdemment nous garantissent une mise en uvre particulirement aise dun missaire grce lintgration avec les ateliers de gnie logiciel standards fournis avec lEAP (Microsoft Visual Studio .NET ou BEA Workshop, par exemple) mais galement grce lintgration avec lensemble des composants et frameworks constituant loffre de lditeur. Pour un projet, la mutualisation des socles entre le royaume et lmissaire permet de capitaliser sur les outils, mthodes et la culture logicielle des quipes afin de pouvoir implmenter un missaire dans le cadre de ce projet, et publier la donne publique un nombre bien identifi de consommateurs. Nanmoins, sil sagit dune bonne approche tactique lchelle dun projet - nous avons bien parl d mergence dun missaire - on se retrouvera souvent confront aux problmatiques suivantes lchelle du SI : Il sagira gnralement de btir de nouveaux missaires en frontal de royaumes existants, loccasion de projets dintgration aux rythmes de vie dcoupls des rythmes de vie des royaumes. Lenjeu sera alors dinteroprer avec des environnements htrognes et plus ou moins obsoltes, dont les quipes projets auront t dissoutes, la documentation rarement mise jour (encore faut-il quelle existe !) Il sagira galement de distribuer la donne dun producteur vers N consommateurs, chacun avec ses rythmes et formats de consommations spcifiques : multiplicit des canaux techniques (SQL, Web Services, MOM, File, Legacy...), multiplicit des modes dchange (synchrone, fil de leau, batch), multiplicit des formats de donnes changes Dans des environnements o les changes de donnes reprsentent une forte criticit pour les applicatifs mtiers (tant sur la disponibilit des services dchange, les performances, les volumes, la qualit des donnes changes), lmissaire devra sengager garantir une qualit de service en production vis--vis des diffrents producteurs / consommateurs avec lesquels il interopre : on ne pourra plus sentendre dire le batch a plant, vous aurez vos infos demain si cette fois a ne plante pas ! Ainsi, pour un missaire et encore plus pour un Hub de donnes ou missaire des missaires , cf. 6.2 - adresser ces problmatiques lchelle dun SI se traduit par la mise en place dun socle dchanges industriel , contractualisant un SLA vis--vis des diffrents producteurs et consommateurs. Ce SLA, porteur de la crdibilit et de la prennit de lmissaire au sein du SI, devra se dcliner en deux axes : Un axe Etudes : il sagit de minimiser les cots et dlais de dveloppement, intgration, dploiement et maintenance dune nouvelle connectivit, dun nouveau flux, dune volution du modle de donnes, etc., tout en garantissant la qualit des dveloppements raliss en particulier par une mthodologie prouve de tests unitaires et dintgration. Un axe Production : il sagit de garantir la disponibilit des services proposs par lmissaire, les temps de rponse, les volumtries annonces, les modes dgrads et plan de secours, les services de monitoring des systmes et de supervision des flux.
Btir lmissaire sur le mme socle technique que le royaume : une bonne approche tactique, mais pas forcment stratgique.
Au niveau dun missaire ou dun Hub de Donnes, la plate-forme dchanges doit garantir et prenniser des niveaux de service levs, tant sur le dveloppement et la maintenance des flux (SLA Etudes) que sur lexploitation de la solution (SLA Production)
38
Il ny a pas de technologie unique pour implmenter un socle dchanges industriel Tout reste avant tout une affaire de mthodologie et dorganisation ! Nanmoins, nous pouvons dire que deux grandes familles de produits sont prdestines la mise en uvre de socle dchanges orients donnes : les EAI et les ETL.
8.3.1 EAI, ETL : Diffrences et complmentarits

EAI, ETL : deux technologies mtures et candidates pour un socle dchanges de donnes.
Historiquement ddis adresser le cas dusage n sources de donnes alimentant en mode batch un DataWareHouse , et reconnus sur ce cas dusage pour leurs performances et leur capacit absorber de fortes volumtries, les ETL intgrent dsormais des fonctionnalits qui leur permettent de venir chasser sur les terres du frre ennemi, citons par exemple : Une large gamme de connecteurs aux sources et cibles de donnes : SGBDR, fichiers (plats, XML), Web Services, bases legacy (Adabas, VSAM), progiciels (SAP, PeopleSoft, Siebel), bases multi-dimensionnelles Connectivit MOM (MQ-Series, JMS..) et selon les produits, EAI (Tibco RV, webMethods..) : le MOM ou lEAI est vu comme une source ou cible de donnes comme une autre, ce qui permet aux ETL dadresser dsormais un mode intgration au fil de leau , et non plus seulement le mode batch historique. Les afficionados de lEAI rtorqueront que dans les faits, le traitement des queues de messages reste gnralement une activit schdule par lETL ! Mais le dbat nest pas l, limportant pour lETL est de pouvoir adresser le traitement des messages, quil soit immdiat ou schdul toutes les x minutes. Des IDE productifs, orients drag-and-drop , avec de fortes capacits dintrospection des modles de donnes des systmes sources ou cibles, la dfinition graphique des rgles dagrgation de donnes, de jointure, de transformationCertains outils du march sappuient sur un rfrentiel centralisant et versionnant les dveloppements, les configurations des composants Nanmoins les ETL restent ddis aux modes dintgration par la donne, lintgration par le processus restant quant elle du domaine des outils EAI : routage et ordonnancement des messages, orchestration des processus, gestion des transactions courtes ou tendues, invocation dinterfaces applicatives Autant de fonctionnalits qui ne sont pas adresses aujourdhui par les ETL.
EAI vs ETL : le dbat sest dplac de batch vs fil de leau Intgration des donnes vs Intgration des processus
En revanche, ds quil sagira de rpliquer ou synchroniser des rfrentiels, agrger diffrentes sources de donnes dans un rfrentiel (oprationnel, dcisionnel) ou plus gnralement de distribuer la donne dun producteur vers plusieurs consommateurs, les ETL savreront des concurrents srieux des EAI, tant sur le plan des tudes que de la production. Dans certains cas, les ETL pourront mme prendre lavantage : cas o la majorit des traitements sont des batchs et o les changes au fil de leau sont minoritaires, batchs forte volumtrie, cas dusage traditionnel de consolidation dun DataWareHouse, besoin de services danalyse de la qualit et de nettoyage des donnes, etc. En synthse, pour les besoins purement techniques dintgration de donnes que ce soit en mode batch ou fil de leau- EAI et ETL seront concurrentiels, lETL pouvant mme facilement prendre lavantage sur lEAI. En revanche, ds que le besoin sera dassurer la gestion des transactions, la gestion des processus, limplmentation de rgles mtiers, etc., lavantage reviendra directement lEAI.
39
8.3.2 Un missaire bas sur un socle EAI

La figure suivante illustre larchitecture gnrale de notre missaire sur la base dun outil EAI (Tibco, webMethods, SeeBeyond, Microsoft ou BEA pour ne citer que les plus connus) :
Architecture gnrale dun missaire bas sur un socle EAI
40
On retrouvera, dans cette architecture, des services fournis par le socle EAI, et des services spcifiques lmissaire, btis ou non sur le socle EAI :
Trois modes dchanges avec lextrieur : requtes synchrones, notifications, batchs.
Des services de connectivit, prsentant aux producteurs et consommateurs des modes dintgration de type query (requtes synchrones pour rcuprer ou injecter de la donne lmissaire : SQL, Web Services), notification (publication dvnements entre lextrieur et lmissaire : triggers SQL, messages sur MOM..), batch. Ces services sappuient sur les connecteurs fournis par lEAI et sur des couches spcifiques de mapping des requtes, notifications, clatement en messages / regroupement des fichiers batch. Une couche de transport de messages interne lEAI, haut niveau de service (garantie de livraison, respect de lordre des messages). Une couche de traitement des messages, fortement dcouple des services de connectivit : cette couche traite un message sans savoir sil provient dune requte synchrone, dune notification, de la ligne #76000 du batch Cette approche permet de mutualiser les services situs au niveau de cette couche entre les diffrents canaux de distribution : services dagrgation, de transformation, de contrle, denrichissement des messages, services dordonnancement des messages... Un cache de donnes, permettant dabsorber les diffrences de rythme entre les producteurs et consommateurs, de garantir un temps de rponse aux consommateurs externes en vitant de solliciter systmatiquement le royaume, etc. Voyons en quoi ce type darchitecture permet damliorer les SLA de type Etudes et Production par rapport aux architectures de type EAP prsents prcdemment : Amlioration du SLA Etudes
Les EAI disposent denvironnements de dveloppement haute productivit pour les phases dtude : mode drag-and-drop, dveloppement dclaratif, versioning
Productivit des dveloppements : lors de lvolution ou mise en place de nouvelles chanes de connectivit et de transformation des donnes, toutes les configurations des connecteurs (SQL, Web Services, MOM, FTP, progiciels) ainsi que les dveloppements de mapping de messages seront raliss lintrieur de lIDE en mode drag-and-drop et dclaratif, accroissant ainsi fortement la productivit de dveloppement et de maintenance. Les rgles de transformation, chanes de transformation, formats dentre et sortie (pivots ou spcifiques producteurs, distributeurs, royaume) seront stocks et versionns dans le repository interne lEAI. Un repository ouvert, supportant XML, facilitera encore plus le pontage entre les formats internes loutil et les formats externes publics (invariants, donnes changes). En revanche, les services plus volus denrichissement, de contrle des donnes, dagrgation de plusieurs sources de donnes, jointures, etc., seront dvelopps en sappuyant sur le langage de dveloppement fourni par lIDE (Java, JavaScript, L4G), et non pas en mode dclaratif. Quant aux services centrs sur lanalyse de la qualit et le nettoyage des donnes, ils devront tre dvelopps en dehors du socle EAI car non fournis par ces outils.
Au sein dun EAI, les services spcifiques aux traitements des donnes (agrgation, jointures, nettoyage...) resteront nanmoins dvelopper.
41
Un framework et une mthodologie de tests permettront dassurer la qualit des dveloppements raliss au fil des diffrents projets dintgration ; ce framework pourra tre capitalis au niveau SI, entre diffrents missaires ou Hubs de donnes.
Qualit des dveloppements : les environnements de dveloppement pourront tre coupls un framework de tests et une mthodologie garantissant la qualit des flux et composants dvelopps, aussi bien au niveau des phases de dveloppement (tests unitaires, tests par bouchons ) que des phases dintgration et dhomologation (tests dintgration, tests fonctionnels, cas derreur, tests de stress). La mise en place dun tel framework sera dautant plus pertinente quelle sinscrira dans une dmarche de forte rutilisation, tant au niveau local (nombreux et rguliers dveloppements de flux au sein de lmissaire ou du Hub de donnes), quau niveau global du SI (rutilisation du framework et de la mthodologie pour dautres missaires, dautres hubs de donnes).
Amlioration du SLA Production

Haute-disponibilit, performances, supervision : les trois piliers de la qualit de service qui seront dclins en SLAs sur catalogue (gold, silver, bronze).
Haute-Disponibilit, modes dgrads : en fonction du SLA demand, chaque outil EAI du march pourra simplmenter sur des architectures de haute-disponibilit spcifiques, tant au niveau de la connectivit, du routage des messages ou de leur transformation. Attention toutefois aux points sensibles de la chane de liaison qui ne sont pas forcment les points forts de lEAI : les connecteurs fichiers par exemple, largement sollicits au sein dune plate-forme dchange oriente batch ! Temps de rponse, volumtrie, scalabilit, etc. : en fonction du SLA demand, il conviendra de sintresser non seulement au dimensionnement des composants du socle EAI (connecteurs, serveurs, pools et files de messages, etc.), mais galement lopportunit dutiliser un cache de donnes au niveau de lmissaire, afin dviter la sollicitation systmatique du royaume pour les accs en lecture ou criture. Plusieurs solutions seront alors possibles : base relationnelle, base relationnelle oriente XML, base XML native Quelque soit la solution retenue, attention tout simplement au codage et loptimisation des requtes qui peuvent rapidement devenir le goulot dtranglement du systme ! Supervision : les outils EAI sont gnralement dots de fonctionnalits de supervision permettant dassurer le suivi des flux, la relance des messages en erreur, le monitoring des composants systme Si loutil permet beaucoup de choses, noublions pas que lexploitation dune plate-forme dchanges requiert des comptences spcifiques et implique des procdures fort diffrentes de lexploitation dapplications transactionnelles : ici aussi tout sera question dorganisation !
Lmissaire pourra sappuyer sur un cache local pour optimiser et garantir les temps de rponse vis--vis de lextrieur.
8.3.3 Un missaire bas sur un socle ETL

Nous avons vu au paragraphe 8.3 les diffrences et complmentarits EAI-ETL. Nous proposons ici de btir un missaire sur une technologie ETL (Informatica, Ascential, SAS, Sunopsis pour nen citer que quelques uns). Larchitecture dun missaire bas sur un socle ETL reste assez proche de larchitecture dun EAI : couches de connectivit avec le royaume et lextrieur de lmissaire, couche de traitements, services de supervision, rfrentiel
42
La figure suivante illustre larchitecture technique gnrale dun tel missaire :
Architecture gnrale dun missaire bas sur un socle ETL
43
Les grandes caractristiques de cette architecture et diffrences par rapport lEAI sont les suivantes :
Les ETL sont centrs sur les traitements des donnes et non pas sur les traitements des messages. A lidentique des EAI, ils prsentent une couche connectivit, traitement, supervision et un environnement de dveloppement dclaratif .
Une couche de connectivit, offrant les mmes services que la couche de connectivit prsente dans le cadre dune architecture EAI ; il ny aura pas ici de services de mapping des requtes synchrones en messages ou de services dclatement des fichiers batchs en messages lmentaires, lETL prenant directement sa charge lextraction ou le chargement des donnes selon ces modes. Une couche de traitements, oriente donnes et non messages : agrgation de sources de donnes (relationnelles, documents XML), jointures, transformations entre modles de donnesDes services de profiling (mesure de la qualit des donnes) et de nettoyage des donnes sont gnralement intgrs aux ETL. On notera qu la diffrence de larchitecture EAI propose prcdemment, les traitements ne sont pas mutualiss entre les diffrents canaux daccs (query, notification, batchs), mais que chaque canal daccs dfinit ses propres chanes de transformation des donnes, selon un mode extraction aggrgation / transformation chargement. Pour le reste et comme pour le cas EAI, on retrouvera un cache de donnes pour optimiser les temps de rponse, des services de supervision (relance des batchs, supervision des chanes de traitement, supervision des composants techniques), un rfrentiel technique stockant les modles de donnes, les rgles de transformation, les configurations des composants de la plate-forme En ce qui concerne les SLA dEtudes et de Production que permet ce type darchitecture, ils seront du mme niveau que ceux offerts par une architecture EAI. Rien de surprenant, vu que lon utilise dans les deux cas des technologies ddies la gestion des changes Ici encore, tout reste une affaire de mthodologie et dorganisation ! Notons nanmoins les quelques points techniques suivants : Les IDE des ETL sont orients donnes la diffrence des IDE des EAI orients messages . Au sein dun IDE ETL, il sera ainsi ais danalyser des sources ou cibles de donnes, dfinir des rgles dagrgation, jointures, transformations, etc. Notons galement que les ETL apportent gnralement des services intgrs de profiling (analyse de la qualit des donnes) et de nettoyage des donnes qui ne seront donc pas dvelopper. Les ETL prennent classiquement bien en charge les traitements batchs en production : traitement de gros volumes, paralllisation des traitements et optimisation des ressources, ordonnancement, supervision et relance Bien que les EAI prsentent tous des connecteurs fichiers , des dveloppements supplmentaires et des procdures de supervision spcifiques seront mettre en place pour adresser ce mode de traitement avec le niveau de service dun ETL.
Suivant le produit choisi et son contexte dutilisation, lETL peut prendre lavantage sur lEAI tant au niveau du SLA Etudes quau niveau du SLA Production
44
45
IX. A propos dOCTO Technology

www.octo.com
OCTO Technology est le cabinet de Conseil en Architecture de Systmes dInformation du Groupe Aubay. Depuis sa cration en 1998, OCTO Technology publie le fruit de ses expriences et de ses recherches sous forme de livres blancs. Ils sont diffuss et diffusables gratuitement. Lide des fondateurs dOCTO Technology est de se consacrer exclusivement au mtier darchitecte, et de lexercer en toute indpendance, en quipes projet, et en fdrant des comptences. Son positionnement, de la stratgie technologique la conception et la mise en uvre de solutions innovantes, est principalement orient vers les grands comptes pour : Les assister dans le pilotage de leur systme dinformation Structurer et scuriser leurs projets par la mise en place de Bureaux dArchitecture oprationnels Tirer le meilleur parti des Technologies de lInformation et acclrer leur mise en uvre, grce notre expertise technique
Lactivit dOCTO Technology se structure en quatre grandes lignes mtier : Architecture de Systmes dInformation Architecture dIntgration Architecture dApplications Architecture de Scurit Enfin, OCTO Technology fonde sa stratgie sur une forte politique de R&D. Les rsultats des recherches et dveloppements dOCTO Technology donnent rgulirement lieu des sminaires et confrences au Cigref, Gartner Group, Clusif, EBG, Benchmark Group, XML Forum et font lobjet de nombreuses publications. Outre ces crits, la R&D des consultants OCTO Technology se traduit galement par lanimation ou la participation des projets Open source phares : Cactus (tests unitaires), Maven (plateforme dintgration), Raccoon (framework dintgration Tibco), etc.
46
2004 OCTO Technology. Tous droits rservs

Les informations contenues dans ce document reprsentent le point de vue actuel dOCTO Technology sur les sujets exposs, la date de publication. Tout extrait ou diffusion partielle est interdit sans lautorisation pralable dOCTO Technology. Les noms de produits ou de socits cits dans ce document peuvent tre les marques dposes de leurs propritaires respectifs.
Auteurs
Les auteurs de ce document sont des consultants OCTO Technology, par ordre alphabtique : Rmy Mathieu-Daud, Bernard Notarianni, Pierre Pezziardi. Merci toute lquipe Architecture de SI pour son support tout au long de la rdaction de ce document. Merci Lyonel Thouvenot pour la qualit du produit fini, et son prcieux coup de main apport entre deux biberons. Pour tous renseignements ppezziardi@octo.com complmentaires, veuillez contacter P. Pezziardi :
Bibliographie OCTO Technology :

Le Livre Blanc des Serveurs dApplications OCTO Technology 1999 Serveurs dApplications (ditions Eyrolles) Le Livre Blanc de lEAI OCTO Technology 1999 Intgration dApplications (ditions Eyrolles) Le Livre Blanc de lIRM OCTO Technology 2000 Le Projet e-CRM (ditions Eyrolles) Le Livre Blanc de la Scurit OCTO Technology 2001 Architectures de Systmes dInformation, Livre Blanc OCTO Technology 2002 Architecture dApplications, la solution .NET OCTO Technology 2003 Architecture de Systmes dInformation, Gouvernance de la Donne OCTO Technology 2004
47
48
49
50
51
OCTO Technology - 62 rue La Botie - 75008 Paris Tl : (33) 1 58 56 10 00 - Fax : (33) 1 58 56 10 01 - http://www.octo.com

Livre Blanc WP Gouvernance Donnee

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Livre Blanc WP Gouvernance Donnee

Transféré par

Droits d'auteur :

Formats disponibles

Architecture de Systmes dInformation Gouvernance de la donne Livre Blanc

Architecture de Systmes dInformation - Gouvernance de la Donne

Table des matires

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

Un ROI pour la gouvernance de la donne

1 : Service Oriented Architecture

Architecture de Systmes dInformation - Gouvernance de la Donne

Nouveaux besoins, nouveaux usages

Architecture de Systmes dInformation - Gouvernance de la Donne

Les leons de lhistoire

Architecture de Systmes dInformation - Gouvernance de la Donne

La donne, un lment de la gouvernance du SI

Scurit Analyste Spcifications de la scurit : identification, habilitations

Donnes Spcifications des donnes publiques et des donnes prives

Processus Cas dusage internes et externes

Fondations techniques de la persistance : lecture, criture, concurrence

Fondations techniques des changes : emballage, mission, rception Serveurs dchange

Serveur de stockage (cluster + SAN)

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

Une vision organique du Systme dInformation

Architecture de Systmes dInformation - Gouvernance de la Donne

Conclusion : cycles courts, cycles longs

Architecture de Systmes dInformation - Gouvernance de la Donne

II. Les enjeux : Qualit et Interoprabilit des donnes

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

III. La modlisation des donnes du SI

3.1.1 Modlisation relationnelle

Architecture de Systmes dInformation - Gouvernance de la Donne

3.1.2 Modlisation oriente Document

Architecture de Systmes dInformation - Gouvernance de la Donne

3.1.3 Une reprsentation hirarchique pour les donnes du SI

Architecture de Systmes dInformation - Gouvernance de la Donne

Identification des invariants dentreprise

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

Le cas particulier de la donne rfrentielle

Architecture de Systmes dInformation - Gouvernance de la Donne

IV. La proprit des donnes : une ralit organique

Architecture de Systmes dInformation - Gouvernance de la Donne

Axe des invariants du SI

Europe/France/Paris Europe/UK/Londres Amrique/USA/New York Amrique/USA/Chicago Asie/Japon/Tokyo

Architecture de Systmes dInformation - Gouvernance de la Donne

La matrice de proprit : un puissant outil de pilotage pour la gouvernance de la donne.

Axe gographique Europe Axe Invariants SI Paris Client

USA N.Y P/Q

Japon Tokyo P/Q

P/T P/M C/M P/Q C/Q P/T C/T P/Q

Architecture de Systmes dInformation - Gouvernance de la Donne

V. Structurer les changes : la Data Supply Chain

Architecture de Systmes dInformation - Gouvernance de la Donne

Plus son travail est ralis la source, plus il sera efficace.

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

VI. Des patterns pour urbaniser les Data Supply Chains

Architecture de Systmes dInformation - Gouvernance de la Donne

Urbaniser les changes multilatraux

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne

Architecture de Systmes dInformation - Gouvernance de la Donne