Monétiser les données avec Oracle Cloud Infrastructure

Oracle Cloud Infrastructure (OCI) vous permet de gérer le cycle de vie complet des données, de l'assimilation des données à l'utilisation en passant par le stockage, tout en offrant une sécurité et une gouvernance fortes. Certaines utilisations de données se font via des produits de données, soit des données elles-mêmes, soit des artefacts dérivés de données, tels que des rapports, des analyses et des prédictions. Vous pouvez avoir une analyse de rentabilisation pour monétiser ces produits de données ; par exemple, vendre des données organisées, ou vendre des rapports ou des prévisions basés sur des données, à des tiers qui peuvent utiliser ces produits de données pour leurs propres activités à valeur ajoutée.

Cette architecture présente un moyen de monétiser les données en configurant un cadre de paiement qui vous permet de facturer l'accès à ces données, ce qui en fait un générateur de revenus.

Architecture

Cette architecture permet de relever le défi de la facturation des produits de données exposés via une API. Ces produits peuvent être, par exemple, des données brutes, peut-être exposées par Oracle Database via Oracle REST Data Services (ORDS), un système qui gère l'accès aux données brutes (comme une application qui agrège et filtre les données à partir d'une ou plusieurs sources, en présentant ces données aux clients via une API), ou de certaines fonctionnalités dérivées de données (par exemple, des prédictions ou des scores fournis par une exécution de machine learning, entraînées sur des données propriétaires).

Cette architecture permet aux demandes des clients d'être interceptées, validées et facturées pendant l'accès à ces produits de données.

