La structure organisationnelle idéale du DataOps

Les communications externes d’une organisation tendent à refléter ses communications internes. C’est ce que Melvin Conway nous a enseigné, et cela s’applique à l’ingénierie des données. Si vous n’avez pas d’équipe chargée des opérations de données (« DataOps ») clairement définie, les sorties de données de votre entreprise seront aussi peu crédibles que les entrées.

Les opérations de données sont le processus d'assemblage de l'infrastructure nécessaire à la génération et au traitement des données, ainsi qu'à leur maintenance. C'est aussi le nom de l'équipe qui fait (ou devrait faire) ce travail - les opérations de données, ou DataOps. Que fait DataOps ? Eh bien, si votre entreprise gère des pipelines de données, lancer une équipe sous ce nom peut apporter un élément d’organisation et de contrôle qui fait défaut autrement.

Les DataOps ne s’adresse pas uniquement aux entreprises qui vendent leurs données. L’expérience récente a prouvé que vous avez besoin d’une équipe chargée des opérations de données, quelle que soit la provenance ou l’utilisation de ces données. Client interne ou client externe, aucune différence. Il vous faut une équipe pour construire (ou soyons réalistes, hériter puis reconstruire) les pipelines. Ce devraient être les mêmes personnes (ou, pour de nombreuses entreprises, la même personne) qui mettent en œuvre des outils d’observabilité et de suivi et qui surveillent la qualité des données à travers ses quatre attributs.

Et bien sûr, les personnes qui ont construit le pipeline devraient être les mêmes que celles qui reçoivent l’alerte redoutée de PagerDuty lorsqu’un tableau de bord est en panne, non pas pour les accabler mais pour qu’elles en tirent des leçons. Lorsqu’ils sont concernés, les gens construisent différemment. C’est une bonne incitation qui permet de mieux résoudre les problèmes et de les régler plus rapidement.

Enfin, cette équipe des opérations de données a besoin d’une mission qui transcende la simple « migration de données » du point A au point B. Et c’est pourquoi le terme « Opérations » est si important.

Pour déplacer les données, les opérations de données mettent en place des processus résilients en fonction de l’objectif prévu. Tout déplacement de données doit avoir une raison. Souvent, cette raison est le chiffre d’affaires. Si votre équipe chargée des opérations de données n’est pas en mesure d’établir un lien clair entre cet objectif final, par exemple permettre aux équipes commerciales d’améliorer leurs prévisions et d’augmenter leur chiffre d’affaires, et leurs activités de gestion du pipeline, vous avez un problème.

En l’absence d’opérations, des problèmes apparaîtront au fur et à mesure que vous évoluerez :

• Duplication des données
• Collaboration difficile
• Données en attente
• Des pansements qui laisseront des cicatrices
• Problèmes liés à la découverte
• Outils déconnectés
• Incohérences de journalisation
• Manque de processus
• Absence d’appropriation et d’accords de niveau de service

S’il y a un décalage, vous pratiquez simplement l’ancienne gestion des données. La gestion des données est l’aspect routinier de la maintenance des opérations liées aux données. Bien que cruciale, elle n’est pas stratégique. Lorsque vous êtes en mode maintenance, vous recherchez la raison d’une colonne manquante ou d’une défaillance du pipeline et vous la réparez, mais vous n’avez pas le temps de planifier et d’améliorer.

Les véritables « opérations » interviennent lorsque vous transformez les tickets d’incident en correctifs reproductibles. Imaginez, par exemple, que vous trouviez une erreur de transformation provenant d’un partenaire et que vous lui envoyiez un e-mail pour la corriger avant qu’elle n’atteigne votre pipeline. Ou que vous placiez une bannière « alertes » sur le tableau de bord de vos dirigeants qui leur indique quand quelque chose ne va pas, pour leur indiquer qu’il faut attendre la mise à jour. Les opérations des données, tout comme les opérations des développeurs, visent à mettre en place des systèmes reproductibles, testables, explicables et intuitifs qui, en fin de compte, réduisent les efforts de tous.

