3 questions pour les contrats de données

Shane Murray a contribué à cet article.

Mon co-fondateur a été all-in sur les contrats de données depuis le début.

Pour ceux qui ne connaissent pas le concept d’ingénierie de données émergent le plus en vogue de 2022, les contrats de données sont conçus non seulement pour résoudre, mais aussi pour prévenir les problèmes de qualité des données qui découlent de modifications de schéma inattendues et de submersions de données.

Nous avons rédigé un guide d’introduction plus détaillé, mais les contrats de données impliquent essentiellement de travailler avec des consommateurs de données pour développer le schéma et les exigences sémantiques des pipelines de données de niveau de production, puis de fournir ces données pré-modélisées à l’entrepôt de données.

Selon Barr, ce nouveau paradigme de qualité des données aide les équipes d’ingénierie des données à mieux s’aligner sur l’entreprise en plaçant les exigences des consommateurs de données au premier plan. Elle accorde un poids énorme à la voix du client.

Je ne pense pas qu’elle se trompe, mais pour moi, ingénieur logiciel passé et présent, il reste trois questions ouvertes auxquelles il faut encore répondre pour déterminer si les contrats de données seront une solution miracle ou une fausse panacée.

Question #1 : Pouvez-vous trouver le bon équilibre d’incitations ?

Les incitations déterminent le comportement humain. Les mandats descendants autoritaires peuvent également fonctionner, mais l’application d’un comportement non naturel a toujours un coût élevé pour le moral, l’efficacité et la concentration de la direction.

Il est beaucoup plus efficace d’avoir une réponse à la question séculaire, « qu’est-ce que cela m’apporte? »

La réponse est assez évidente pour les ingénieurs de données qui n’auraient plus besoin de se démener chaque fois qu’un changement de schéma inattendu rompt un pipeline de données clé. Pour les autres membres de l’équipe de données – les consommateurs de données de puissance dans les rôles de science des données et d’analyse – les avantages de données de meilleure qualité dans un entrepôt de données mieux organisé sont également clairs.

Mais qu’en est-il pour ceux qui possèdent et gèrent les services produisant les données ? Les ingénieurs logiciels ? Les administrateurs Salesforce ? Dans la plupart des organisations aujourd’hui, non seulement les incitations ne sont pas alignées, mais il existe d’énormes silos organisationnels et des structures hiérarchiques disparates.

Les équipes d’ingénierie des données et d’ingénierie logicielle sont presque toujours isolées les unes des autres, et la réalité est que trop souvent les données (et l’ingénierie des données) sont des citoyens de seconde classe. En effet, traditionnellement, les données étaient uniquement exploitées pour les outils de BI, effectuées hors ligne et ne stimulaient pas l’activité, du moins pas dans la même mesure.

En d’autres termes, l’équipe d’ingénierie logicielle a tout le pouvoir et aucune des incitations pour adopter des contrats de données comme un autre ajout à leur flux de travail déjà encombré.

N’oubliez pas qu’ils sont déjà les « bénéficiaires » d’autres initiatives que nous avons déplacées vers la gauche, telles que la cybersécurité et la gouvernance. Je peux dire d’expérience qu’en plus ruban rouge les flux de travail et les étapes d’approbation en dehors de notre domaine d’expertise et les KPI ne sont pas populaires.

D’après l’expérience de mon collègue et ancien vice-président principal des données du New York Times, Shane Murray, « Avec toute initiative de décalage à gauche (par exemple, confidentialité / RGPD), nous devions démontrer pourquoi elle est précieuse au-delà des autres priorités des équipes d’ingénierie logicielle , et nous devons fournir les outils pour faciliter les choses, y compris des boucles de rétroaction qui montrent qu’ils réussissent tout en économisant du temps et des efforts.

Réponse possible : technologie et processus

Cette friction inhérente peut être exactement ce qu’une plate-forme de contrat de données pourrait être conçue pour résoudre. La technologie et les processus ne sont pas une incitation en soi, mais ils peuvent les faciliter.

Par exemple, GoCardless tire parti de la technologie et des processus CI/CD pour fournir à ses producteurs de données une autonomie accrue (démarrage automatique de l’infrastructure et d’autres ressources nécessaires) au sein de son système de contrat de données. L’automatisation réduit les obstacles, accélère les flux de travail et applique les politiques.

Question #2 : Pouvez-vous amener les gens à ralentir ?

Lorsqu’un changement de schéma est nécessaire, quelqu’un doit ralentir.

Soit c’est le producteur de données qui doit attendre que les mises à jour appropriées soient apportées aux systèmes de données en aval, soit c’est l’équipe d’ingénierie des données qui doit réparer un pipeline cassé après que la modification a été apportée.

L’hypothèse inhérente à un système de contrat de données est que le premier est plus précieux (ou peut-être moins douloureux) que le second. La réalité est que cela dépendra du coût du temps d’arrêt des données dû à la rupture des changements de schéma par rapport au coût des opérations de retardement liées à l’intégration du nouveau schéma.

Vous pouvez même créer une équation lâche pour cela :

Mais même si nous aimerions résoudre ce problème avec des exemples clairs et des mathématiques dures et froides, le monde réel a tendance à exister sur un spectre plus flou.

Peignons un scénario hypothétique dans lequel une architecture de contrat de données fonctionne exactement comme prévu. Le Sales Kickoff arrive la semaine prochaine et le CRO et le CFO ont besoin que l’équipe des opérations de vente modifie considérablement l’organisation de Salesforce afin de démontrer leur nouvelle stratégie révolutionnaire de mise sur le marché.

