Monetize Dados com o Oracle Cloud Infrastructure

O Oracle Cloud Infrastructure (OCI) permite que você gerencie o ciclo de vida completo dos dados, desde a ingestão, armazenamento e uso, fornecendo forte segurança e governança. Alguns usos de dados são por meio de produtos de dados, os próprios dados ou artefatos derivados de dados, como relatórios, análises e previsões. Você pode ter um caso de negócios para monetizar esses produtos de dados; por exemplo, vender dados selecionados ou vender relatórios ou previsões com base em dados, para terceiros que podem usar esses produtos de dados para suas próprias atividades de valor agregado.

Essa arquitetura apresenta uma maneira de monetizar dados configurando uma estrutura de pagamento que permite cobrar pelo acesso a ela, tornando-a um gerador de receita.

Arquitetura

Essa arquitetura aborda o desafio de cobrar pelos produtos de dados expostos por meio de uma API. Esses produtos podem ser, por exemplo, dados brutos, talvez expostos pelo Oracle Database por meio do Oracle REST Data Services (ORDS), um sistema que medeia o acesso a dados brutos (como um aplicativo que agrega e filtra dados de uma ou mais fontes, apresentando esses dados aos clientes por meio de uma API), ou alguma funcionalidade derivada de dados (por exemplo, previsões ou pontuações entregues por um tempo de execução de aprendizado de máquina, treinados em dados proprietários).

Essa arquitetura permite que as solicitações do cliente sejam interceptadas, validadas e cobradas durante o acesso a esses produtos de dados.

As principais partes de uma arquitetura para monetizar dados na OCI são:

• Um serviço API Gateway que fornece acesso aos produtos de dados e aplica políticas que controlam esse acesso.
• Um Provedor de Identidades (aqui, OCI Identity and Access Management [AIM]) que autentica os clientes dos produtos de dados.
• Uma função que autoriza o acesso a produtos verificando direitos de acesso e também coordena a cobrança pelo acesso a produtos de dados.
• Um sistema CRM, ou outro banco de dados, para rastrear os direitos dos clientes de acessar produtos de dados específicos e estabelecer os termos (por exemplo, assinatura ou pagamento por uso) que controlam o acesso.
• Um meio de cobrar os clientes, seja por meio de um provedor de serviços de terceiros (por exemplo, Stripe) ou registrando uma transação (por exemplo, como uma entrada de Contas a Receber no ERP).
• Serviços que expõem produtos de dados, por exemplo:
  • O Autonomous Data Warehouse (ADW), que pode expor interfaces REST a dados, oferece APIs de Compartilhamento Delta e pode oferecer acesso SQL a seus próprios dados e dados no armazenamento de objetos.
  • Machine learning e tempos de execução de IA.
  • Quaisquer outros serviços, na nuvem ou no local, que possam disponibilizar dados monetizáveis

O diagrama a seguir ilustra essa arquitetura de referência.

Descrição da ilustração de dados-monetization.png

monetização de dados-oracle.zip

Os produtos de dados podem ser dados propriamente ditos (por exemplo, números financeiros históricos) ou podem ser derivados de dados (por exemplo, KPIs, tendências, previsões, pontuações) acessíveis por meio de APIs, downloads etc.

A arquitetura acima funciona da seguinte forma.

1. O cliente faz a autenticação com o provedor de identidades.
2. O cliente acessa a API do produto de dados por meio de um Gateway de API, que posteriormente aplicará suas próprias políticas (por exemplo, limitação) após autorizar a solicitação.
3. O Gateway de API chama uma função para autorizar a solicitação.
4. A função valida os tokens de cliente fornecidos com o provedor de identidades.
5. Em seguida, a função verifica os direitos de acesso do cliente ao produto de dados no CRM ou em outro sistema e também verifica se o pagamento por assinatura ou por uso se aplica. Se uma assinatura se aplicar, a função verificará se ela é válida.
6. A função registra o uso do produto de dados para pagamento:
   1. Uso de gravação em um razão; e/ou
   2. Executar um pagamento on-line por meio de um provedor de pagamento.
7. Uma vez autorizado e monetizado, o Gateway de API fornece acesso ao produto de dados.

