Executive summary

Dans la plupart des entreprises, les données empruntent des routes tortueuses depuis les systèmes sources jusqu’à leur usage finaux. La faute à une multiplication des technologies, à une inflation incontrôlable des volumétries.

Les équipes data s’échinent à extraire, ingérer, déplacer, nettoyer, intégrer, agréger les données pour pouvoir adresser les use cases du business. Mécaniquement, se créent des « pipelines de données » qui deviennent vite inefficaces et sujets aux erreurs : les données sont traitées par différentes technologies, sautent de système en système, elles sont répliquées à l’infini, ou encore oubliées dans un coin.

Les réutilisations de données, et la factorisation des process sont l’exception. Aussi, le business attend des temps infinis ses réponses, pourtant urgentes.

La dataOps promet de rationaliser le processus de création, de modification et de gestion des pipelines de données, au service d’une véritable data governance.

Son objectif principal est de maximiser la valeur qui peut être extraite des données et d'améliorer la satisfaction du métier.

Comment ? En accélérant la livraison des données et en en optimisant la qualité, pour répondre à ce triple objectif : « mieux, plus vite, moins cher ».

Il est possible de voir la dataOps comme des méthodes de travail couplées à des approches techniques. Une première brique essentielle vise à comprendre le transport et l’usage de l’information et à mettre en place un référentiel centralisé à jour en se désengageant au maximum des interventions humaines. Il est ensuite possible d’obtenir une documentation précise des données : origine, devenir, usages. C’est de ce deuxième point dont ce docuement traitre.

http://ellipsys-bi.com

A propos de l'auteur

Samuel Morin, le fondateur d'Ellipsys, a mis en place de nombreuses plateformes Analytics dans les plus grandes entreprises françaises pendant les premières années de sa carrière.

Il a rapidement noté l'augmentation exponentielle du volume des données et de la complexité des systèmes due aux nouveaux besoins commerciaux, aux nouvelles exigences réglementaires, et à la volonté louable de démocratiser l'accès aux données.

Au départ, les analyses étaient essentiellement manuelles et empiriques. Mais cette méthode a une grande limite : dès que l’analyse est opérée, que des correctifs sont mis en œuvre, les pathologies des systèmes réapparaissent inéluctablement.

Il paraissait nécessaire d'automatiser tous les processus, de créer des robots (parsers / sondes) pour auditer les systèmes en continu, et adresser ainsi des use cases de plus en plus nombreux.

Le logiciel openAudit était né. Plusieurs personnes ont rejoint le projet en 2016.

La société Ellipsys est basée au Luxembourg. Elle compte les plus grandes banques luxembourgeoises dans son portefeuille clients, ainsi que quelques grands acteurs de la distribution en France.

Les enjeux de la dataOps

Un rapide constat

Les systèmes d’informations sont de plus en plus complexes, car hétérogènes et massifs. Les besoins métiers de plus en plus pressants.

Si les solutions de gouvernance de données garantissent la fiabilité de l’information et remettent au cœur de l’entreprise la gestion de la data, ces solutions restent principalement déclaratives et nécessitent une organisation qui accompagne des tâches souvent redondantes à faible valeur ajoutée, avec d’innombrables écueils.

Notre approche pose comme préalable à toute démarche de « data governance » ambitieuse, l’intérêt d’une cartographie centrale fine, partagée, automatisée, définissant en temps réel le cheminement de la donnée et ses usages.

Notre vision de la dataOps

DataOps est l’abréviation de data et d’opérations. C’est un ensemble de pratiques et de technos permettant de délivrer des réponses analytiques (dashboards, analyses adhoc, jeux de données pour des modèles d’apprentissage).

La dataOps applique les méthodes du développement logiciel à la création de modèles de données, des sources opérationnelles à leur consommation.

L’objectif est de faire plus vite, mieux et moins cher, et ainsi valoriser au maximum les données, par l’adhésion du business.

La dataOps s'inspire du mouvement de devOps dans le développement logiciel qui utilise divers outils de cadrage de code, de test, et des outils collaboratifs pour mutualiser les développements, accélérer les déploiements. La devOps impose une collaboration entre les équipes de développement, réseau, sécurité pour accélérer les cycles de développement / intégration en réduisant les risques de non-qualité.