Il s’agit des opérations de données par opposition à la gestion des données. La question qui se pose alors est la suivante : comment structurer cette équipe chargée des opérations de données ?

Revenons donc à notre point de départ, à savoir comment les résultats de votre système reflètent votre structure organisationnelle. Si votre équipe d’opérations des données n’a d’opérationnel que le nom, et qu’elle se contente principalement d’assurer la maintenance, vous accumulerez probablement un nombre toujours plus grand de demandes en attente qui ne sera jamais résolu. Ainsi, vous aurez rarement le temps pour des opérations de maintenance à long terme, par exemple pour remplacer un système ou ajuster un processus. Vous êtes bloqué dans les méandres des réponses Jira ou ServiceNow.

Si, au contraire, vous avez fondé (ou relancé) votre équipe chargée des opérations de données avec des principes et une structure solides, vous produisez des données qui reflètent la qualité de votre structure interne. De bonnes structures d’équipe d’opérations des données produisent de bonnes données.

Prenez un ingénieur en traitement de données, un data scientist et un analyste dans un groupe ou un « pod » et demandez-leur de résoudre ensemble les éléments qu’ils auraient pu gérer séparément. Invariablement, ces trois perspectives conduisent à de meilleures décisions, à moins de tergiversations et à plus de prévoyance. Par exemple, au lieu d’avoir un data scientist qui échange des notes écrites avec le seul ingénieur, au risque de générer des échanges sans fin, on peut imaginer que ces deux personnes collaborent avec un analyste pour définir les besoins avant que l’ingénieur n’indique la démarche à suivre pour parvenir à leurs fins.
De nombreuses équipes chargées des opérations de données travaillent déjà de cette façon. « Les équipes doivent avoir pour ambition d’avoir une pile complète en termes de personnel, afin que les talents nécessaires en ingénierie des données soient disponibles pour avoir une vision à long terme de l’ensemble du cycle de vie des données », affirment Krishna Puttaswamy et Suresh Srinivas chez Uber. Et sur le site de voyages Agoda, l’équipe d’ingénieurs utilise des pods pour la même raison.

Faites-le même si vous êtes le seul membre de l’équipe. Chaque rôle est un « chapeau » que quelqu’un doit  porter. Pour avoir une équipe chargée des opérations de données performante, il est utile de savoir quel chapeau est à quel endroit, et qui est le propriétaire des données et dans quel but. Vous devez également réduire la marge de manœuvre de chaque individu à un niveau gérable. Cette approche pourra peut-être plaider en faveur de nouvelles embauches.

Qu’est-ce que la gestion de l’équipe chargée des opérations de données ? C’est un niveau de coordination au-dessus de vos structures de pod, qui joue le rôle de leader à votre service. Il gère les projets, les supervise et les déverrouille. Idéalement, ce sont les personnes les plus compétentes de l’équipe.

Nous avons créé notre propre structure idéale, bien que ce soit un processus permanent. Ce qui est important à noter, c’est qu’il n’y a qu’une seule personne à la tête qui a une vision des données (le vice-président). Au-dessous d’eux se trouvent plusieurs dirigeants qui guident les différentes disciplines des données vers cette vision (les directeurs), et au-dessous d’eux, des équipes interdisciplinaires qui veillent à ce que l’organisation des données et les fonctionnalités des données fonctionnent ensemble. (Merci à notre architecte de solutions de données, Michael Harper, pour ces idées.)

Le choix d’un indicateur de référence permet à toutes les personnes impliquées de comprendre ce qu’elles sont censées optimiser. Sans un tel accord, vous vous exposez à des litiges. Vos « clients » des données internes se plaignent peut-être de la lenteur des données. Mais si elle est lente, c’est parce que vous savez que leur désir inavoué est d’optimiser d’abord la qualité.

Indicateurs de référence communs aux DataOps : qualité des données, automatisation (processus reproductibles) et décentralisation des processus (autonomie de l’utilisateur final).

Une fois que vous avez un niveau de référence, vous pouvez également décider de sous-indicateurs ou de sous-principes qui pointent vers cet objectif, qui est presque toujours un indicateur retardé.

