Monetice los datos con Oracle Cloud Infrastructure

Oracle Cloud Infrastructure (OCI) permite gestionar todo el ciclo de vida de los datos, desde la ingesta de datos, el almacenamiento y el uso, al tiempo que proporciona una seguridad y gobernanza sólidas. Algunos usos de datos se realizan a través de productos de datos, ya sea datos en sí o artefactos derivados de datos, como informes, análisis y predicciones. Es posible que tenga un caso de negocio para monetizar estos productos de datos; por ejemplo, vender datos seleccionados o vender informes o predicciones basados en datos a terceros que puedan utilizar estos productos de datos para sus propias actividades de valor agregado.

Esta arquitectura presenta una forma de monetizar los datos mediante la configuración de un marco de pago que le permite cobrar por el acceso a ellos, lo que lo convierte en un generador de ingresos.

Arquitectura

Esta arquitectura aborda el desafío de cobrar por los productos de datos expuestos a través de una API. Estos productos podrían ser, por ejemplo, datos sin procesar, tal vez expuestos por Oracle Database a través de Oracle REST Data Services (ORDS), un sistema que media el acceso a datos sin procesar (como una aplicación que agrega y filtra datos de una o más fuentes, presentando esos datos a los clientes a través de una API), o alguna funcionalidad derivada de los datos (por ejemplo, predicciones o puntuaciones proporcionadas por un tiempo de ejecución de aprendizaje automático, entrenado en datos propietarios).

Esta arquitectura permite que las solicitudes de los clientes se intercepten, validen y cobren durante el acceso a dichos productos de datos.

Las partes clave de una arquitectura para monetizar datos en OCI son:
  • Un gateway de API que proporciona acceso a productos de datos y aplica políticas que rigen ese acceso.
  • Un proveedor de identidad (aquí, OCI Identity and Access Management [AIM]) que autentica a los clientes de los productos de datos.
  • Una función que autoriza el acceso a productos mediante la comprobación de derechos de acceso y también coordina los cargos por acceso a productos de datos.
  • Un sistema CRM u otra base de datos para realizar un seguimiento de los derechos de los clientes para acceder a productos de datos específicos y establecer las condiciones (por ejemplo, suscripción o pago por uso) que rigen el acceso.
  • Un medio para cobrar a los clientes, ya sea a través de un proveedor de servicios externo (por ejemplo, Stripe) o mediante el registro de una transacción (por ejemplo, como una entrada de cuentas a cobrar en ERP).
  • Servicios que exponen productos de datos, por ejemplo:
    • Autonomous Data Warehouse (ADW), que puede exponer interfaces REST a datos, ofrece API de Delta Sharing y puede ofrecer acceso SQL a sus propios datos y datos en el almacenamiento de objetos.
    • Tiempos de ejecución de aprendizaje automático e inteligencia artificial.
    • Cualquier otro servicio, en la nube o local, que pueda hacer que los datos monetizables estén disponibles
El siguiente diagrama ilustra esta arquitectura de referencia.


Descripción de data-monetization.png siguiente
Descripción de los datos de la ilustración: monetization.png

monetización de datos: oracle.zip

Los productos de datos pueden ser datos en sí mismos (por ejemplo, cifras financieras históricas) o pueden derivarse de datos (por ejemplo, KPI, tendencias, predicciones, puntuaciones) accesibles a través de API, descargas, etc.

La arquitectura anterior funciona de la siguiente manera.
  1. El cliente se autentica con el proveedor de identidad.
  2. El cliente accede a la API del producto de datos a través de un gateway de API, que posteriormente aplicará sus propias políticas (por ejemplo, limitación) después de autorizar la solicitud.
  3. El gateway de API llama a una función para autorizar la solicitud.
  4. La función valida los tokens de cliente proporcionados con el proveedor de identidad.
  5. A continuación, la función comprueba los derechos de acceso del cliente al producto de datos en el CRM u otro sistema y también comprueba si se aplica el pago por suscripción o por uso. Si se aplica una suscripción, la función comprueba si es válida.
  6. La función registra el uso del producto de datos para el pago:
    1. Uso de registro en un libro mayor; y/o
    2. Ejecución de un pago en línea a través de un proveedor de pagos.
  7. Una vez autorizado y monetizado, API Gateway proporciona acceso al producto de datos.