De même, la dataOps doit rassembler toutes les parties prenantes des données -architectes, data engineer, data scientists, data stewards, data analysts, développeurs, utilisateurs d’outils analytics - pour créer des solutions de bout en bout, d'une manière agile et collaborative.

Mais tout cela reste théorique, car au-delà de la méthode qui suscite l’adhésion, il est primordial de rendre possible cette ambition. Une méthodologie « agile », une forte intégration collaborative, la création d’environnements de test incontournables, ne seront bien souvent pas suffisants pour créer les conditions d’une pleine réussite.

Nous pensons que, libérées des tâches chronophages et récurrentes, les équipes data peuvent se mobiliser massivement sur des sujets où leur intelligence et leur discernement sont indispensables, et ainsi avancer factuellement vers une meilleure data governance.

Besoin d’une stratégie dataOps ?

Une courte liste, non-exhaustive, qui indique un potentiel besoin de mis en œuvre d’une stratégie dataOps au service de la data gouvernance. Bienheureuses les équipes qui n’ont traversé aucunes de ces problématiques !

- La hot line équipe data est inondée de tickets de demandes mineures.

- Les utilisateurs métier constatent régulièrement qu’il y a des erreurs dans les données qu’ils exploitent

- Les projets innovants, typiquement les analyses prédictives, sont retardées faute de disponibilité des équipes.

- Chaque modification de flux de données depuis les systèmes sources chamboulent les projets d’exploitation et d’exploration de données.

- L’inertie est importante entre les besoins du métier et les réponses IT, avec la création de pipelines « anarchiques » depuis les directions métier. L’IT est de plus en plus régulièrement by-passée, avec en corollaire, des risques croissants d’incohérence et de sécurité.

- Ces pipelines de données non maîtrisés impliquent des variations mineures avec des conséquences potentielles majeures : il n’y a plus une vérité, mais des vérités.

- La complexité du « legacy system » bloque les projets de migration de solution à solution, ou plus encore des migrations vers le cloud.

- Les projets « compliance » type GRPR, Bâle III, sont mal adressés techniquement.

Approche méthodologique

Nous opérons par scanning permanent de tout le système Analytics et des solutions environnantes, en rentrant dans l’hyper détail des systèmes.

La démarche est originale, car elle est technique et dynamique.

Certains grands éditeurs proposent des approches qui paraissent exhaustives. Nous en connaissons les innombrables effets de bords : intégrations fastidieuses, formations chronophages, tarifs rédhibitoires, pour n’en citer que quelques-uns.

Mais surtout, certains composants de ces solutions fonctionnent uniquement de façon déclarative, ce qui impose à des « data stewards » ou autres « data engineers », de remettre l’ouvrage sur le métier à longueur d’années, dans la mesure où l’ambition est d’avoir une vision objective des choses.

Notre approche consiste à apporter quelques briques « élémentaires » qui peuvent permettre de bâtir une véritable stratégie dataOps.

Nous pensons qu’il est pertinent de mettre à disposition des équipes un référentiel de métadonnées qui définisse finement et en continu les principaux attributs de chacune des données d’un système analytics : origine et devenir, étapes de transformation intermédiaires, usages (qui l’utilise, quand, comment).

De ce fait, nous n’ambitionnons pas d’apporter des réponses stéréotypées hyper orientées « use cases », mais avec quelques réponses élémentaires, les équipes métier / business peuvent potentiellement adresser un grand nombre de problématiques plus vite, et mieux. C’est peut-être ça fondamentalement la dataOps. En plus d’être objective, cette information est accessible, intelligible, partagée.

En somme, nous préférons la boite de Lego qui laisse l’inventivité, la créativité aux équipes techniques ou métier, à la solution pré construite, dont on attendrait qu’elle puisse traverser les mers ou atteindre la lune.

Par ailleurs, notre approche technique tient en un mot : automatisation, pour que les « snapshots » délivrés soient continuellement à jour, que les équipes puissent construire leurs réponses sur des bases solides, puisque factuelles

