Le « Data Hub » épine dorsale de la flexibilité

D’après un article publié le 8/2/2016 sur « value-architecture »

A noter qu’il peut y avoir de nombreuses définitions d’un « Data Hub » voir par exemple.

Le Data Hub (au sens strict donné ici) est l’épine dorsale d’une architecture flexible.

Il est constitué par :

  • des composants non techniques, que l’on peut voir sous forme de « services de données« , instanciant 2 figures de style :
  • une « couche d’intermédiation« , fonctionnelle et technique, qui permet :
    • d’accepter les divers protocoles des différents mondes techniques, avec la mise en forme et la compréhension des différents modes d’échange (ESB, échanges fichiers, messages, API,…)
    • d’étendre ces interfonctionnements au monde NoSQL, aux Big Data, au Cloud, via un socle technique,
    • de corriger les différences de latence dues à ces modes d’échange (batch, message, service),
    • de détecter les erreurs d’identification et de synchronisme,
    • de normaliser certains échanges pour les rendre conformes à un modèle générique, en stabiliser le modèle, éviter la dispersion d’échanges spécifiques,
    • d’instituer les échanges au niveau du grain le plus fin,
    • de gérer la sécurité,
    • de publier des flux ou services d’intérêt public,
    • d’appliquer des contrats de données (contrats de dépôt, d’abonnements, de diffusion à un périmètre du SI), sous différentes formes (échanges directs, en flux de message, en stocks, en différentiel, anonymisé, filtrés),
    • de gérer la mise en qualité des données, en relation avec les domaines source de ces données,
  • une « couche d’intelligence » pour orchestrer les échanges, répartir les flux (ces fonctions peuvent aussi être situées en dehors du Data Hub, il s’agit alors d’interfonctionner avec elles).
  • des fonctions de service : pilotage, statistiques, sauvegarde, restauration, sécurité, reconfiguration sont aussi indispensables pour compléter le Data Hub.

Le Data Hub est une solution pratique pour répondre aux sept principes d’Urbanisme des systèmes énoncés par R. Mandel (avril 2016).

Les autres composants d’un SI, en dehors du Data Hub, sont :

  • les moteurs de complexité et d’alignement réglementaire (paie, liquidation, moteurs de marketing, logistique, comptabilité, finances, …)
  • les usines de données (Data Lake, OSB, …)
  • les portails et extranets,
  • les visions 360,
  • les diverses plateformes (mobilité, IoT…).
Data Hub-2
Schéma de principe sur la composition et l’insertion d’un Data Hub

Le design d’un Data Hub adapté au cas de l’Entreprise, et à son évolution stratégique, est fortement créateur de valeur. Il est la clé de la flexibilité. Par exemple, un Data Lake (voir « Puits et Data Lake« ) est un entrepôt brut, neutre pour l’Architecture. Le Data Hub est, par contre, au centre de l’Architecture, son épine dorsale, et doit être conçu en tant que tel.

Le Data Hub crée un Lego systémique :

  • il peut s’étendre par adjonction de nouveaux modules (puits, référentiels), sans remise en cause les modules existants,
  • les composants hors architecture s’associent au Data Hub en utilisant les divers modes d’interfonctionnement.

Le design d’un Data Hub, dans l’approche « Architecture Flexible » est fortement lié à l’analyse des chaînes de valeur (voir Trame Business).

La mise en place d’un Data Hub est primordiale pour diminuer les risques d’un projet SI. Elle est à la base d’un Projet Flexible.