Tenga en cuenta que otras funciones pueden estar implicadas en la entrega de productos de datos; por ejemplo, hacer que los datos estén disponibles a través de una descarga de archivos efímera.

Los pasos 4 y 5 anteriores se pueden implantar como se describe en el documento de OCI Transferencia de tokens a funciones de autorizador para agregar autenticación y autorización a despliegues de API, al que puede acceder desde el tema Explorar más, a continuación, donde la función personalizada comprueba las suscripciones y/o realiza cargos como parte del proceso de autorización. El gateway de API almacenará en caché los resultados de la autorización durante un mínimo de 60 segundos, por lo que si necesita cobrar por solicitudes de clientes individuales que llegan con más frecuencia, puede optar por desplegar la función de autorización como proxy a la API monetizada, como se muestra en la siguiente arquitectura alternativa:


Descripción de alterno-data-monetization.png
Descripción de la ilustración alterno-datos-monetization.png

monetización de datos alternativos: oracle.zip

En esta alternativa, el flujo es ligeramente diferente del anterior.
  1. El cliente se autentica con el proveedor de identidad.
  2. El cliente accede a la API del producto de datos a través de API Gateway, que posteriormente aplicará sus propias políticas (por ejemplo, limitación) después de autorizar la solicitud.
  3. El gateway de API llama a una función para autorizar la solicitud.
  4. La función valida los tokens de cliente proporcionados con el proveedor de identidad
  5. La función comprueba los derechos de acceso del cliente al producto de datos en CRM u otro sistema, y también comprueba si se aplica el pago por suscripción o por uso. Si se aplica una suscripción, las funciones comprueban si esa suscripción es válida.
  6. Una vez autorizado, API Gateway reenvía la solicitud a una función de proxy.
  7. Por solicitud, la función de proxy cobra por el acceso al producto de datos. Tenga en cuenta que este cargo también se puede realizar después de un acceso correcto al producto de datos, evitando la situación en la que se cobra a los clientes si el acceso falla. Los cargos se realizan mediante:
    1. Uso de registro en un libro mayor; y/o
    2. Ejecución de un pago en línea a través de un proveedor de pagos.
  8. La función de proxy accede a los datos monetizados en nombre del cliente.
Esta arquitectura tiene los siguientes componentes:
  • Identity and access management (IAM)

    IAM permite controlar quién puede acceder a sus recursos en OCI y las operaciones que pueden realizar en esos recursos.

  • Gateway de API

    El servicio de Oracle API Gateway le permite publicar API con puntos finales privados accesibles desde su red y que pueden exponerse a la red pública de Internet si es necesario. Los puntos finales admiten la validación de API, la transformación de solicitud y respuesta, CORS, la autenticación y autorización, y la limitación de solicitudes.

  • Functions

    Oracle Functions es una plataforma de funciones como servicio (FaaS). Está alimentado por el motor de origen abierto Fn Project. Las funciones le permiten desplegar el código y llamarlo directamente o dispararlo en respuesta a eventos. Oracle Functions utiliza contenedores de Docker alojados en OCI Registry

Estos orígenes de productos de datos representativos también se encuentran en esta arquitectura de referencia:
  • Autonomous Data Warehouse

    Oracle Autonomous Data Warehouse (ADW) es un servicio de base de datos de autogestión, autoseguridad y autorreparación optimizado para cargas de trabajo de almacenamiento de datos. No necesita configurar ni gestionar ningún hardware, ni instalar ningún software. OCI se ocupa de la creación de la base de datos, así como de la copia de seguridad, la aplicación de parches, el cambio de versión y el ajuste de la base de datos.

  • Oracle Machine Learning

    Oracle Machine Learning, o Machine Learning de Oracle Database, admite la exploración, preparación y modelado de datos a escala mediante SQL, R, Python, REST, aprendizaje automático automatizado (AutoML) e interfaces sin código, que se ejecutan directamente en los datos de la base de datos. Permite el despliegue y la gestión de modelos nativos en la base de datos y modelos en formato ONNX en el entorno de Oracle Autonomous Database. Los desarrolladores de aplicaciones utilizan modelos a través de puntos finales REST fáciles de integrar.