Observe que outras funções podem estar envolvidas na entrega de produtos de dados; por exemplo, disponibilizar dados por meio de um download efêmero de arquivos.

As etapas 4 e 5 acima podem ser implementadas conforme descrito no documento do OCI, Passando Tokens a Funções de Autorizador para Adicionar Autenticação e Autorização a Implantações de API - que você pode acessar no tópico Explorar Mais, abaixo - em que sua função personalizada verifica assinaturas e/ou executa a cobrança como parte do processo de autorização. O Gateway de API armazenará em cache os resultados da autorização por um mínimo de 60 segundos; portanto, se você precisar cobrar por solicitações de clientes individuais que vêm com mais frequência, poderá optar por implantar a função de autorização como proxy para a API monetizada, conforme mostrado na arquitetura alternativa abaixo:

Descrição da ilustração alternate-data-monetization.png

alternate-data-monetization-oracle.zip

Nesta alternativa, o fluxo é ligeiramente diferente do acima.

1. O cliente faz a autenticação com o provedor de identidades.
2. O cliente acessa a API do produto de dados por meio do API Gateway, que posteriormente aplicará suas próprias políticas (por exemplo, limitação) após autorizar a solicitação.
3. O Gateway de API chama uma função para autorizar a solicitação.
4. A função valida os tokens de cliente fornecidos com o provedor de identidades
5. A função verifica os direitos de acesso do cliente ao produto de dados no CRM ou em outro sistema e também verifica se o pagamento por assinatura ou por uso se aplica. Se uma assinatura se aplicar, as funções verificarão se essa assinatura é válida.
6. Uma vez autorizado, o Gateway de API encaminha a solicitação para uma função de proxy.
7. Por solicitação, a função de proxy cobra pelo acesso ao produto de dados. Observe que essa cobrança também pode ser feita após um acesso bem-sucedido ao produto de dados, evitando a situação em que os clientes são cobrados se o acesso falhar. O carregamento é feito por:
   1. Uso de gravação em um razão; e/ou
   2. Executar um pagamento on-line por meio de um provedor de pagamento.
8. A função proxy acessa os dados monetizados em nome do cliente.

Esta arquitetura inclui os seguintes componentes:

• Identity and Access Management (IAM)

  O IAM permite controlar quem pode acessar seus recursos no OCI e as operações que eles podem executar nesses recursos.

• Gateway de API

  O serviço Oracle API Gateway permite que você publique APIs com pontos finais privados acessíveis na sua rede e que você pode expor à internet pública, se necessário. Os pontos finais suportam validação de API, transformação de solicitação e resposta, CORS, autenticação e autorização e limitação de solicitação.

• Serviço Functions

  O Oracle Functions é uma plataforma Functions-as-a-Service (FaaS) totalmente gerenciada, multitenant, altamente escalável e sob demanda. Ele é alimentado pelo mecanismo de código aberto do Fn Project. As funções permitem que você implante seu código e o chame diretamente ou o acione em resposta a eventos. O Oracle Functions usa contêineres Docker hospedados no OCI Registry

Essas fontes de produtos de dados representativas também estão nesta arquitetura de referência:

• Autonomous Data Warehouse

  O Oracle Autonomous Data Warehouse (ADW) é um serviço de banco de dados autônomo, de segurança e autorreparo otimizado para cargas de trabalho de data warehousing. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. A OCI lida com a criação do banco de dados, bem como com o backup, a aplicação de patches, o upgrade e o ajuste do banco de dados.

• Oracle Machine Learning

  O Oracle Machine Learning, ou Machine Learning no Oracle Database, suporta exploração de dados, preparação e modelagem de aprendizado de máquina em escala usando SQL, R, Python, REST, aprendizado de máquina automatizado (AutoML) e interfaces sem código, executadas diretamente nos dados no banco de dados. Ele permite a implantação e o gerenciamento de modelos nativos no banco de dados e modelos no formato ONNX no ambiente do Oracle Autonomous Database. Os desenvolvedores de aplicativos usam modelos por meio de pontos finais REST fáceis de integrar.

Recomendações

Use as recomendações a seguir como ponto de partida ao monetizar dados com o Oracle Cloud Infrastructure. Seus requisitos podem ser diferentes da arquitetura descrita aqui.