Notre véritable métier est donc de construire des parsers, des sondes, qui vont pour certains investiguer continuellement les multiples technologies de stockage et de transformation de données d’un système Analytics (ETL, langages procéduraux, scripts et outils de manipulation de données)

Pour pouvoir établir une temporalité dans l’exécution de process, d’autres parsers / sondes vont analyser certaines informations dans les différents schedulers (ordonnancement des tâches mise en production).

Et enfin, pour apporter un surcroît de précision sur la vie d’une donnée dans un système, d’autres parsers / sondes analysent certains des évènements qui sont logués dans les bases d’audit des bases de données.

Ces référentiels constitués vivent au même rythme que les outils de production et d'analyse de l'information, ils en forment donc la mémoire (évolution dans le temps de la donnée et de ses modes de transport) et l'intelligence de l'entreprise (règles de calcul dans les transformations unitaires, traduction des règles de gestion formulées par le métier).

Même s'il est bien-entendu difficile de concevoir autant de parsers et de sondes qu'il y a de technologies dans l'entreprise, il existe néanmoins de nombreuses méthodes pour rapprocher les informations stockées entre elles en s'appuyant sur leur structure, sur les schedulers ou les logs des bases de données et des différents outils de transport de l'information.

Cette « intelligence » qui automatise les rapprochements redonne de la visibilité là où il y avait des ruptures : transfert de données par FTP avec changement de nom entre les sources et les cibles, SQL dynamique, scripts générés à la volée par des outils tiers, utilisation abusive de couche d'abstraction de l'information comme les vues SQL. Les exemples sont innombrables.

Une fois ces référentiels en place, il devient plus simple de casser la complexité en classifiant les grands domaines de transformations et de stockage, en les croisant avec de nouvelles sondes sur les bases d'audit et ainsi mettre en évidence les autoroutes de l'information et a contrario les multiples ramifications peu actives ou mortes.

C’est la première étape pour pouvoir dissocier le canal prioritaire, stratégique de l’entreprise de l’information secondaire, obsolète, qui pourra être revalorisée sans contrainte forte de maintenance.

Quels peuvent être les outputs utiles ?

Un référentiel unique ouvert avec des APIs

Le premier output est la mise à disposition d’un référentiel de données homogène et structuré qui fait abstraction des technologies analysées, que ce soit pour le stockage et les transformations, et autres informations (usages, planification des processus, fréquences d’alimentation, ruissellement des termes métiers dans les données techniques).

Ce référentiel est directement mis à disposition des équipes. Il peut être versé dans les bases de données de l’entreprise pour être interroger par les mêmes outils de reporting / dataviz analysés. Mais ce référentiel peut également être intégré dans des outils de gouvernance via des APIs.

La transparence est un vecteur clef d’une bonne gouvernance.

Par ailleurs, il est également utile d’apporter quelques réponses très précises, pré- construites pour le coup et interfacées. Pourquoi ? Parce ces réponses capitales nécessitent des croisements d’informations complexes, que nous recueillons depuis nos sondes / parsers.

Ces réponses préconstruites sont le fruit de besoins exprimés par nos différents clients et qui nourrissent continuellement la communauté d’openAudit.

Une cartographie exhaustive

L’objectif est de comprendre très simplement quels sont les données impactées par quelconque transformation, et de quoi se nourrissent chacune des transformations.

Cette approche est réalisée de façon globale, mais aussi de façon segmentée s’il y différents moteurs de transformation, typiquement un ETL, du code procédural, des vues, une couche sémantique, etc.

Un data lineage granulaire et technique

Quand les sources opérationnelles sont multiples, qu’il y a différents moteurs de transformation de la donnée, quand les chaînes sont longues et tortueuses, et quand les technologies de reporting foisonnent, les équipes sont souvent dans l’incapacité de sourcer une information et de se figurer ses impacts.

A cela s’ajoutent les biais techniques, tels que les vues, le SQL dynamique, diverses couches sémantiques, des Enterprise Service Bus (ESB), des transferts de données par FTP qui créent mécaniquement des ruptures dans les chaînes.

Chaque investigation opérée par les équipes data est automatiquement obsolète dès lors qu’une virgule change dans les flux.