Les éléments clés d'une architecture pour monétiser les données sur OCI sont les suivants :
  • API Gateway qui fournit l'accès aux produits de données et applique des stratégies régissant cet accès.
  • Un fournisseur d'identités (ici, OCI Identity and Access Management [AIM]) qui authentifie les clients des produits de données.
  • Fonction qui autorise l'accès aux produits en vérifiant les droits d'accès et coordonne également la facturation de l'accès aux produits de données.
  • Système CRM, ou autre base de données, permettant de suivre les droits des clients d'accéder à des produits de données spécifiques et d'établir les conditions (par exemple, abonnement ou paiement à l'utilisation) qui régissent l'accès.
  • Moyen de facturer les clients, soit par l'intermédiaire d'un fournisseur de services tiers (par exemple, Stripe), soit en enregistrant une transaction (par exemple, en tant qu'entrée Comptabilité clients dans ERP).
  • Services exposant des produits de données, par exemple :
    • Autonomous Data Warehouse (ADW), qui peut exposer les interfaces REST aux données, propose des API de partage Delta et peut offrir un accès SQL à ses propres données et données dans le stockage d'objets.
    • Le machine learning et les exécutions d'IA.
    • Tous les autres services, sur le cloud ou sur site, qui peuvent rendre les données monétisables disponibles
Le diagramme suivant illustre cette architecture de référence.


Description des données : monetization.png suit
Description des données de l'illustration : monetization.png

monétisation des données-oracle.zip

Les produits de données peuvent être des données elles-mêmes (par exemple, des chiffres financiers historiques) ou des données (par exemple, des KPI, des tendances, des prévisions, des scores) rendues accessibles via des API, des téléchargements, etc.

L'architecture ci-dessus fonctionne comme suit.
  1. Le client s'authentifie auprès du fournisseur d'identités.
  2. Le client accède à l'API du produit de données via une passerelle d'API, qui appliquera ultérieurement ses propres stratégies (par exemple, la limitation) après avoir autorisé la demande.
  3. API Gateway appelle une fonction pour autoriser la demande.
  4. La fonction valide les jetons client fournis avec le fournisseur d'identités.
  5. La fonction vérifie ensuite les droits d'accès du client au produit de données dans le CRM ou un autre système et vérifie également si l'abonnement ou le paiement à l'utilisation s'applique. Si un abonnement s'applique, la fonction vérifie s'il est valide.
  6. La fonction enregistre l'utilisation du produit de données pour le paiement :
    1. l'utilisation de l'enregistrement dans un grand livre ; et/ou
    2. Exécuter un paiement en ligne par l'intermédiaire d'un fournisseur de paiement.
  7. Une fois autorisée et monétisée, API Gateway fournit l'accès au produit de données.
Notez que d'autres fonctions peuvent être impliquées dans la fourniture de produits de données, par exemple la mise à disposition de données via un téléchargement de fichier éphémère.

Les étapes 4 et 5 ci-dessus peuvent être implémentées comme décrit dans le document OCI, Transmission de jetons aux fonctions d'autorisation pour ajouter l'authentification et l'autorisation aux déploiements d'API, auquel vous pouvez accéder à partir de la rubrique Explorer plus, ci-dessous, où votre fonction personnalisée vérifie les abonnements et/ou effectue la facturation dans le cadre du processus d'autorisation. La passerelle d'API mettra en cache les résultats de l'autorisation pendant au moins 60 secondes. Par conséquent, si vous devez facturer des demandes client individuelles plus fréquentes, vous pouvez choisir de déployer la fonction d'autorisation en tant que proxy pour l'API monétisée, comme indiqué dans l'architecture alternative ci-dessous :


La description de alter-data-monetization.png suit
Description de l'image alternative-data-monetization.png

alternative-data-monetization-oracle.zip

Dans cette variante, le débit est légèrement différent de celui ci-dessus.
  1. Le client s'authentifie auprès du fournisseur d'identités.
  2. Le client accède à l'API de produit de données via API Gateway, qui appliquera ultérieurement ses propres stratégies (par exemple, la limitation) après avoir autorisé la demande.
  3. API Gateway appelle une fonction pour autoriser la demande.
  4. La fonction valide les jetons client fournis avec le fournisseur d'identités
  5. La fonction vérifie les droits d'accès du client au produit de données dans CRM ou tout autre système, et vérifie également si le paiement par abonnement ou par utilisation s'applique. Si un abonnement s'applique, les fonctions vérifient si cet abonnement est valide.
  6. Une fois autorisée, la passerelle d'API transmet la demande à une fonction proxy.
  7. Sur une base par demande, la fonction proxy facture l'accès au produit de données. Notez que cette facturation peut également être effectuée après un accès réussi au produit de données, évitant ainsi que les clients soient facturés en cas d'échec de l'accès. La facturation est effectuée par :
    1. l'utilisation de l'enregistrement dans un grand livre ; et/ou
    2. Exécuter un paiement en ligne par l'intermédiaire d'un fournisseur de paiement.
  8. La fonction proxy accède aux données monétisées pour le compte du client.
Cette architecture comporte les composants suivants :
  • Identity and Access Management (IAM)

    IAM vous permet de contrôler qui peut accéder à vos ressources dans OCI et les opérations qu'ils peuvent effectuer sur ces ressources.

  • Passerelle d'API

    Le service Oracle API Gateway vous permet de publier des API avec des adresses privées accessibles à partir de votre réseau, et que vous pouvez exposer sur le réseau Internet public si nécessaire. Les adresses prennent en charge la validation d'API, la transformation des demandes et des réponses, l'authentification et l'autorisation CORS, ainsi que la limitation des demandes.

  • Functions

    Oracle Functions est une plate-forme Functions-as-a-Service (FaaS) entièrement gérée, colocative, hautement évolutive, à la demande. Il est alimenté par le moteur open source du projet Fn. Les fonctions vous permettent de déployer votre code, et de l'appeler directement ou de le déclencher en réponse à des événements. Oracle Functions utilise des conteneurs Docker hébergés dans OCI Registry

Ces sources représentatives de produits de données figurent également dans cette architecture de référence :
  • Autonomous Data Warehouse

    Oracle Autonomous Data Warehouse (ADW) est un service de base de données autonome, auto-sécurisé et auto-réparable optimisé pour les charges de travail d'entreposage de données. Vous n'avez pas besoin de configurer ou de gérer du matériel, ni d'installer un logiciel. OCI gère la création, la sauvegarde, la mise à niveau et le réglage de la base de données, ainsi que l'application de patches à la base de données.

  • Oracle Machine Learning

    Oracle Machine Learning, ou Machine Learning dans Oracle Database, prend en charge l'exploration, la préparation et la modélisation de données d'apprentissage automatique à grande échelle à l'aide d'interfaces SQL, R, Python, REST, d'apprentissage automatique automatisé (AutoML) et sans code, exécutées directement sur les données de la base de données. Il permet le déploiement et la gestion de modèles natifs dans la base de données et de modèles au format ONNX dans l'environnement Oracle Autonomous Database. Les développeurs d'applications utilisent des modèles via des adresses REST faciles à intégrer.

Recommandations

Utilisez les recommandations suivantes comme point de départ lors de la monétisation des données avec Oracle Cloud Infrastructure. Vos exigences peuvent différer de l'architecture décrite ici.
  • Produits de données

    Presque n'importe quel corps de données, ou n'importe quoi dérivé de données, peut être un produit de données. Les produits de données utiles offrent de la valeur en étant complets et dignes de confiance, et obtiennent normalement ce statut grâce à une sorte de conservation par un propriétaire de produit de données. La gouvernance des données constitue un élément clé de la gestion des produits de données, couvrant le catalogue de données, le contrôle d'accès et la gestion de la qualité des données, ainsi que le suivi du lignage, tous les aspects des produits de données qui ne sont pas ciblés par cette architecture et ne sont donc pas présentés. Oracle recommande, mais pas nécessaire, de prendre en compte les cycles de vie et la gestion des produits de données lors du déploiement d'une structure de monétisation des données, telle que celle présentée ici.

  • Sécurité

    Utilisez Oracle Cloud Guard pour surveiller et maintenir la sécurité de vos ressources dans Oracle Cloud Infrastructure de manière proactive. Cloud Guard utilise des recettes de détecteur que vous pouvez définir pour examiner vos ressources à la recherche de failles de sécurité et pour surveiller les opérateurs et les utilisateurs à la recherche d'activités à risque. En cas de détection d'une mauvaise configuration ou d'une activité non sécurisée, Cloud Guard recommande des actions correctives et aide à effectuer ces actions, en fonction des recettes de répondeur que vous pouvez définir.

    Pour les ressources nécessitant une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle basée sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles à partir du réseau Internet public et elles doivent être cryptées à l'aide de clés gérées par le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations par rapport aux stratégies de la recette de zone de sécurité et refuse les opérations qui enfreignent l'une des stratégies.

  • Cloud Guard

    Clonez et personnalisez les recettes par défaut fournies par Oracle pour créer des recettes de détecteur et de répondeur personnalisées. Ces recettes vous permettent de spécifier le type de violation de sécurité qui génère un avertissement et les actions autorisées. Par exemple, vous pouvez détecter les buckets Object Storage dont la visibilité est définie sur Public.

    Appliquez Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire la charge administrative liée à la maintenance de plusieurs configurations.

    Vous pouvez également utiliser la fonctionnalité Liste gérée pour appliquer certaines configurations aux détecteurs.

Points à prendre en compte

Tenez compte des points suivants lors du déploiement de cette architecture.

  • Approche de monétisation

    Déterminez comment les clients doivent être facturés pour l'accès aux produits de données. Une approche de paiement par accès (par exemple, l'utilisation de Stripe) est-elle appropriée, ou une approche plus complète basée sur l'abonnement est-elle plus appropriée compte tenu des interactions client attendues avec les produits de données ?

  • Gestion des clients et des abonnements

    Comment les droits des clients d'accéder à des produits de données spécifiques sont-ils enregistrés et comment les abonnements aux produits de données sont-ils gérés, si nécessaire ? Cette architecture montre comment les paiements pour l'accès aux produits de données peuvent être déclenchés, mais si plus d'un simple paiement unique par utilisation est requis, une sorte d'enregistrement des droits des clients pour accéder à des produits de données spécifiques est nécessaire et une sorte de structure de gestion des abonnements peut être requise. Ces fonctions sont-elles disponibles via votre système CRM ? Vos exigences sont-elles suffisamment simples pour déployer votre propre solution personnalisée ou un composant de gestion des abonnements plus performant est-il requis ?

  • Provisionnement des utilisateurs et contrôle d'accès

    Lorsque les clients ont accès aux produits de données, comment sont-ils provisionnés dans OCI IAM (qui les authentifie) ? Comment sont-ils déprovisionnés lorsque leurs droits d'accès doivent être révoqués ? Ces considérations s'inscrivent dans le cadre d'un débat plus large sur la manière et à qui les produits de données monétisés sont mis à disposition.

En savoir plus

En savoir plus sur la monétisation des données avec Oracle Cloud Infrastructure.

Consultez les ressources supplémentaires suivantes :

Remerciements

Author: Gareth Smith