Organisez l’équipe de sorte que les différents groupes au sein de celle-ci doivent interagir fréquemment et demander des choses à d’autres groupes. La valeur de ces échanges peut être tout simplement exceptionnelle. « Lorsque les data scientists et les ingénieurs comprennent comment l’autre travaille, ces équipes évoluent plus vite et gagnent en productivité », explique Amir Arad, directeur technique senior chez Agoda.

Amir estime que l'une des valeurs cachées d'une petite redondance inter-fonctionnelle est que les gens posent des questions que personne dans l'équipe n'avait pensé à poser.

« Ce manque de connaissances en ingénierie est en fait plutôt cool. Ça peut les amener à nous demander de simplifier », explique Amir. « Ils peuvent dire : « Mais pourquoi ne pouvons-nous pas faire ça ? » Et parfois, nous revenons en arrière et réalisons que nous n'avons pas besoin de ce code ou de ce serveur. Parfois, les non-experts nous apprennent de nouvelles choses. »

Comme pour le DevOps, les meilleures équipes chargées des opérations de données sont invisibles et travaillent sans relâche pour disparaître en coulisses. Au lieu de jouer le rôle du héros, qui finit par fragiliser le système, incarnez le leader opportun. Visez, comme l’a dit Lao Tzu, à mener les gens vers la solution de manière à les amener à réfléchir : « Nous l’avons fait nous-mêmes. »

Traitez votre équipe chargée des opérations de données comme une équipe produit. Étudiez votre client. Conservez un carnet de correctifs. L'objectif est de rendre l'outil suffisamment utile pour que les données soient réellement utilisées.

Il n’est jamais trop tôt pour la surveillance et l’observabilité des données. L’analogie qui est souvent utilisée pour justifier le défaut de surveillance est la suivante : « Nous construisons l’avion en vol ». Visualisez ce concept. Cela ne résume-t-il pas ce que vous devez savoir pour exister sur le long terme ? Une analogie bien plus pertinente serait celle de la bonne vieille architecture. Plus vous attendez pour poser une fondation, plus son installation coûtera cher et plus l’absence de fondation posera problème.

Lire : Qu’est-ce que l’observabilité des données ?

Les décisions que vous prenez aujourd’hui concernant votre infrastructure de données « résonneront dans l’éternité », comme l’a dit le général Maximus. Le growth hacking d’aujourd’hui est le cauchemar gargantuesque de demain, source de chaos dans les systèmes internes et de transformation des données. Vous devez obtenir le soutien de l’exécutif pour prendre des décisions gênantes mais justifiées, comme dire à tout le monde qu’il faut suspendre les demandes parce que vous avez besoin d’un trimestre pour régler les problèmes.

CASE (copy and steal everything) signifie « copier et tout voler », une façon ironique de dire qu’il ne faut pas tout créer à partir de zéro. Il existe aujourd’hui de nombreux microservices et offres open source utiles. Grimpez sur les épaules des géants du secteur et concentrez-vous sur la construction des 40 % de votre pipeline qui ont réellement besoin d’être personnalisés, en faisant les choses bien.

Allez jeter un œil aux tickets en attente. À quelle fréquence réagissez-vous aux problèmes au lieu de les prévenir ? Combien de problèmes que vous avez traités avaient une cause racine clairement identifiable ? Combien avez-vous pu en corriger de manière permanente ? Plus vous prévenez, plus vous ressemblez à une véritable équipe d’opérations de données. Un outil d'observabilité des données vous sera d'autant plus utile. Une visibilité totale peut vous aider à passer d'une simple maintenance à une amélioration active.

Les équipes qui améliorent activement leur structure améliorent activement leurs données. L’harmonie interne conduit à l’harmonie externe, dans une connexion qui rendrait fier Melvin Conway.

En savoir plus sur la plateforme d’observabilité continue des données d’IBM Databand et sur la manière dont elle aide à détecter les incidents de données plus tôt, à les résoudre plus rapidement et à fournir des données plus fiables à l’entreprise. Si vous êtes prêt à aller plus loin, réservez une démo dès aujourd’hui.