En automatisant le parsing des processus en delta (i.e. en ne s’intéressant qu’aux processus qui ont évolués par rapport au parsing précédent), il est possible d’obtenir une vision parfaitement synchronisée de la réalité des flux de transport des données.

Toutes les transformations sont fusionnées, les ruptures dans le lineage sont traitées par différentes méthodes (rapprochements structurels, analyses de logs)

Par ailleurs, les chaînes peuvent facilement devenir indigestes par leur longueur et leur complexité. Nous avons jugé pertinent de donner la possibilité de « masquer » l’intégralité des transformations pour faire réellement du bout en bout, avec un affichage instantané.

Cet exercice est également envisageable dans les différents environnements de travail (dev, test, intégration, QA, UAT, prod) pour mesurer et expliquer les écarts dans le cycle de vie de la transformation de données.

Enfin, toute évolution du référentiel est mémorisée pour conserver toute l’intelligence au fil de la rationalisation.

Une définition des usages de la donnée

Une question légitime affleure souvent dans les équipes data : « nous collectons de l’information, nous la transformons, nous l’exposons. Et pour quoi, pour qui, quand, à quelle fréquence ? »

A défaut d’avoir des réponses, la tendance lourde est de reproduire à l’infini des pipelines et de construire des réponses (quasi) analogues.

Cette mécanique est excessivement préjudiciable pour les raisons suivantes :

- Conformité des données exposées : des nuances émergent dans les différents pipelines qui finissent par créer des « vérités parallèles ».

- Risque : certaines équipes, personnes, en dépit de règles de sécurité finissent par avoir accès à des données qui ne leur sont pas destinées, à travers des outils pilotés par l’IT, mais surtout via des requêtes JDBC / ODBC qui sortent des radars. Inventorier ces innombrables « failles » est une gageure.

- Maîtrise d’un système : un système dont on maîtrise difficilement toutes les arcanes est un système qui grossit, qui se renchérit, et qui obère les possibilités de migrations. Or les migrations d’outils à outils (ETL, système de bases de données, outils de reporting) et surtout les migrations vers le Cloud sont des défis que chacune des équipes data se doit de relever à échéance régulière.

- L’IT est généralement considéré comme un centre de coût dans une entreprise, et donc surcharger ses systèmes avec des éléments répliqués, ou des éléments qui ne servent pas, peut aussi avoir des conséquences financières.

L’idée ici est de flagger de façon catégorique les éléments (tables, fichiers, dashboards, autres) qui sont faiblement ou pas du tout utilisés.

Au choix ces éléments peuvent être écartés, ou être versés dans une architecture annexe, faisant l’objet d’une maintenance moindre.

Ainsi, il devient possible de faire émerger un canal prioritaire, particulièrement monitoré, sécurisé, et un canal subsidiaire à moindre enjeux.

Le « ruissellement » des termes métiers

La multiplication du transport et de la transformation de l’information occulte sa représentation : quelles données véhicule-t-elle réellement. L’interrogation même de cette information directement depuis sa source physique (fichier, table, vue de la base de données par exemple) ne suffit pas nécessairement à répondre à cette question simple.

Pourtant, les outils de reporting, d’analyse, de dataviz possèdent souvent une description de l’information pour aider les utilisateurs à l’exploiter.

En propageant ces descriptions, il est possible de définir les grands concepts métiers qui définissent l’information à n’importe quel niveau technique dans le système d’information. Ce ruissellement automatisé donne de la visibilité conceptuelle à des couches purement technique. En d’autres termes, il contextualise n’importe quel regroupement de données (fichier, tableau, flux) en termes purement métiers.

Ces référentiels peuvent également aider à automatiser la classification de l’information en s’appuyant sur la théorie des ensembles en rassemblant les définitions sémantiques des descriptions techniques.

Un use case

« Avoir la pleine maîtrise d’un système Analytics pour pouvoir migrer vers le Cloud »

Groupe ADEO - Leroy Merlin

Le groupe ADEO, constitué de plus de 100 000 collaborateurs, compte parmi ses enseignes Leroy Merlin, Bricoman, Bricocenter, Weldom, Aki, Zôdio, Quotatis, etc.

