Au-delà du concept et des principes d’architecture, est-ce que le Data Mesh est viable à l’épreuve de réalité des organisations et des SI data ? Est-ce que cette architecture décentralisée et orientée domaine fonctionnel, qui permet une exploitation des données en libre-service, est la hauteur des promesses ?

Voici les principaux écueils à anticiper.

En tant que pure-player de la Data, nous en avons connu chez Smartpoint des architectures de données … Et nous savons à quel point il est complexe de trouver, de concevoir, de mettre en œuvre la bonne solution et de briser enfin les silos. On sait aujourd’hui qu’environ 80% des projets de Data Warehouses ont échoué et il y a déjà presque 10 ans, Gartner prédisait que 90% des Data Lakes seraient finalement inutiles. Il est vrai aussi que l’on sait qu’une équipe Data centralisée est souvent débordée et manque d’expertises par domaines métiers, ce qui nuit invariablement à la découverte et à la création de valeur data.

Revenons sur les principes fondamentaux qui caractérisent le Data Mesh ou Maillage de données tel que promus par Zhamak Dehghani(ThoughtWorks) en alternative aux structures de données centralisées et monolithiques :

1. Domain-driven ownership of data : Les données sont considérées comme des actifs appartenant à des domaines spécifiques au sein de l’organisation. Chaque domaine est responsable de la production, de l’amélioration de la qualité des données et de la gestion. Cette approche permet de créer des équipes spécialisées, composées d’experts métier et techniques, qui travaillent en étroite collaboration pour définir les normes et les règles spécifiques à leur domaine. Leur objectif est de répondre aux besoins de leur domaine fonctionnel en terme d’exploitation des données, tout en favorisant la réutilisation et l’interopérabilité entre les différents domaines métiers.

2. Data as a product : Les données sont destinées à être consommées par les utilisateurs au sein de l’organisation. Les équipes data doivent se recentrer sur le client pour fournir des data sets de qualité, fiables et bien documentés. Elles créent des interfaces claires (API) et définissent des contrats pour la consommation des données. Ainsi, les utilisateurs peuvent découvrir, accéder et utiliser les données de manière autonome, comme un produit prêt à l’emploi. On est dans la même logique que les architectures microservices.

3. Self-service data platform : Les équipes data fournissent une plateforme de données en libre-service, qui facilite la découverte, l’accès et l’exploitation des données. Cette plateforme fournit des outils, des services et des interfaces qui permettent aux utilisateurs de trouver intuitivement et de consommer les données de manière autonome. Elle favorise l’automatisation et l’orchestration des flux de données, permettant ainsi aux équipes data de se concentrer sur la qualité et l’enrichissement des données plutôt que sur des tâches opérationnelles chronophages et à faible valeur ajoutée.

4. Federated computational governance : La gouvernance des données est décentralisée et répartie entre les différentes équipes. Chaque équipe a la responsabilité de définir et d’appliquer les règles et les normes spécifiques à son domaine. La gouvernance fédérée consiste à mettre en place des processus et des outils qui permettent de gérer et de contrôler les données de manière distribuée. Cela inclut la gouvernance des métadonnées, la sécurité, la conformité réglementaire, ainsi que la prise de décision collective et transparente sur les évolutions de l’architecture et des pratiques liées aux données.

Voici pourquoi une architecture data mesh pourrait se révéler être un échec dans certaines organisations où les notions de produit data ou de propriété de domaines sont difficilement applicables.

• Toutes les données n’ont pas forcément une valeur, c’est même le contraire. La plupart des données collectées sont inutiles et brouillent l’information car elles ne sont pas pertinentes. Dans les faits, c’est compliqué d’identifier dans la masse celles qui sont réellement précieuses et potentiellement génératrice de valeur. C’est un véritable chantier en soi, complexe et laborieux. Un travail de chercheur d’or !
• Produire des données est une charge supplémentaire ! Certes le concept de data product est séduisant et facile à appréhender mais dans la réalité du terrain, les ingénieurs data doivent déjà les créer … Et les transformer en plus par domaine nécessite d’élargir encore leurs compétences. Certes les avancées en IA, automatisation, et autres Low Code promettent de leur faciliter la tâche mais c’est encore une promesse qui reste à éprouver.
• On en vient naturellement à la troisième difficulté : le manque de compétences data disponibles. Le Data Engineering, c’est un métier de spécialiste de la gestion des données et nous savons qu’il est rare de trouver des professionnels qui en maîtrise toute la palette ! Déléguer la responsabilité à des équipes par domaine, sans compétences spécialisées en data, peut générer des problèmes sans aucun doute.
• La gouvernance fédérée est aussi une évidence sur le papier. Dans les faits, ce n’est pas applicable sans de fortes contraintes avec un véritable régime central très autoritaire qui encadre les comportements et contrôle régulièrement les usages. En effet, si la gouvernance des données est détenue par une guilde fédérée composées de représentants de différents domaines, cela risque fortement d’être inefficace car chaque département a ses propres règles et priorités.
• Une plateforme centralisée en libre-service fait rêver mais dans les faits, mettre en place ce type de solution se révèle très complexe car on est confronté à une variété vertigineuse de formats de données, une pluralité de systèmes et d’applications différents, de différentes versions voire de générations. Certes, nous disposons aujourd’hui de nombreux outils pour ingérer massivement les données et de larges bibliothèques de connecteurs … mais on peut rapidement retomber dans les travers du data warehouse.

