Plus que des mots: faire la lumière sur le désordre terminologique des données

Nous avons besoin de XYZ. Certainement. C'est dans tous les rapports d'analystes, c'est une tendance hors du commun, et nos concurrents l'ont aussi. Alors trouvons un vendeur qui l'a et investissons. Ça devrait le faire.

Semble familier? Espérons que les décisions d’investissement technologique dans votre entreprise ne soient pas prises de cette façon. Mais comme la technologie évolue plus rapidement que jamais, il est difficile de suivre toute la terminologie. Malheureusement, certaines personnes voient la terminologie comme une couche d'obscurcissement destinée à glorifier ceux qui l'inventent, à faire du battage publicitaire sur les produits et à faire paraître intelligents les gens qui lancent des termes.

Il y a peut-être une part de vérité là-dedans, mais cela ne veut pas dire que la terminologie est inutile. Au contraire, la terminologie est là pour répondre à un besoin réel, celui de décrire des concepts émergents dans un domaine en évolution rapide. Idéalement, un vocabulaire partagé devrait faciliter la compréhension des différents concepts, segments de marché et produits.

Exemple concret: la gestion des données et des métadonnées. Avez-vous déjà entendu les termes gestion des données, observabilité des données, data fabric, data mesh, DataOps, MLOps et AIOps? Mais savez-vous ce que chacun d’eux signifie exactement et comment ils sont tous liés? Voici votre chance de le découvrir.

Couches de données

Bien que nous soyons actifs en tant qu'analystes dans le paysage plus large des données, nous avouerons que tout ce qui précède n'était pas non plus tout à fait clair pour nous. Ainsi, lorsque nous avons rencontré Maarten Masschelein et Tom Baeyens, nous avons décidé de leur demander leur avis. Masschelein et Baeyens sont les co-fondateurs de Soda, une startup qui vient de remporter le prix « Cool Vendor in Data Management » du Gartner.

En plus d'être officiellement proclamés cool, il y a une autre raison pour laquelle ils savent peut-être une chose ou deux: ils ont été là. Masschelein était l'employé numéro cinq chez Collibra, qui a été, selon ses propres termes, le premier à vendre des logiciels aux Chief Data Officers – avant même que cela n'existe. Baeyens a été fondateur et chef de projet chez jBPM, un projet open source légendaire de gestion des processus métiers (BPM).

Commençons avec tissu de données. Masschelein considère cela comme un cadre permettant d'organiser les données à grande échelle: une méta-couche permettant d'accéder à toutes les données pertinentes pour une organisation, où qu'elles se trouvent, de manière unifiée.

Une structure de données se concentre sur l’aspect technologique de cet accès unifié aux données.

Maillage de données est un concept similaire mais différent dans le sens où il se concentre sur les aspects organisationnels. Masschelein estime que le maillage de données s'apparente à une version modernisée des principes de gouvernance des données, applicable à des équipes de données plus larges. L’objectif est de structurer et d’organiser, en supprimant certains des goulots d’étranglement du passé, comme le recours à une équipe d’entrepôt de données. Masschelein a dit :

"Avec le maillage de données, il s'agit essentiellement de créer des produits et des services de données. Il s’agit donc d’une réflexion sur les produits de données. En gouvernance des données, on parle de gérer les données comme un atout. Quand on parle de gestion des données en tant que produit, c’est finalement plus précis. C'est cette idée que nous devrions avoir des services de plateforme de base. Mais en plus de cela, nous devons avoir une structure autour des domaines de données, des domaines, des activités, de l'expertise et des connaissances, leur permettant d'être en libre-service. Je pense que c'est la clé".

Gestion de données«, a ajouté Masschelein, est un terme qui existe déjà depuis de nombreuses décennies. Il a été largement décrit par le association de gestion de données, qui a beaucoup travaillé sur la façon dont les données doivent être gérées. En fin de compte, une partie de cela était la gestion des métadonnées, qui a donné naissance à des logiciels de catalogage de données et à des capacités de traçage des données.

Masschelein voit la surveillance des données, observabilité des données, et tests de données en tant que sous-domaines spécialisés de la gestion de la qualité dans le cadre plus large de la gestion des données. Baeyens a ajouté du contexte sur l'observabilité des données :

"Vous avez des ingénieurs qui construisent des pipelines de données. Ils préparent les données à utiliser dans des produits de données, tels que des modèles d'apprentissage automatique. De nombreux ingénieurs développent régulièrement de nouveaux produits. Une fois que ces produits entrent en production, c'est là que commence l'observabilité. C’est là que les données pourraient se détériorer. Si les modèles utilisant les données ne remarquent pas que les données sont mauvaises, cela entraîne toutes sortes de conséquences très coûteuses et dangereuses. »

Surveillance des données, tests, fitness et collaboration

Pour ce qui est de Opérations de données, il s'agit d'utiliser des capacités liées aux données, organisées selon des processus de bonnes pratiques, pour fournir des produits de données à une vitesse croissante, le tout avec une fiabilité accrue. De nombreux petits processus doivent être mis en place et standardisés pour permettre de mieux travailler avec les données, à l'instar de ce que nous avons fait avec DevOps en génie logiciel, a déclaré Masschelein.

