Un Data Lake sans architecture d'entreprise est un saut dans le vide

Ce nouvel eldorado inspiré par des technologies créées par les GAFA est souvent perçu comme une solution purement technique. Il apparaît pourtant nécessaire d'aborder les apports essentiels de l'architecture d'entreprise dans la valorisation et le succès d'un Data Lake à travers trois chapitres distincts :

• L'activité urbanisation des systèmes d'information qui permet d'anticiper la place que le Data Lake occupera dans le « paysage applicatif » et dans l'organisation du système d'information.
• L'activité modélisation de données et mise en place de référentiels afin de garder le contrôle de son Data Lake et empêcher la transformation du lac (Data Lake) en marais (Data Swamp).
• L'activité pilotage du changement centré sur les données et les usages, pour être en capacité de transformer les futures idées innovantes issues de votre Data Lake en avantages compétitifs réels pour l'organisation.

En effet, si le Data Lake démonte techniquement les silos de données et ouvre la porte à des analyses globales et instantanées qui étaient inaccessibles jusque-là, il ne permet pas de disposer automatiquement d'une avance sur ses concurrents.

Chacun des chapitres qui suivent rappelle que le décloisonnement de la donnée n'est utile qu'à condition de faire évoluer en conséquence son système d'information et son organisation. Non par une démarche dogmatique qui imposerait un cadre, mais par une concertation autour des mutations à venir de l'organisation.

Si la résistance au changement, celle qui annihile les bonnes intentions, terrasse votre initiative de Data Lake, c'est probablement que certains des points qui suivent ont été sous-estimés.

Urbanisation : la place du Big Data dans la Big Picture

Si l'on s'en tient à une définition technique du Data Lake - un espace de stockage de données brutes à partir desquelles les Data Scientists effectuent des analyses pertinentes - la stratégie d'adoption est souvent la même. Un environnement moderne d'analyse est créé et un espace de stockage y est adjoint. Il s'ensuit une alimentation progressive en flux de données. Comme un POC qui ne dirait pas son nom. Cela ne permet aucune démarche d'urbanisation et n'embarque aucune réflexion sur les enjeux de l'industrialisation future. Pourtant, les sujets sont nombreux et porteurs d'enjeux forts.

Types d'utilisations et qualité des données 

Un Data Scientist utilise toutes les données pour ses expérimentations, mêmes les erronées et les « incertaines ». Un responsable produit veut des données consolidées et visualisables quotidiennement. Un Marketing veut de la segmentation à la volée pour proposer les meilleurs produits. Les commerciaux sont sensibles au « time-to-market », de l'idée à son exploitation commerciale. Sans parler des préoccupations du RSSI, du DPO, du management, du DSI, du DAF, des partenaires.

Ces différents modes de fonctionnement évoluent dans le temps et définissent des séparations logiques dans le Data Lake. Non pas des silos, mais des contraintes d'utilisations qu'un Data Lake n'embarque pas par défaut, et qui nécessitent une certaine maturité dans l'urbanisation du Data Lake. Le Data Lake n'est pas un COTS - un produit informatique standard « vendu sur étagère ». Définir un écosystème est nécessaire pour découpler ces utilisations. Echanges de flux, orchestration des processus, supervision, autorisations d'accès, tout cela est nécessaire pour que le Data Lake évolue en phase avec le reste du SI.

Processus de collecte 

En rapatriant toutes les données brutes dans le Data Lake, l'industrialisation des collectes de données ne peut pas faire l'économie d'une réflexion globale sur les qualités prioritaires attendues des échanges et de l'urbanisation qui en découle.

Et toutes les entreprises n'auront pas les mêmes contraintes. Un opérateur de téléphonie peut générer un million de données par seconde de mille sources différentes, dont certaines sont soumises à des obligations légales de traçabilité et d'autres à des obligations comptables. Une petite mutuelle génèrera péniblement cinq mille données par jour, mais certaines seront des données de santé sensibles.

D'autres auront leurs données dans des progiciels, dont certains en mode SaaS. D'autres encore exploiteront les données de partenaires de fiabilités variables. Des entreprises au SI de plus de trente ans passeront par des couches d'encapsulation de leur mainframe. Et toutes ces contraintes peuvent se combiner. Une logique urbanisée est vitale.