Pour conclure, une architecture Data Mesh est très intéressante, mais au là du concept, il faut en mesurer les risques, les écueils et ses limites.

Voici les principaux avantages qui méritent qu’on étudie sa faisabilité et sa mise en pratique dans votre SI Data :

1. Démocratisation de l’exploitation des données par un plus grand nombre (au delà des data scientist) via les applications en libre service
2. Réduction des coûts car cette architecture distribuée est davantage #Cloud native avec des pipeline de collecte des données en temps réel (paiement à la consommation en terme de stockage)
3. Interopérabilité car les données sont normalisées indépendamment du domaine et les consommateurs s’interfacent par APIs.
4. Renforcement de la sécurité et de la gouvernance des données car les normes sont appliquées au-delà du domaines ainsi que la gestion des droits et des accès (journalisation, observabilité).

Sources :

• L’échec des projets de datawarehouses : https://www.dbta.com/Editorial/Think-About-It/Why-a-Majority-of-Data-Warehouse-Projects-Fail-and-What-Businesses-Can-Do-145910.aspx
• Dès 2014, Gartner prévoyait qu’en 2018, 90% des data lakes déployés seraient inutiles car ils seront submergés d’informations capturées pour des cas d’utilisation incertains. Relire les prédictions de l’époque : https://blogs.gartner.com/merv-adrian/2014/12/30/prediction-is-hard-especially-about-the-future/
• 6 raisons pourquoi le Data Mesh va échouer : https://medium.com/@hannes.rollin/six-reasons-why-data-mesh-will-fail-195886c89bdd

• Un data Warehouse est une base de données analytique centralisée qui stocke les données déjà structurées. Il est utilisé par des analystes qui maîtrisent parfaitement le langage SQL et savent donc manipuler les données. Les données sont optimisées et transformées pour être accessibles très rapidement à des fins d’analyses, de génération de rapports et des tableaux de bords de pilotage des entreprises.

• Un data lake collecte et stocke lui aussi des données mais il a été conçu pour traiter les Big Data, c’est-à-dire pour de fortes volumétries de données brutes, non structurées ou semi-structurées. Les data lakes sont à privilégier dans le cas d’un traitement en continu et d’une gestion en temps réel des données. Les données sont généralement stockées en prévision d’une utilisation ultérieure. Comme elles sont de natures brutes et non traitées, il est nécessaire de faire appel à un Data Scientist lorsqu’on souhaite les exploiter. Généralement, le datalake est utilisé pour le traitement par lots. Il permet notamment l’utilisation d’ELT en libre-service (par ex Informatica) pour automatiser l’ingestion et le traitement des données, ce qui permet de réduire la complexité de la conception et la maintenance des pipelines de données.

• Un data Lakehouse, c’est une nouvelle architecture qui réconcilie en théorie le meilleur des deux mondes entre l’entrepôt de donnée et le data lake en une seule plateforme ! Le data lakehouse permet d’éviter la multiplication des moteurs de requêtes en exécutant des analyses directement dans le data lake lui-même.

À suivre ? les solutions proposées par Databricks …

L’objectif est de documenter tous les data assets de l’organisation, de les cartographier afin de voir comment ils circulent dans vos systèmes afin d’obtenir un schéma directeur.

La schéma directeur va donner le cadre sous-jacent aux plateformes de données qui alimentent également les outils de gestion de données. Il va permettre aussi de spécifier les normes pour la collecte, l’intégration, la transformation et le stockage de données. Aujourd’hui, on utilise de plus en plus des systèmes de streaming de données en temps réel et on prend en charge désormais les applications d’IA/ML en plus de la BI traditionnelle.

Le développement du cloud a encore apporté une couche de complexité aux architectures de données. Autre concept émergeant, la Datafabric ! Enfin, l’architecture de données doit prendre en considération la conformité règlementaire et la gouvernance des données.

Une bonne conception doit être :

• Orientée métier pour être alignée sur l’organisation et les besoins
• Flexible et évolutive
• Fortement sécurisée pour interdire les accès non autorisés et les utilisations abusives

Ses composants ? Des modèles de données avec des référentiels communs, des diagrammes et des flux de données pour comprendre comment circulent les données dans les systèmes et les applications qui les consomment, des documents qui normalisent comment les données sont collectées, intégrées et stockées.

Source pour aller plus loin : What is data architecture? A data management blueprint