Le groupe utilise de longue date Teradata comme Appliance (bases de données et infra), des scripts Teradata puis Stambia comme ELT (Extract, Load, and Transform), et principalement BO, Qlikview, et Power BI pour la restitution.

Le projet de ADEO est de migrer Teradata vers Big Query (GCP - Google Cloud Platform) et d’y raccorder tous les outils de reporting donc l’entreprise escompte se servir à l’avenir.

Pour « détricoter » un système en place, et pour le reconstruire dans le cloud, il faut en avoir une vision fine et partagée de l’ensemble de l’architecture analytics : qui utilise quelle donnée dans quel contexte.

Malheureusement, le transport de l’information s’appuie historiquement sur une librairie importante de transformations SQL sous forme de scripts BTEQ (Basic Teradata Query).

Une partie de ces scripts ont été repris dans l’ELT Stambia. Cependant, pour obtenir une vue d’ensemble, il est nécessaire de définir le cheminement de l’information :

- Dans du langage procédural (macros, procédures et SQL Teradata), dans Stambia et BO en ce qui concerne le système « historique » ;

- Dans la plateforme GCP (Google Cloud Plateforme) pour le système en cours de construction (utilisant essentiellement Stambia et bigQuery couplé à looker).

La migration vers Google Cloud

Migrer l’ensemble des flux de données d’un système à un autre dans un groupe international nécessite :

- De comprendre globalement quels sont les grandes familles de transformation ;

- Mais également de quantifier les flux personnalisés qui se sont naturellement greffées au fur et à mesure autour de ces grandes familles pour les adapter aux différentes filiales.

Le niveau « d’exceptions » donne généralement une bonne idée de la complexité du système source et donc de l’effort à fournir pour être à isopérimètre.

Pour autant, comment établir ce degré de complexité sans visibilité sur toutes les transformations écrites à la main, avec toutes les nuances et particularités qu’impliquent ce type de développement ?

La multiplicité et la fréquence d’évolution des flux interdit également une analyse manuelle car elle ne peut être que partielle (non exhaustive) et rapidement obsolète.

A l’inverse, un parser est capable de disséquer des millions de lignes avec des temps records. Ces flux de transformations sont ainsi décomposés sous forme d’arbres syntaxiques, avec une finesse importante, qui rendent ainsi possible des analyses ensemblistes.

La force de ces outils est de pouvoir rapprocher tous les morceaux afin de créer des fils de transformation au niveau le plus fin.

Comprendre l’usage de la donnée

Pourquoi migrer l’ensemble d’un système si toutes les informations ne sont pas utilisées ?

Quelle approche utiliser ? un big bang, une approche itérative par silo, une approche dataOps ?

Par ailleurs, est-il possible de migrer par secteur d’activité ? Si certaines populations sont prioritaires, comment connaître l’exhaustivité des informations qu’elles utilisent ou produisent ?

Seules les différentes sondes dans les bases de données ou autres outils d’exécution des flux de transformations peuvent donner une idée du type d’information utilisée ou non par un type de population. Rassembler et uniformiser ces méta-informations n’est pour autant pas suffisant sans la connaissance des structures intermédiaires construites pour stocker l’information utile.

En d’autres termes, pour connaître le véritable usage de l’information, il faut croiser les flux de transformations de données avec

- L’ensemble des exécutions des processus (qui donnent une idée de l’information maintenue, vivante) ;

- L’ensemble des consultations / insertions dans les bases de données, également pour connaître l’information vivante en dehors des processus automatisés;

- La structure de l’information stockée ou volatile;

- Les définitions métiers (business glossary, couches sémantiques) pour contextualiser les informations par famille;

- L’organisation des individus et des équipes.

Un vrai métier !

Raccourcir le processus de développement

L’évolution d’un système vers un autre donne de nouvelles marges de manœuvres. Dans le cas d’une migration vers le cloud, cette évolution a le mérite de rendre de la souplesse à des processus autrefois nettement plus rigide et d’accélérer la production d’information directement exploitable par l’ensemble des acteurs de l’entreprise.