Sécurité des données 

Le Data Lake a aussi pour vocation de faire circuler une part très importante des données de l'entreprise pour des usages dont le nombre, la nature et les utilisateurs finaux seront amenés à évoluer. Cela ne peut pas se faire sans une automatisation de la traçabilité, de la supervision et de la sécurisation des échanges et du stockage. C'est même bien souvent une obligation légale (RGPD, données de santé, Sarbanes-Oxley.).

La gestion des identités et des accès (IAM), l'API Management, leur intégration avec les données sensibles ou réglementées sont des sujets que l'architecture d'entreprise et le RSSI doivent orchestrer.

Quels modules dans l'écosystème Data Lake ? 

D'autres éléments structurants de votre SI doivent être pris en compte dans l'urbanisation du Data Lake :

• Le « catalogue des données », les référentiels associés et leurs cycles de vie,
• L'orchestration des processus entourant la gestion des créations, évolutions ou disparitions des sources et destinations,
• Le transport physique des données, la gestion de l'intégrité et de l'unicité des transactions, la reprise sur erreur.
• La normalisation des données doit retrouver sa place autour d'un Data Lake qui favorise la donnée brute d'origine. La repousser en aval dans la chaîne de traitement ou faire cohabiter anciennes et nouvelles chaînes en parallèle, les choix dépendent des contraintes et attentes.

Chaque SI étant spécifique, cette liste est loin d'être exhaustive.

Se lancer dans la constitution d'un Data Lake sans faire le point sur les impacts, les contraintes et les opportunités mène généralement à une mauvaise adéquation par rapport aux enjeux stratégiques et aux besoins pressentis. Qui d'autre que l'architecte d'entreprise pour donner le recul nécessaire à la définition de la solution de bout-en-bout qui correspond à vos impératifs ?

Référentiels : connais-toi toi même 

Le principal avantage du Data Lake est aussi son principal inconvénient : il casse les silos de données en acceptant n'importe quelle donnée sans surveillance ni gouvernance. Or, il est bien hasardeux, en ces temps de RGPD, de laisser accéder n'importe qui à n'importe quelle donnée.

Autant il est facile de déverser en vrac des données non-dénaturées dans une couche persistante accessible par des personnes autorisées (le Data Lake dans sa forme épurée), autant se passer de référentiels qui permettent la mesure de la valeur des différentes sources de données fait perdre la maitrise du contenu du Data Lake et de tous ses usages possibles.

Les référentiels sont principalement des données de référence sur les données, des métadonnées. Savoir quelle donnée est disponible dans quelle source. Discriminer les données de référence, les données opérationnelles et les données d'exploitation. Connaître les fréquences de rafraîchissement, les versions disponibles, les responsables, la classification, les moyens de les visualiser.

L'utilisation qui en est faite dans le Data Lake est également un élément essentiel pour éviter la création de « silos logiques » venant remplacer les « silos physiques ». Le référentiel peut permettre de connaître le responsable des autorisations d'accès, l'endroit où elle est utilisée, son usage dans des expérimentations, des processus ou des rapports, les référents techniques, fonctionnels ou Métiers.

Si une donnée se trouve dans plusieurs sources, il faut savoir quelle source fait référence (« golden source »), les applications possédant une copie locale, celles pouvant mettre à jour la référence et les règles de propagation des modifications dans le SI, les mécanismes détectant et remédiant les inconsistances entre sources.

Il n'est pas possible de lister ici toutes les informations qui, dans un contexte ou un autre, peuvent être pertinentes. Mais c'est bien l'architecture d'entreprise qui définit le périmètre et les limites de cette gouvernance des données.

Cette gouvernance doit faire en sorte que l'utilisation des données ne reflète pas les anciens silos techniques. Elle permet aussi de faire contribuer les experts Métiers, fonctionnels et techniques sur la façon d'utiliser ces données qu'ils connaissent bien. Leur engagement et leur implication participent grandement du décloisonnement.

La technologie Data Lake pourrait permettre d'accepter n'importe quelle donnée sans surveillance ni gouvernance. Mais les organisations qui ont profité de cette possibilité de ne plus surveiller, ni mettre en place une gouvernance se sont retrouvés avec un Data Swamp dont la gestion est plus complexe, les bénéfices plus aléatoires et les risques opérationnels sans commune mesure avec ceux d'un Data Lake sous le contrôle des architectes d'entreprise.

