« Alors, tu l’as enfin ? »
« Quoi ? »
« Ben ton Data Hub !!! »
« Ah oui c’est génial, on l’a implémenté direct après notre Datalake !!!: »
« Mais du coup c’est quoi les bénéfices ? »
« … »
« Bon d’abord, imagine le Datalake, quoi ! »
« … »
« … »
« … »
« On a mis plein de trucs dedans donc on peut faire plein de choses avec hein ! »
« Genre quoi ??? »
« Ben genre des trucs quoi… Et que t’imagines pas… »
« … ??? »
Il est amusant de constater que notre métier est souvent constitué de « buzz words » parfois mal maîtrisés. Ces termes accompagnant l’émergence et l’adoption de technologies plus ou moins novatrices ; ainsi en va-t-il des technologies du Big Data et de l’implémentation de ces fameux Data Lakes et Data Hubs.
Mais de quoi parle-t-on au final? Certes de nouveaux moyens ou outils technologiques permettent de dépasser certaines limitations (performance…) ou d’abaisser certains coûts (stockage…) ; ce qui peut donc changer certaines manières de travailler et de concevoir différemment certaines solutions, mais sans remettre en cause ce qui les caractérise vraiment : leurs fonctionnalités et l’apport aux utilisateurs métiers.
C’est ce que l’on oublie souvent, notamment parce que l’on peut les voir comme de véritables modes : « Il faut que je mettre en place mon Data Hub », parce que c’est la tendance du moment ; l’« initiative » peut même être « vendue » aux interlocuteurs métiers parce que tout le monde en parle, mais pour quelles fonctionnalités et bénéfices ?
Car les hubs de données n’ont pas attendu l’arrivée du Big Data pour exister ; les architectures liées à l’intégration de données opérationnelles existent depuis longtemps et se doivent de recouvrir plusieurs fonctionnalités en fonction de la maturité de la solution et l’implication des acteurs métiers :
- Centralisation des flux de données : d’un point de vue architectural, c’est bien évidemment le premier objectif d’une approche Data Hub. On passe du fameux plat de spaghetti constitué de flux en connexion directe entre des systèmes à une approche centralisée, avec des demi-flux entrants et des demi-flux sortants. Ces demi-flux peuvent être réalisés en mode « push » ou en mode « pull », relativement aux systèmes considérés.
- Stockage : pour répondre à une stratégie de demi-flux et également à certains besoins d’historisation, la persistance des données doit être assurée dans le Data Hub. Cette persistance peut évidemment dépendre d’une certaine « durée de validité » de la donnée par rapport au(x) processus métier(s) qui la porte(nt). On pourra s’appuyer également sur un concept « Data Lake » pour cette couche, afin de minimiser les coûts de stockage. Les différents « étages » d’un Data Lake seront mis en place afin de distinguer notamment les données brutes entrantes des données transformées (cf. ci-après) en sortie, voire de permettre leur accès et leur exploitation directe par les métiers.
- Consolidation de la donnée : un tel système centralisé ayant vocation à porter l’ensemble des échanges opérationnels, c’est l’occasion de définir l’ensemble des objets métiers dans une perspective globale et universelle ; la définition des objets devient unique pour tout le monde et l’ensemble des systèmes ; les particularités de chaque système fournisseur étant prises en compte et chaque système consommateur « piochant » les attributs voulus dans cette vision complète et adaptés en sortie aux besoins en aval. Il est donc important de pouvoir qualifier les objets métiers relativement à des clefs métiers pour assurer une telle consolidation. Et l’on reconnaitra pour les données de référence les concepts de MDM et de Golden Record, qui peuvent potentiellement être portés par un Data Hub en l’absence de système MDM.
- Suivi et traçabilité : il est essentiel de s’assurer que toutes les données en transit soient correctement ingérées et transmises de manière à garantir la cohérence des données entre elles, en sortie du Data Hub, afin de garantir la fiabilité des processus métiers en aval.
- Gouvernance de la donnée : un autre objectif, avec la centralisation et donc la simplification des flux, est de redonner la main aux acteurs métiers quant à aux échanges, la fiabilisation et la propagation de leurs données. Même si l’implémentation d’un Data Hub peut être vue comme une « simple » refonte technique d’un existant, l’implication des métiers et la mise en place d’une réelle gouvernance de la donnée ne pourra qu’éviter de dévoyer petit à petit le nouveau système, à cause d’initiatives trop locales et isolées, qui ne pourront conduire qu’à un « resilotage » des données.
Commentaires récents