Cette évolution peut également être vu comme la multiplication de petits bacs à sables spécialisés. Comment passer raisonnablement d’une construction empirique souvent fragile à une construction viable dans le temps et plus robuste, bref à une « industrialisation du processus » ?

De la même manière, cette évolution a un coût, l’entreprise est-elle certaine de pouvoir le maîtriser ?

Aussi, il faut pouvoir quantifier continuellement les sources principales d’informations répliquées et connaître leur degré de mutation par rapport à la donnée originelle. Cette connaissance est le socle de base pour établir les grandes règles de transformations qui pourraient être mutualisées. Sans cette matière première, la dataOps vire très rapidement à l’anarchie car le système est « aveugle », non piloté. Un système qui permet une très forte créativité sans indicateurs d’évolution est l’équivalent d’une réaction en chaîne nucléaire auto-alimentée (une petite bombe pour simplifier).

Partager la vision d’ensemble à tous les acteurs impliqués

Le processus d’évolution ou d’apprentissage nait avant tout du mimétisme. La réplication est donc naturelle car elle est à l’origine des petites mutations qui vont améliorer le système dans son ensemble. Cependant, comme il l’a été précisé dans le paragraphe précédent, l’accélération de ces mutations peut rapidement bloquer l’ensemble du système si la complexité n’est pas partagée par tous les acteurs.

Seulement, pour rendre intelligible un système complexe il est indispensable de casser la complexité en créant par exemples des grands ensembles, des grandes familles remises dans leur contexte.

Conteneuriser chaque brique du système

Pourquoi ne pas anticiper d’emblée les prochaines évolutions majeures ? Le passage dans le cloud provoque une accélération de la consommation de la donnée comme nous l’avons évoqué précédemment. En se projetant un peu plus dans le temps, nous pouvons vite remarquer que ce même mouvement est accompagné par l’« Infrastructure as Code ».

Il s’agit d’outils qui simplifient la « scalablity » et / ou l’évolution de votre système d’information. Autant dire, une nouvelle accélération de la consommation. Votre système s’essouffle ? peu importe ces outils vous donneront la possibilité d’ajouter des nœuds, des briques, des conteneurs pour le débrider. Il faudra néanmoins en supporter tout son « poids ».

Cependant, l’intérêt est également de pouvoir versionner une évolution et donc d’expérimenter « sans risque ». Nos outils accompagnent ces mutations en apportant également nos briques dans les différents conteneurs. Vous construisez de nouvelles images SAP BI, nous les accompagnerons automatiquement du lineage dans toute la chaîne.

Conclusion

Il faut comprendre que la mise en place de ces référentiels, auto-alimentés quotidiennement, doit être considérée comme la première brique de la dataOps.

Bien au-delà de la simple gouvernance de l'information de l'entreprise, ces référentiels constituent le socle pour accélérer les évolutions, permettre de revenir en arrière, d'organiser les « pulsions » du métier en toute transparence, ou tout simplement booster une migration qu’elle soit technique ou fonctionnelle.

En se projetant d’avantage, comme le font un grand nombre de groupes dans le monde, il est dorénavant possible d’industrialiser ces briques dans le cloud pour amener son entreprise vers une stratégie « data driven ».

Les nouvelles approches méthodologiques liées à la dataOps telles que l’« Infrastructure as Code » prouvent que ces évolutions deviennent « naturelles » si l’entreprise souhaite motiver ces utilisateurs à exploiter d’avantage l’information disponible (même si une motivation cachée reste de transférer les coûts de l’IT vers le métier).

Quelques soient les circonstances de la mutation, le transfert ne peut s’opérer sans une forte visibilité de la complexité. Les différentes expériences de mise en place de gouvernances « déclaratives » ne suivent pas le rythme effréné de ces nouvelles tendances. Peu importe le nombre de « cerveaux d’œuvre » en place pour tenter d’y remédier, l’intelligence « biologique » a largement prouvée son incompétence à opérer des tâches fortement répétitives et ennuyeuses face à une armée de robots. A l’inverse, cette intelligence biologique excelle pour synthétiser, classifier et dégager les tendances lourdes d’un système. En somme, le bon outil est celui qui trouve la bonne main (cerveau ?) pour l’exploiter.