Transformation continue et pilotage par la donnée : commencer par aligner dans les deux sens

On se prive d'opportunités lorsque l'alignement entre le système d'information et les Métiers se fait toujours au détriment du SI. La complexité technique invisible aux demandeurs d'évolutions et la difficulté de rendre le SI adaptable aux exigences imprévues, rendent l'alignement difficile.

Dans le cas d'un Data Lake, lorsque différents acteurs Métiers accèdent au catalogue de données et aux services associés, le Métier s'aligne de lui-même sur ce que le SI lui rend disponible. En ouvrant son catalogue et en étant capable d'afficher ce qu'il est techniquement possible de fournir, le SI rationalise les exigences du Métier. Il le doit au socle urbanisé qui assure la maîtrise technique des flux et à la gouvernance pour la maîtrise fonctionnelle des données.

Certes, un travail effectué par le SI est toujours nécessaire pour s'aligner sur le besoin. Mais ce besoin sera plus naturellement cadré et les impossibilités techniques seront beaucoup plus rares.

Puis baliser la propagation de l'innovation

De même que le DevOps est le chaînon manquant entre deux mondes aux fonctionnements difficilement compatibles (le développement et l'exploitation), de même, il manque une étape importante entre la Data Science - qui extrait la valeur et valide la pertinence d'une nouvelle utilisation d'un ensemble de données - et le Métier qui attend une mise en production rapide de cette segmentation, cette visualisation ou cette publication.

Votre Data Lake va peut-être vous apporter de nombreuses idées de nouvelles utilisations de votre patrimoine de données. Il est rationnel de mettre en place des processus simples pour l'industrialisation de ces différents types d'utilisations.

Un « DevOps Data » avec des outils plus proches de la gestion de paramétrage que de la gestion d'une intégration continue. Il s'agit moins d'injecter de nouvelles versions applicatives dans le SI que de faire cohabiter des usages à différents degrés de maturation dans le même SI. A partir du Data Lake, il sera permis d'enrichir en continu des API à usages internes ou externes, ou d'automatiser la création de Data Sets pour des besoins de BI et de reporting. Ce DevOps se met en oeuvre principalement autour :

• D'outils d'orchestration des processus,
• D'une bibliothèque extensible de connecteurs,
• Du travail algorithmique des Data Scientists,
• De la gestion des droits et des accès aux différents services,
• D'une gestion des sources, des environnements et des déploiements, plus classiques du DevOps.
• De convertisseurs en sortie pour fournir les formats utiles.

L'architecture d'entreprise associée à un Data Lake vous permet de créer du logiciel robuste, professionnel et évolutif sans vous lancer dans des appels d'offres de COTS qui reproduisent prioritairement les besoins du plus grand nombre, et non vos besoins spécifiques. Votre Data Lake devient l'élément central d'un applicatif adressant vos innovations sur-mesure.

Data Lake et transformation

Cette évolution continue à l'échelle de l'entreprise fera le succès du Data Lake. Ce changement de paradigme a beau être souvent problématique, la nécessité d'une conduite du changement amenant à une modification de l'organisation est rarement perçue ; alors même que les Data Lake sont issus de GAFA et de startups dont la culture et l'organisation sont souvent à l'opposé des organisations matricielles qui s'emparent actuellement du Big Data et des Data Lake.

Ce mode de fonctionnement va bouleverser des pans entiers de votre organisation, modifier les circuits de décisions, les périmètres de responsabilités, les modes de communications internes et externes, les cycles de vie des produits et services, le contrôle des mises en production. Ces nouveautés sont anxiogènes et vont entraîner des résistances et des stratégies d'évitement.

C'est justement pour adopter plus facilement une démarche transverse affectant aussi bien l'architecture technique, les processus métiers, que l'accompagnement de la transformation de l'organisation, que l'architecture d'entreprise a été créée.

La mise en place d'un Data Lake est un saut dans l'inconnu. L'architecture d'entreprise est votre parachute.

^{Crédit photo : Ai825 / Shutterstock}

Sylvain Mazeau, Consultant senior Architecture d'Entreprise - Rhapsodies Conseil.