Ils en ont besoin au plus vite. L’équipe SalesOps vérifie ou est avertie que leurs modifications vont casser les schémas remplissant les tableaux de bord qui prennent en charge les AE dans la région nord-ouest. Arrêtent-ils ce qu’ils font ? L’organisation voudrait-elle qu’ils fassent une pause ? Peut-être. Peut être pas.

Encore une fois, vous pouvez voir comment la technologie pourrait réduire le temps nécessaire pour préparer les systèmes de données pour un nouveau changement de schéma. Cependant, les contrats de données ne sont pas seulement des registres de schémas, ils définissent également la sémantique.

Avec tout le respect que je dois à notre futur souverain suprême GPT-3, la création et la mise à jour de la logique, du sens et de l’objectif de l’entreprise est encore largement un goulot d’étranglement humain. Cela a été l’un des principaux obstacles à l’adoption du catalogue de données pendant des années.

Réponse possible : les données sont promues

Il y a la carotte et puis il y a le bâton. Personne ne veut être celui qui pousse le mauvais code et interrompt la production. Cette même urgence n’est pas présente pour une mise à jour de service qui pourrait mettre un tableau de bord hors ligne pendant quelques heures.

Au fur et à mesure que les systèmes de données évoluent de plus en plus vers des cas d’utilisation opérationnels – par exemple, réadapter les passagers bloqués pour citer un exemple de l’industrie du voyage – cela changera à mesure que les données deviendront un citoyen de première classe.

« J’ai vu des équipes de données amener les ingénieurs logiciels à se soucier de la qualité des données – généralement dans des équipes plus petites et interfonctionnelles – en sensibilisant aux utilisations en aval des données », a déclaré Shane. « Mais faire évoluer cela à environ 50 équipes de produits contribuant au même schéma d’événement ? C’est une question très ouverte.

Réponse possible : Choisissez vos batailles

« Il existe un principe dans l’ingénierie de la fiabilité des sites pour éviter de rechercher plus de fiabilité que ce qui est strictement nécessaire, et vous pouvez voir comment ce principe s’applique aux contrats de données », a déclaré Shane.

« Si le produit de données est essentiel aux opérations commerciales ou à l’expérience du produit, la qualité des données émises devient alors aussi importante (ou plus) que d’autres fonctionnalités et le contrat est primordial. Les exemples ici seraient les rapports financiers et certaines (mais peut-être pas toutes) les applications d’apprentissage automatique de production », a-t-il poursuivi. « Si les données sont un avantage secondaire, il n’est pas toujours pratique de faire obstacle au lancement d’un produit. Obtenir une visibilité sur le changement de manière à pouvoir adapter les pipelines en aval peut être l’approche la plus viable. »

Question #3 : Les consommateurs de données peuvent-ils prévoir et exprimer avec précision leurs besoins ?

C’est peut-être ma plus grande réserve et question ouverte. Si vous louchez, vous pouvez voir comment les contrats de données sont une autre forme de test de données.

L’un des plus grands changements de paradigme de l’observabilité des données, et la raison pour laquelle il a résonné auprès de tant d’équipes d’ingénierie des données, est l’incapacité des humains à définir à quoi les données devraient ressembler et à anticiper leur comportement (le problème des inconnues inconnues).

Les tests de données restent un élément important de la pile de fiabilité des données, mais même si nous pouvions anticiper chaque type de test dont nous avons besoin, ils sont impossibles à mettre à l’échelle efficacement. C’est une tâche bien mieux adaptée aux moniteurs d’apprentissage automatique.

Donc, si les professionnels des données ont du mal à maintenir les tests de données et à documenter la sémantique des actifs de données, pouvons-nous nous attendre à ce que les consommateurs de données réussissent ? L’expérience pratique invite au moins à la prudence.

« Les analystes de données/scientifiques ajouteront souvent manuellement de nouvelles données, interpoleront ou extrapoleront les données manquantes », a déclaré Shane. « Parfois, c’était parce qu’ils ne pouvaient pas demander aux équipes en amont de collecter ces données, mais tout aussi souvent, c’était imprévu ou en cours de test. pour sa valeur. »

Oui, les consommateurs de données connaîtront mieux les données. Oui, il est facile de voir comment la technologie peut combler les lacunes techniques d’une partie prenante de l’entreprise, mais peut quelqu’un définir et anticiper les formes que les données devront prendre ? C’est comme essayer de définir la forme de l’eau ou espérer qu’un vêtement sera à la mode pour toujours – au mieux, ce n’est qu’un moment dans le temps.

Réponse possible : espérez le meilleur, découplez-vous pour la réalité

Les contrats de données sont utiles pour traiter des quantités connues, où la précision a une vérité terrain qui peut être garantie.

L’expérience de GoCardless a montré que, au moins dans certains cas, les consommateurs de données n’ont peut-être pas besoin d’apporter trop souvent des modifications au contrat. Il peut être possible de maintenir un ensemble limité d’attentes pour les données sur une période de temps fermée. C’est particulièrement le cas avec les pipelines de production où les données reflètent le monde réel, comme le nombre réel d’expéditions effectuées, ou une métrique cruciale en contact avec le client qui EST la fonctionnalité.

« Il doit y avoir un éventail entre les solutions de fortune (demander simplement aux ingénieurs de données de corriger les changements de schéma de rupture toute la journée) et attendre la perfection des producteurs de données », a déclaré Shane. « Une façon d’y parvenir est de créer des données…