MLOps, qui semble être utilisé de manière interchangeable avec AIOps, repose sur une bonne base DataOps mais est plus spécialisé. Dans DataOps, nous ne surveillerons pas la précision des prédictions, par exemple. Cela est spécifique au produit de données et également au cycle de vie du produit de données. Masschelein y réfléchit du point de vue du cycle de vie :

"Ce sont deux choses distinctes car le cycle de vie d'un ensemble de données n'est pas étroitement lié au cycle de vie de l'apprentissage automatique ou d'un produit de données, en fin de compte. Il y a aussi différentes personnes qui font cela. Lorsqu'il s'agit de gérer les données et les DataOps, nous avons des producteurs de données qui peuvent être externes à l'organisation, et vous avez des données générées en interne.

Une autre façon de voir les choses est le paysage de l’outillage. Et si vous regardez la pile logicielle de surveillance et d’observabilité, nous avons l’infrastructure au bas de l’échelle. Donc d’abord, nous écrivons des applications, puis aujourd’hui nous utilisons les données et l’apprentissage automatique comme deux types de nouvelles couches. »

Nous commençons tout juste à utiliser des logiciels et des plates-formes pour aider à surveiller ces couches relativement nouvelles, alors que les autres existent depuis bien plus longtemps, note le duo. Et c’est là que la propre plateforme de Soda entre en jeu. Le nom est né parce que les fondateurs aimaient l’idée de problèmes de données silencieux qui bouillonnaient, comme les sodas pétillants. Soda couvre donc la surveillance, les tests, l’adéquation des données et la collaboration.

La surveillance consiste à surveiller automatiquement les ensembles de données pour détecter les problèmes. Cela signifie essayer de déterminer s'il y a quelque chose d'anormal dans les ensembles de données qui atterrissent dans vos environnements. Par exemple, environ combien d’enregistrements avez-vous traités cette fois-ci? Est-ce anormal par rapport à ce qu’il y a eu le même jour la semaine dernière? Soda peut utiliser l'apprentissage automatique pour détecter des anomalies, par exemple.

Mais la surveillance ne couvre qu’un petit pourcentage des types de problèmes de données que vous pouvez rencontrer. C'est pourquoi le test et la validation des données constituent la prochaine étape. C'est ici que vous activez à la fois les ingénieurs de données et les experts en la matière. C'est ici que des règles telles que « Nous ne pouvons avoir que X pour cent de données manquantes dans cette colonne », « Nous avons besoin d'intégrité référentielle » ou « Un ensemble de valeurs autorisé » peuvent être spécifiées.

C'est très bien, mais si vous disposez d'un système de découverte des problèmes de données, il créera de nombreuses alertes. La question est donc: comment gérez-vous les alertes? Quel est le processus commercial que vous suivez? C’est là qu’interviennent les tableaux de bord d’état des données. Cela permet le suivi des SLA, donnant aux propriétaires de données une vue de toutes les attentes concernant les données dans l'ensemble de l'organisation et un flux de travail autour de la résolution des problèmes.

Enfin et surtout, la collaboration est une préoccupation transversale. Disposer de fonctionnalités de collaboration permet à des personnes ayant des connaissances différentes sur le problème, qui ont souvent des connaissances tacites et non documentées, de travailler ensemble et de résoudre les problèmes. Baeyens a mentionné que cela touche également à des fonctionnalités qui ne sont pas traditionnellement considérées comme de la collaboration, comme permettre aux analystes de gérer eux-mêmes les connaissances du domaine sans impliquer les données ingénieurs.

Mousses et sodas

L'expertise en BPM que Baeyens apporte à Soda a été mise à profit dans la construction de la plateforme, en particulier dans la façon dont les différents modules s'articulent dans une progression de flux de travail. Soda fonctionne avec les sources SQL et l'intégration de Spark est presque là. L’objectif est de pouvoir couvrir autant de données que possible.

Soda ne couvre peut-être pas tous les piliers clés d'une structure de données complète selon la définition de Gartner, mais là encore, il est difficile d'imaginer de nombreuses solutions qui le feraient. Il augmente cependant les catalogues de données, en se concentrant sur DataOps. De plus, soda cible différents segments d’utilisateurs, et cela se reflète également dans son offre.

Il existe une couche open source destinée aux ingénieurs de données. Baeyens estime que le segment des utilisateurs n'est pas forcément intéressé par une offre SaaS. Soda SQL open source vise à être simple et à travailler avec la technologie que son public cible aime utiliser – SQL et YAML, selon Baeyens.

Soda SQL connaît une bonne croissance et une bonne adoption, et c'est un moyen pour les gens de faire connaissance avec Soda. Cependant, s'ils aiment ce qu'ils voient et que leurs besoins augmentent pour inclure des personnes telles que des analystes et des CDO, alors il est temps de passer à la version SaaS payante de Soda.

L'entreprise a récemment a reçu 11,5 millions d’euros en financement de série A, ce qui, combiné à leur précédent financement d'amorçage, donne un total d'environ 14 millions d'euros. Cela devrait fournir à Soda une bonne piste pour développer son offre, dans le but de développer à la fois les équipes d'ingénierie et de mise sur le marché.

Les fondateurs de Soda semblent avoir une solide compréhension du paysage dans lequel ils opèrent, au moins.