• Produtos de Dados

  Quase qualquer corpo de dados, ou qualquer coisa derivada de dados, pode ser um produto de dados. Produtos de dados úteis oferecem valor por serem abrangentes e confiáveis, e normalmente alcançam esse status por meio de algum tipo de curadoria por um proprietário de produto de dados. A governança de dados constitui uma parte fundamental do gerenciamento de produtos de dados, abrangendo catalogação de dados, controle de acesso e gerenciamento de qualidade de dados e rastreamento de linhagem - todos os aspectos dos produtos de dados que estão fora do foco restrito dessa arquitetura e, portanto, não são mostrados. A Oracle recomenda, mas não é necessário, que você considere o ciclo de vida e o gerenciamento de produtos de dados ao considerar a implementação de uma estrutura de monetização de dados, como a apresentada aqui.

• Segurança

  Use o Oracle Cloud Guard para monitorar e manter a segurança de seus recursos no Oracle Cloud Infrastructure de forma proativa. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos quanto a pontos fracos de segurança e monitorar operadores e usuários em busca de atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a executar essas ações, com base nas receitas do respondedor que você pode definir.

  Para recursos que exigem segurança máxima, a Oracle recomenda o uso de zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita definida pela Oracle de políticas de segurança baseadas nas melhores práticas. Por exemplo, os recursos de uma zona de segurança não devem ser acessíveis por meio da internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você criar e atualizar recursos em uma zona de segurança, o Oracle Cloud Infrastructure validará as operações de acordo com as políticas na receita de zona de segurança e negará as operações que violarem qualquer uma das políticas.

• Cloud Guard

  Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas do detector e do respondedor. Essas receitas permitem especificar que tipo de violações de segurança geram uma advertência e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública.

  Aplique o Cloud Guard no nível da tenancy para cobrir o escopo mais amplo e reduzir a carga administrativa de manter várias configurações.

  Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.

Considerações

Considere os pontos a seguir ao implantar essa arquitetura.

• Abordagem de monetização

  Considere como os clientes devem ser cobrados pelo acesso aos produtos de dados. Uma abordagem de pagamento por acesso (por exemplo, usando o Stripe) é adequada ou uma abordagem baseada em assinatura mais abrangente é mais apropriada, dadas as interações esperadas do cliente com os produtos de dados?

• Gerenciamento de Cliente e Assinatura

  Como os direitos dos clientes de acessar produtos de dados específicos são registrados e como as assinaturas de produtos de dados são gerenciadas, se necessário? Essa arquitetura mostra como os pagamentos de acesso a produtos de dados podem ser acionados, mas, se for necessário mais do que um pagamento único simples por uso, será necessário algum tipo de registro dos direitos dos clientes de acessar produtos de dados específicos e algum tipo de estrutura de gerenciamento de assinatura poderá ser necessário. Essas funções estão disponíveis através do seu sistema CRM? Seus requisitos são simples o suficiente para implementar sua própria solução personalizada ou é necessário um componente de gerenciamento de assinatura mais capaz?

• Provisionamento de Usuários e Controle de Acesso

  Quando os clientes recebem acesso a produtos de dados, como eles são provisionados no OCI IAM (o que os autentica)? Como eles são desprovisionados quando seus direitos de acesso devem ser revogados? Essas considerações surgem como parte da discussão mais ampla sobre como e para quem os produtos de dados monetizados são disponibilizados.

Explorar Mais

Saiba mais sobre a monetização de dados com o Oracle Cloud Infrastructure.

Revise estes recursos adicionais:

• Estrutura de melhores práticas do Oracle Cloud Infrastructure

• Especificando Tokens para Funções de Autorizador para Adicionar Autenticação e Autorização a Implantações de API

• Gateway de API do OCI

• Funções do OCI

• OCI Data Catalog (parte de uma estrutura de governança de produtos de dados)

• Autonomous Data Warehouse (origem potencial de produtos de dados)

• Serviço IAM com Domínios de Identidade (para gerenciamento de identidade e acesso)

• Oracle Machine Learning (maneira potencial de oferecer produtos de dados derivados de dados)

Agradecimentos

Author: Gareth Smith