#4.8 SAP Datasphere et le data mesh

SAP et le data mesh

Depuis que le concept de data mesh a émergé en 2019, la réponse des grands éditeurs de solutions centralisées était attendue. SAP n’étant clairement pas un ardent défenseur de la décentralisation, il était légitime pour ses clients de se demander comment l’editeur allait aborder le sujet.

Lancé en 2019, formalisé en 2022 dans le livre éponyme, le concept de data mesh a convaincu un certain nombre d’entreprises comme Suez, Le bon coin, Paypal, Eurotunnel, etc. Certains ne le nomment pas, et en choisissent les principes qu’ils souhaitent appliquer. Mais tous font un pas vers la décentralisation de la responsabilité des données vers les domaines métiers, et la migration de data warehouses centralisés vers des data products, décentralisés fonctionnellement et centralisés techniquement.

Centraliser les données ou les jeux de données ?

La réponse de SAP est apparue récemment, elle s’appelle SAP Datasphere. Soit pour ne pas avoir à payer de royalties, soit pour ne pas avouer qu’il n’est pas l’inventeur du concept, SAP n’utilise quasiment pas l’expression data mesh dans sa communication. Mais l’objectif est clairement de répondre à cette évolution. Voyons ensemble comment.

Il y a quelques années, SAP migrant vers le cloud, proposait comme solution centrale à un système décisionnel son offre SAP Data Warehouse Cloud. Evoluant sur les plans technologiques et marketing, SAP Data Warehouse Cloud est devenu SAP Datasphere. Et il y a tout juste un an, SAP a présenté SAP business data fabric, basée sur SAP Datasphere comme coeur de la conception des systèmes décisionnels pour ses clients. “i[Data Fabric est une architecture technique, qui permet de rassembler des données hétérogènes en provenance de plusieurs sources]i”, explique Wolfgang Epting, expert produit chez SAP. On est donc bien dans une architecture de centralisation des données. Mais en réalité, SAP défend que SAP Datasphere peut être utilisé pour centraliser, de manière technique uniquement, des données ou des jeux de données (data products) qui peuvent provenir de sources externes.

Ainsi, en définissant et construisant les data products dans les domaines métier, comme le préconise le data mesh, mais en les stockant dans la SAP business data fabric, cette dernière devient une plateforme selfservice de jeux de données. Les quatre principes du data mesh sont bien respectés : les domaines, les jeux de données, la plateforme en libre-service, et la gouvernance fédéralisée.

Il faudra cependant resister à la tentation de stocker les données unitaires dans SAP business data fabric et d’y fabriquer les jeux de données, auquel cas il n’y aurait plus de décentralisation et l’on retrouverait le trio data warehouse - data lake - data mart. Le data mesh est avant tout un changement de paradigme, une organisation différente, décentralisant la responsabilité des données dans les métiers, et modifiant la répartition des rôles entre l’informatique et les métiers. Les luttes de pouvoir pourraient se réveiller à l’occasion de cette mise en place…

Cataloguer, la première pierre de l’édifice

Qu’il s’agisse de gouvernance ou de data mesh, le catalogue des données est au centre du dispositif. SAP ou pas, sans catalogue de données, toute la gouvernance et la décentralisation des responsabilités vers les métiers, seront incomplètes et surtout bien compliquées à appliquer.

SAP s’est beaucoup appuyé sur ses partenaires pour la création du catalogue des données. Collibra semble le partenaire éditeur privilégié. D’ailleurs, en terme de couverture fonctionnelle, comme de coût et de délai de mise en place, il n’est pas rare d’entender Collibra qualifié de “SAP des catalogues de données”.

Jusqu’à ce que SAP annonce sa propre solution, SAP Datasphere Catalog. Il permet “ i[de découvrir, gérer et controler, toutes les données afin de garantir une gouvernance transverse de l’ensemble de leur cycle de vie]i”, explique Wolfgang Epting. Il s’appuie sur un graphe de connaissance, qui met en relation les données, les métadonnées, et les processus métier. Dès la version 1.0 de SAP Datasphere, publiée en janvier 2024, il est possible de rechercher en une fois des données et des jeux de données dans le catalogue.

Dans la feuille de route publiée par SAP, la connexion entre les data products et le catalogue de données, est prévue pour le dernier trimestre 2024. Les data products pourront alors s’enrichir des métadonnées du catalogue. Le catalogue de données pourrait alors devenir un catalogue de data products. L’extraction automatique des métadonnées pour alimenter Datasphere est prévue pour le premier trimestre 2025. Une question intéressante se pose alors en ce qui concerne l’avenir de la coopétition avec Collibra, et de l’impact de SAP Datasphere Catalog sur les clients actuellement équipés de SAP et de Collibra… Devront ils cumuler les deux solutions ou SAP leur conseillera-t-il amicalement de se concentrer sur sa propre solution ?

Vers le partage et la monétisation des données

Autre évolution intéressante, la place de marché de jeux de données que pourrait devenir SAP Datasphere. Les différentes fonctionnalités liées à la publication de données et de jeux de données sont prévues dans le courant de 2024. Seule l’ouverture vers une place de marché publique est inscrite dans la vision mais non encore planifiée.

Franchement, si le ramage de SAP business data fabric, et ses composants Datasphere et Catalog, se rapportent à leur plumage, cette évolution de l’offre de SAP est en ligne avec celle des bonnes pratiques, et c’est une bonne nouvelle. Reste à voir le prix, les ressources de mise en œuvre, et la complexité.