La donnée en tant que produit dans SAP Datasphere : Le rôle des fournisseurs de données, de leurs produits de données et du Data Marketplace
- SAP Datasphere
- 9 min de lecture
Franziskus Heep
Comment les entreprises peuvent-elles transformer leurs données en produits qui peuvent être utilisés et réutilisés par d'autres ?
SAP Datasphere propose une approche innovante pour organiser et utiliser les produits de données avec l'approche Data-as-a-Product.
Les données peuvent être regroupées dans des produits de données structurés et réutilisables. Ces produits de données peuvent être mis à disposition par des fournisseurs de données, publiés via un Data Marketplace et consommés par les utilisateurs en fonction de leurs besoins.
Cet article traite du fonctionnement et de la mise en œuvre du concept Data-as-a-Product au sein de SAP Datasphere.
Table des matières
1. Fournisseur de données
Le fournisseur de données, en tant que fournisseur des produits de données, joue un rôle central. Seuls les utilisateurs DSP, qui se présentent comme des fournisseurs de données, sont autorisés à mettre à disposition et à publier des produits de données.
Outre une licence Datasphere valide, un utilisateur a besoin de son propre profil de fournisseur de données, qui lui ouvre ce rôle ainsi que les possibilités qui y sont liées.
Ensuite, le fournisseur de données peut créer ses produits de données, gérer leur accès et fournir des mises à jour continues grâce à la publication ciblée de versions. Ces étapes sont illustrées dans le graphique suivant.
Dans la suite de l'article, ces étapes de processus sont décrites à l'aide du Data Products „Sales Orders Insights“.
Ce Data Product contient des données pour l'analyse des commandes clients avec des informations détaillées sur l'historique des commandes. Cela peut aider les entreprises à prévoir leur chiffre d'affaires et à optimiser leurs processus de chaînes d'approvisionnement.
Profil du fournisseur de données
Dans le contexte de SAP Datasphere, un fournisseur de données représente une personne ou une entreprise qui définit des Data Products et les publie via le Data Marketplace (voir ill. 2).
Grâce à une gestion ciblée des contextes et des licences, le fournisseur de données peut définir pour qui les Data Products publiés sont visibles et qui est autorisé à les consommer. Ainsi, le fournisseur de données peut garantir une distribution contrôlée et sécurisée de ses Data Products.
Contrairement à un Data Consumer, un Data Provider n'accède pas aux Data Products via le Data Marketplace, mais les administre, les publie et les gère via le Data Sharing Cockpit.
Comme on peut le voir sur l'illustration trois, outre la maintenance des données de base du fournisseur de données respectif dans le profil du fournisseur de données, la visibilité sur la place de marché et les types de transfert de l'envoi de données sont également limités.
La visibilité sur la place de marché détermine si le fournisseur de données est autorisé à publier sur des places de marché de données publiques, privées ou internes en général. Vous trouverez de plus amples informations à ce sujet dans la section Place de marché.
Lors de l'envoi de données via Open SQL, l'utilisateur doit fournir un schéma Open SQL. Après l'activation, le schéma fourni est disponible dans le Data Builder comme source de données et peut y être utilisé.
La livraison externe désigne la mise à disposition de fichiers, par exemple au format .csv, pour une utilisation en dehors de SAP Datasphere. Dans l'exemple montré, le fournisseur de données « s-peers DP » se limite toutefois au transfert de données : Livraison intégrée (Integrated Delivery).
Lors de la sélection du transfert de données : La livraison intégrée permet à un consommateur de données, s'il possède la licence nécessaire pour ce produit de données, d'importer les artefacts dans l'espace qu'il a sélectionné.
Il a ensuite un accès en lecture à la vue et peut l'utiliser, par exemple, comme source pour un modèle analytique.
Contrairement aux méthodes courantes d'échange de données, telles que les fichiers plats, les API et les exportations de tableaux de bord, cette approche permet d'intégrer des données dans les modèles DSP sans qu'une autre interface ne soit nécessaire.
En plus de ces informations, le profil du fournisseur de données offre également un aperçu des produits de données déjà publiés (voir illustration 4).
2. Produit de données
Dans SAP Datasphere, les Data Products sont des unités de données regroupées et réutilisables, qui peuvent être définies et publiées par un Data Provider et consommées par d'autres utilisateurs DSP.
Un Data Provider peut définir ses Data Products via la section « My Data Product » dans le Data Sharing Cockpit.
Outre les métadonnées descriptives, des espaces DSP, des artefacts de Data Product et des filtres à appliquer à ces artefacts peuvent également être définis en fonction de la configuration.
Actuellement, seules les vues peuvent être utilisées comme artefacts pour un Data Product. Lors du transfert de données avec livraison intégrée, il convient en outre de distinguer les modes de livraison. Dans l'exemple (voir fig. 5), l'accès en direct a été choisi : au lieu d'une réplication, les données sont ici partagées directement au sein du même tenant. Les modifications sont immédiatement visibles, car les vues apparaissent directement dans l'espace cible. Ce mode garantit que les données restent toujours à jour. Un Data Product ne possède pas son propre domaine de visibilité. Pour définir la visibilité pour les Data Consumers potentiels, on utilise des « contextes » (Contexts). Comme une visibilité doit être définie pour chaque Data Product, l'attribution d'un contexte est obligatoire lors de la création d'un Data Product. Ces contextes sont des espaces de travail définis par le Data Provider, qui peuvent être liés de manière flexible à un ou plusieurs Data Products. Ils permettent un contrôle d'accès personnalisable aux Data Products dans le Marketplace non public, dans lequel les utilisateurs et les groupes d'utilisateurs peuvent être ajoutés, adaptés ou supprimés en fonction des besoins.
Après la publication, les Data Providers et les Data Products peuvent être recherchés et trouvés par les utilisateurs dans le Datasphere Data Catalog , à condition qu'ils se trouvent dans le domaine de visibilité qui leur est attribué.
Malheureusement, dans le Data Catalog, il n'est pas encore possible d'établir un lien avec des métadonnées (-objets) tels que des KPI ou des termes, comme c'est le cas pour les actifs. SAP prévoit d'introduire cette fonctionnalité dans la version du quatrième trimestre 2025.
Une explication complète des actifs, des KPI, des termes et de la maintenance des métadonnées dans le Data Catalog, ainsi que de leurs possibilités de mise en réseau, est traitée dans l'article suivant : De l'ordre à la valeur ajoutée
Dans la suite de cet article, l'accent sera mis sur le Data Marketplace, où les Data Consumers potentiels peuvent rechercher et consulter spécifiquement des Data Products et des Data Providers.
3. Publication sur la place de marché des données
La visibilité définit pour quels utilisateurs DSP un produit de données est visible. Pour cette visibilité, on distingue principalement, lors de la publication d'un produit de données, entre Public Marketplace, Private Marketplace et Intern Marketplace.
Ces trois types de Marketplaces ne doivent pas être considérés comme des plateformes séparées, mais se réfèrent à la visibilité des fournisseurs de données et des produits de données pour les consommateurs de données potentiels, que nous venons de décrire. Dès que le fournisseur de données a entièrement défini son produit de données, il peut le publier via le bouton „List“.
Ensuite, le produit de données publié est trouvable pour les utilisateurs DSP pour lesquels le Marketplace de données respectif est visible.
Le type de Marketplace de données et qui a accès aux produits de données sont gérés via les Contexts.
Place de marché des données publiques
Les produits de données qui sont répertoriés via l'option Public Data Marketplace sont visibles pour toutes les instances DSP sur la SAP Business Technology Platform (BTP), qui sert d'environnement cloud central pour le développement, l'intégration et la gestion des applications. Le contexte Public Marketplace est attribué par défaut à chaque utilisateur du Data Marketplace et ne peut pas être quitté. Chaque utilisateur d'un DSP a la possibilité de trouver les produits de données et de les importer en fonction de sa licence.
Place de marché de données privées
Avec l'option Private Data Marketplace, la visibilité des Data Products après leur publication est limitée aux utilisateurs invités. L'invitation se fait par le biais de clés d'activation, avec lesquelles un utilisateur peut activer son accès au Data Marketplace.
Place de marché de données internes
Avec l'option « Internal Data Marketplace », la visibilité des produits de données publiés est limitée aux membres de tenants spécifiques qui peuvent être définis dans le contexte du fournisseur de données. Un bon exemple en est l'échange de données entre les départements, les divisions ou les filiales, qui utilisent chacun des tenants DSP différents.
Les contextes permettent aux fournisseurs de données de contrôler de manière ciblée les places de marché privées et internes et de définir la visibilité des produits de données pour certains utilisateurs ou groupes d'utilisateurs. Si un utilisateur est associé à un contexte contenant un produit de données spécifique, ce produit de données lui est visible, ainsi que les métadonnées, dans le Data Marketplace. Pour pouvoir effectivement consommer le produit de données, il a également besoin de la licence appropriée pour le produit de données.
Le fournisseur de données peut générer et envoyer des clés d'activation pour inviter des utilisateurs dans un contexte spécifique. Dans la section « Data Marketplace – Mon contexte », le consommateur de données peut activer ces clés et gérer son appartenance à différents contextes. En rejoignant un contexte, l'utilisateur accède aux produits de données qui y sont publiés.
Une multitude de clés d'activation peuvent être créées pour un contexte, et chaque destinataire peut activer plusieurs clés d'activation pour différents contextes.
Dans l'exemple illustré ci-dessous (voir fig. 6), le contexte « Reporting financier » a été créé en tant que Private Data Marketplace avec une validité jusqu'au 31.12.2024. Pour ce contexte, deux clés d'activation ont été générées et envoyées pour les fournisseurs de données et deux pour les membres, mais jusqu'à présent, seule une clé d'activation de membre a été activée. Une clé d'activation de membre donne au destinataire l'accès au Marketplace en tant que membre, ce qui rend le Marketplace visible pour lui. Une clé d'activation de fournisseur de données, en revanche, donne non seulement à la personne invitée l'accès au Marketplace, mais aussi l'autorisation d'agir en tant que fournisseur de données dans le contexte et de publier ses propres Data Products dans le contexte. L'activation des clés d'activation de fournisseur de données ne se fait pas via « Data Marketplace – My Context », mais dans le « Data Sharing Cockpit – Context Management ».
Tant le fournisseur de données qui a créé le contexte et invité des utilisateurs, que l'utilisateur lui-même, peuvent décider indépendamment que cet utilisateur quitte à nouveau le contexte. Ces opérations sont documentées dans la section « Gestion du contexte » et, comme le montre la capture d'écran, sont transparentes et compréhensibles pour le fournisseur de données.
En tant que Data Consumer, l'utilisateur DSP accède au Data Marketplace via la navigation sur le côté gauche (voir fig. 7) et peut y utiliser la recherche en texte libre et appliquer des filtres tels que Data Category, DeliveryPattern (Cycle de publication) ou Regional Coverage.
Contrairement au Data Consumer, qui accède au Data Marketplace – comme illustré dans la capture d'écran ci-dessus – via le menu Data Marketplace, le Data Provider trouve son accès central pour la gestion de ses Data Products dans le Data Sharing Cockpit.
Dans cette zone, le Data Provider peut consulter ses Data Products publiés, surveiller l'état et effectuer d'autres ajustements.
Il peut également savoir combien d'utilisateurs ont consulté ou installé un Data Product spécifique.
Le Data Provider peut comprendre dans quels espaces suivants le Data Product a été répliqué à l'aide de l'analyse de la lignée et de l'impact, à condition que le transfert de données « Livraison intégrée » (Integrated Delivery) ait été choisi.
Actuellement, il n'existe pas encore de possibilité d'informer automatiquement le Data Provider par notification dans l'interface DSP des événements pertinents liés à son Data Product.
La capture d'écran suivante (voir fig. 8) montre le Data Marketplace du point de vue du Data Provider : la page d'accueil du Data Sharing Cockpit.
4. Contrôler les accès
Alors qu'un contexte régit la visibilité des produits de données, un utilisateur a également besoin de la licence nécessaire pour pouvoir les utiliser.
Comme pour les contextes, l'attribution, l'utilisation et la suppression des licences ainsi que leurs clés d'activation pour le fournisseur de données sont documentées dans le Data Sharing Cockpit, comme illustré à la figure 9. Une licence peut comprendre plusieurs produits de données. De même, un produit de données peut être affecté à différentes licences.
5. Mises à jour des versions de produits
La gestion des publications dans le Data Marketplace permet des mises à jour contrôlées des données via le Data Sharing Cockpit en créant de nouvelles versions pour un Data Product.
Les versions sont présentées sous forme de liste dans un tableau où les utilisateurs peuvent consulter des informations ciblées, telles que l'historique des téléchargements et l'état de la publication, à l'aide de filtres interactifs.
6. Conclusion
En résumé, SAP Datasphere, avec les concepts de fournisseurs de données, de produits de données et de place de marché des données, offre une approche intéressante pour fournir et utiliser les données en tant que produits de données structurés au sein de la plateforme. Le modèle Data-as-a-Product favorise une responsabilité et une gestion décentralisées des données et permet une intégration simple, sans qu'une connaissance approfondie du modèle de données sous-jacent ne soit nécessaire pour la consommation des données.
Le modèle est particulièrement pertinent pour les entreprises qui souhaitent orienter leur stratégie de données vers des approches en libre-service et décharger le service informatique central.
Les utilisateurs peuvent travailler ou consommer des Data Products spécifiques sans avoir à passer par des contrôles d'accès complexes ou des processus d'approbation fastidieux. Selon le transfert de données choisi, la nécessité d'interfaces supplémentaires au sein du même système est supprimée.
Si l'on compare les Data Products avec les vues et les autorisations d'accès conventionnelles, on constate une forte similitude dans la fonctionnalité de base: Les deux approches régissent l'accès aux données et leur utilisation. Toutefois, le Data Marketplace offre une extension, car il permet une mise à disposition des données basée sur le principe du "pull". Au lieu qu'un Data Provider doive activement mettre les données à la disposition d'utilisateurs spécifiques, ceux-ci peuvent rechercher, demander et consommer eux-mêmes les Data Products pertinents. Alors que les approches traditionnelles reposent souvent sur des autorisations prédéfinies et des processus de validation manuels, le Marketplace prend en charge une gestion plus décentralisée et flexible des accès aux données.
Dans sa mise en œuvre actuelle, le concept ne semble pas encore entièrement abouti, surtout si l'on considère la valeur ajoutée par rapport à la fonction de partage existante au sein de la modélisation DSP. Des améliorations pourraient être apportées par des extensions, comme la possibilité de lier directement des objets de métadonnées à des Data Products, de la même manière que c'est déjà le cas pour les Assets. L'intégration d'autres artefacts DSP, tels que les modèles analytiques, pourrait également augmenter considérablement l'utilité pratique des Data Products. Il sera intéressant de voir comment ces approches seront mises en œuvre et développées lors des prochaines phases de développement.
En savoir plus ?