Recomendaciones

Utilice las siguientes recomendaciones como punto de partida para monetizar datos con Oracle Cloud Infrastructure. Los requisitos pueden diferir de la arquitectura que se describe aquí.
  • Productos de datos

    Casi cualquier cuerpo de datos, o cualquier cosa derivada de los datos, puede ser un producto de datos. Los productos de datos útiles ofrecen valor al ser completos y confiables, y normalmente alcanzan ese estado a través de algún tipo de curación por parte del propietario del producto de datos. La gobernanza de datos forma una parte clave de la gestión de productos de datos, que abarca la catalogación de datos, el control de acceso y la gestión de la calidad de los datos, y el seguimiento del linaje, todos los aspectos de los productos de datos que están fuera del enfoque estrecho de esta arquitectura y, por lo tanto, no se muestran. Oracle recomienda, pero no es necesario, que tenga en cuenta los ciclos de vida y la gestión de los productos de datos al considerar el despliegue de un marco de monetización de datos, como el que se presenta aquí.

  • Seguridad

    Utilice Oracle Cloud Guard para supervisar y mantener la seguridad de los recursos en Oracle Cloud Infrastructure de manera proactiva. Cloud Guard utiliza recetas de detector que puede definir para examinar los recursos en busca de deficiencias de seguridad y para supervisar a los operadores y usuarios en busca de actividades de riesgo. Cuando se detecta cualquier actividad no segura o de configuración incorrecta, Cloud Guard recomienda acciones correctivas y ayuda a realizar esas acciones, según las recetas de responsable de respuesta que pueda definir.

    Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta de políticas de seguridad definida por Oracle que se basa en las mejores prácticas. Por ejemplo, los recursos de una zona de seguridad no deben ser accesibles desde la red Internet pública y se deben cifrar mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con respecto a las políticas de la receta de zona de seguridad y deniega las operaciones que violan cualquiera de las políticas.

  • Cloud Guard

    Clone y personalice las recetas por defecto proporcionadas por Oracle para crear recetas personalizadas de detector y responsable de respuesta. Estas recetas permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar cubos de Object Storage que tengan la visibilidad definida en público.

    Aplique Cloud Guard en el nivel de arrendamiento para abarcar el ámbito más amplio y reducir la carga administrativa que supone mantener varias configuraciones.

    También puede utilizar la función Lista gestionada para aplicar determinadas configuraciones a los detectores.

Consideraciones

Tenga en cuenta los siguientes puntos al desplegar esta arquitectura.

  • Enfoque de monetización

    Considere cómo se debe cobrar a los clientes por el acceso a los productos de datos. ¿Es adecuado un enfoque de pago por acceso (por ejemplo, el uso de Stripe) o es más adecuado un enfoque basado en suscripción más completo dadas las interacciones esperadas con los productos de datos?

  • Gestión de clientes y suscripciones

    ¿Cómo se registran los derechos de los clientes para acceder a productos de datos específicos y cómo se gestionan las suscripciones a productos de datos, si es necesario? Esta arquitectura muestra cómo se pueden disparar los pagos por acceso a productos de datos, pero si se requiere más de un simple pago único por uso, se requiere algún tipo de registro de los derechos de los clientes para acceder a productos de datos específicos, y puede ser necesario algún tipo de marco de gestión de suscripciones. ¿Estas funciones están disponibles a través de su sistema CRM? ¿Son sus requisitos lo suficientemente sencillos como para desplegar su propia solución personalizada o se necesita un componente de gestión de suscripciones más capaz?

  • Aprovisionamiento de usuarios y control de acceso

    Cuando los clientes tienen acceso a productos de datos, ¿cómo se aprovisionan en OCI IAM (que los autentica)? ¿Cómo se anula el aprovisionamiento cuando se revocan sus derechos de acceso? Estas consideraciones surgen como parte del debate más amplio sobre cómo y a quién se ponen a disposición los productos de datos monetizados.

Explorar más

Más información sobre la monetización de datos con Oracle Cloud Infrastructure.

Revise estos recursos adicionales:

Agradecimientos

Author: Gareth Smith