Data Mesh, Data Fabric et Knowledge Graphs : comment traiter les données pour générer des profits ?

Pendant de nombreuses années, ces données proliférantes ont été regroupées dans des data lakes. Les données ont été extraites de diverses sources, transformées en fonction d’une nouvelle structure, puis chargées dans un data warehouse central pour être synthétisées et analysées afin d’obtenir des informations exploitables. À un moment donné, la quantité de données impliquées (et l’effort nécessaire pour les extraire) est devenue intenable et le meilleur en matière de technologie des données s’est déplacée vers les data fabrics et les data meshes.

Définition grossière : un data mesh signifie propriété et gestion décentralisées des données, tandis qu’une data fabric est plus centralisée avec une couche unifiée pour l’accès aux données. Un data mesh est un ensemble de principes, un modèle de mise en œuvre ; une data fabric est plutôt une construction de connaissances. Il peut sembler que ces deux concepts soient opposés, mais ce n’est pas le cas. La plupart des opérations de données réussies mettront en œuvre une approche hybride, combinant les principes de la data fabric et du data mesh tout en superposant des architectures knowledges graphs pour trouver des informations essentielles.

Pour libérer le potentiel de revenus latents des données internes, il faut comprendre précisément comment ces éléments s’emboîtent et comment tirer parti de leur puissance combinée pour accéder à des informations commerciales transformatrices.

S’attacher aux faits

À l’heure actuelle, trop d’entreprises déploient une approche dépassée. Dans cette approche, chaque fois qu’une application est créée, elle doit être connectée à toutes les sources de données existantes. En général, ce travail incombe au développeur, qui doit ensuite interpréter toutes ces sources de données, rester au courant de leurs fluctuations et maintenir les interprétations des données à jour. Le problème, c’est que les développeurs n’ont pas été formés pour cela : ce n’est pas leur domaine d’expertise et cela crée un réel risque potentiel de gouvernance. Cette interconnexion à forte intensité de main-d’œuvre sert également à ralentir l’ensemble du système, qui fonctionnera inévitablement au rythme de sa composante la plus lente.

Une approche plus sage, qui utilise des architectures knowledge graphs en tandem avec le data mesh et la data fabric, consiste à reproduire non pas les données, mais les faits. Les entreprises ne doivent isoler que les points de données utiles pour répondre à une requête donnée. En d’autres termes, ce qu’ils devraient rechercher, ce n’est pas les données elles-mêmes, mais une carte de ces données, car c’est finalement tout ce dont on a besoin pour exécuter des analyses pertinentes.

C’est là qu’intervient l’architecture knowledge graphs. Superposée au combo data mesh - data fabric, elle peut fournir une carte ontologique et sémantique des données, en les façonnant à des fins utiles et rentables.

L’intérêt majeur des knowledge graphs

Par analogie, tournons-nous vers l’industrie pharmaceutique. Les sociétés pharmaceutiques doivent être en mesure de générer des réponses rapides et complètes à toutes les questions qu’elles pourraient se poser sur un médicament. Les enjeux sont élevés, compte tenu du risque de préjudice pour les patients et de mesures réglementaires ou de problèmes juridiques ultérieurs. Mais les paradigmes actuels en matière de données rendent difficile la production d’informations sur les drogues de haute qualité et exploitables.

Pourquoi ? En l’occurrence, tout est dans le nom – ou, plus précisément, dans les noms. Le cycle de vie d’un médicament qui arrive sur le marché est long avec d’innombrables étapes distinctes : recherche, essais, certification FDA, fabrication, commercialisation, suivi post-approbation, etc. À chacune de ces étapes, le médicament en question peut être déposé sous un nom de code, un numéro de projet, un numéro de dossier ou une marque nominative différents. Par exemple, le médicament peut avoir cinq noms différents dans cinq entreprises différentes, et 10 noms différents au sein d’une entreprise car il est commercialisé sur différents marchés. Les fabricants de médicaments ont besoin d’une vue à 360 degrés de ces données pour prendre de bonnes décisions et éviter toute responsabilité, mais lorsque les données dont ils ont besoin pour répondre correctement à une requête sont (par exemple) une couche supérieure de leur modèle, ils sont contraints d’opérer à partir d’informations impartiales et potentiellement trompeuses.

C’est là qu’interviennent les knowledge graphs – ils vous permettent de combiner des ontologies disparates et d’examiner les informations. Cela est important pour de nombreuses raisons, notamment parce que cela élargit l’éventail des personnes qui peuvent exécuter des requêtes complexes. Il n’est plus nécessaire de maîtriser les meilleures pratiques SQL pour obtenir des informations importantes.

Les implications en termes de revenus sont importantes. Quel que soit le secteur d’activité. Par exemple : les fabricants. À l’heure actuelle, de nombreux fabricants se concentrent moins sur l’acquisition de nouveaux clients et plus sur l’optimisation des revenus des clients existants. Dans ce contexte, le déploiement correct des architectures knowledge graphs peut aider à signaler des éléments tels que des remises inappropriées ou le potentiel d’augmentation de l’IPC. Cela augmentant ainsi facilement les bénéfices avec un minimum de dépenses supplémentaires.

Se focaliser sur les objectifs

Ainsi, quelle est la meilleure approche pour les entreprises souhaitant réorganiser leurs opérations de données en ce sens ?

Il faut penser en termes de données plutôt que d’applications, rechercher des solutions intégrées et créer une culture d’entreprise centrée sur les données.

Ce dernier point est important. Trop souvent, les initiatives de données s’enlisent dans la « plomberie » et deviennent effectivement des projets informatiques déconnectés des objectifs commerciaux plus larges.

Illustrons cela avec une histoire – une histoire composite, mais qui est loin d’être invraisemblable.

Un grand fournisseur de soins de santé décide qu’il veut enquêter sur des incidents de décès dans des ambulances en route vers la salle d’urgence. Une recherche sans fin commence et après un an d’efforts incalculables, une équipe de 20 personnes parvient à répondre à la question. Ils apportent leur réponse aux supérieurs, qui, déconcertés, les interrogent sur le nombre de ces mêmes cas dans lesquels un ambulancier était à bord. L’enquête redémarre. Six mois plus tard, ils reviennent avec leur réponse – et on leur demande dans combien de cas un défibrillateur était à bord. Enquête à nouveau. Six mois plus tard, une autre question de la part des supérieurs : l’ambulancier à bord était-il formé à l’utilisation du défibrillateur ? Cette fois-ci, pas d’enquête : l’équipe informatique abandonne tout simplement.

Ce projet – et les nombreux autres projets similaires qui sont entrepris chaque jour – a été mené par des développeurs plutôt que par des scientifiques des données. Il n’était pas centré sur l’entreprise et ne déployait pas les types d’architectures knowledge graphs décrits ci-dessus. Ce qu’il souligne, c’est l’importance de créer une véritable culture des données, d’exploiter les gestionnaires de données, de modéliser correctement les données et de lutter contre l’informatique lorsque les objectifs de l’entreprise sont en jeu.

L’objectif ultime ici est la fluidité. Il faut pouvoir adapter vos données à tout moment en fonction de l’évolution des besoins métiers. Ceci pour répondre le plus rapidement possible à de nouvelles questions sans forcément avoir à faire intervenir l’informatique. Les données internes, correctement exploitées, peuvent être une source fantastique de croissance et de revenus, mais seulement lorsque l’on dispose d’une vue des données à 360 degrés. C’est ce que peuvent offrir le data mesh et la data fabric, rendus vivants par des architectures knowledge graph.