Esse artigo apresenta uma abordagem sobre como utilizar o Canvas para a estruturação de um produto de dados.

A abordagem sobre Data Product de maneira literal sempre foi importante quando se está trabalhando com Analytics. No BI tradicional já usamos, há mais de duas décadas, metodologias para criar Data Marts, Reports e Algoritmos. E as empresas com mais maturidade em estatísticas, como o setor financeiro, direcionam a modelagem analítica de crédito e risco dentro das áreas de negócios e não na TI, portanto executam um trabalho mais orientado a produto de dados e negócios.

O que está mudando?

Na última década, a massificação de Analytics e AI adicionou ao backlog da TI as funções de arquitetura de dados e engenharia com amplas abordagens, começando pelo Data Lake nas organizações, estendendo as capacidades do DW com Big Data, DataOps, ingestão, Data Science e muito mais. Esta avalanche de dados e soluções baseadas em novas arquiteturas foram pouco direcionadas a entregas tangíveis de negócios.

Como abordamos em nosso artigo sobre os princípios do Data Mesh, o objetivo do Data Mesh é criar uma base para obter valor de dados analíticos e fatos históricos em escala, sendo aplicada à mudança constante do cenário de dados, proliferação de fontes de dados e consumidores, diversidade de transformação e processamento que os casos de uso exigem, velocidade de resposta à mudança.

O primeiro princípio para a arquitetura Data Mesh é o Data Product, que é explicado abaixo.

Data Product

Os dados analíticos fornecidos pelos domínios devem ser tratados como um produto, e os consumidores desses dados devem ser tratados como clientes, clientes felizes e encantados. Os produtos de dados devem ser compostos por dados limpos, atualizados e completos, dessa forma são entregues a qualquer consumidor de dados, a qualquer hora, em qualquer lugar, com base em permissões e funções.

Existe uma maneira melhor de construir e administrar uma organização de dados: execute-a como se você estivesse construindo um produto de dados e todos os seus colegas fossem seus clientes.

Acreditamos que isso tem a capacidade de transformar a organização e ajudar as equipes a alcançarem seu verdadeiro potencial.

Na mentalidade da organização de serviço, a oportunidade é desperdiçada. Mas quando você começa a ver seus dados como um produto que ajuda a orientar as decisões, então você tem a chance de maximizar o potencial.

Data Product Development Canvas é uma ferramenta fácil de entender e que facilita a colaboração da equipe de negócios e de dados na triagem do problema, focando na identificação dos dados e componentes analíticos para o desenvolvimento de um produto de dados com o objetivo de alcançar um resultado específico.

Modelo Data Product Canvas - triggo.ai
Modelo de Canvas para Data Product

Esse é um framework baseado em um modelo Canvas, que segue os princípios da metodologia Ágil/Lean. Seu principal objetivo é servir como uma ferramenta prática para a geração do roadmap de produtos de dados, alinhando em um único documento a visão completa de todos os envolvidos sobre o real propósito do projeto.

Um pouco mais de contexto sobre Data Product

De acordo com J. Majchrzak, um “produto de dados é uma unidade de dados padronizada, otimizada para leitura e autônoma, que contém pelo menos um conjunto de dados (conjunto de dados de domínio) criado para satisfazer as necessidades do usuário”.

Conceitualmente, uma malha (mesh) é um grafo, uma rede, consistindo em nós e arestas de conexão. Cada nó no Data Mesh é chamado de produto de dados. Cada produto de dados existe dentro de um contexto limitado, e um contexto limitado pode conter vários produtos de dados.

Como em toda estrutura, a arquitetura de dados também tem uma arquitetura de pessoas. Portanto, precisamos considerar pessoas e processos, além da tecnologia, para o gerenciamento de dados. É preciso também levar em conta que, como temos consumidores para nossos dados, esses esperam uma certa qualidade. Portanto, nossos dados precisam estar acessíveis e todos devem saber onde encontrá-los. Assim, a perspectiva sociotécnica nos leva a adotar a filosofia de pensamento de produto para dados → produtos de dados.

Construir e manter produtos de dados é um investimento financeiro e ocupa a capacidade da equipe de domínio (times de negócios e outros). Portanto, o valor e os custos precisam ser avaliados antecipadamente.

O que poderia ser um produto de dados? Geralmente, qualquer representação de dados que tenha valor para seus consumidores (usuários) pode ser um bom candidato. A seguir, você encontrará uma lista de exemplos de possíveis produtos de dados:

  • Uma tabela ou view;
  • Banco de dados de gerenciamento de dados mestre;
  • Modelos de aprendizado de máquina;
  • Data Applications;
  • Dashboard e painéis de visualizações;
  • API REST: dados otimizados para leitura que são expostos em aplicativos;
  • Arquivos não estruturados brutos, como imagens ou vídeos enviados por usuários de um portal de vídeo (que se tornam valiosos para os consumidores quando recebem metadados);
  • Fluxo de dados de entidades em um sistema de transações;
  • Fluxo de dados que representa o histórico de alterações no aplicativo, como eventos relacionados a alterações feitas em uma conta de cobrança;
  • Arquivos simples, como dados em formato CSV, arquivos Excel, JSON, etc.;
  • Arquivos particionados em formato otimizado (Parquet).

Data Product Canvas

Para estabelecer um processo estruturado de design de produtos de dados em uma organização, propomos começar com um Data Product Canvas. 

Estruturação de um Canvas para Data Product - triggo.ai
Estruturação de um Canvas para Data Product

Um Data Product Canvas é uma estrutura visual que orienta sua equipe pela especificação do produto de dados. Sugerimos preencher esta tela de forma colaborativa. No total, o Data Product Canvas consiste em dez blocos de construção:

  1. Domínio;
  2. Nome do produto de dados;
  3. Consumidor e caso de uso
  4. Output Ports;
  5. Metadados;
  6. Input Ports;
  7. Projeto de produto de dados;
  8. Observabilidade;
  9. Linguagem ubíqua;
  10. Classificação.

A seguir, descrevemos cada um dos blocos de construção que constituem o produto de dados. A ordem dos blocos de construção representa a sequência recomendada das etapas colaborativas durante o workshop.

Domínio: cada produto de dados deve ser implementado, evoluído e mantido apenas por uma equipe de domínio. Portanto, cada produto de dados pertence exclusivamente a um domínio. As seguintes possíveis perguntas são relevantes neste bloco de construção:

  • Quem é responsável pelo produto de dados?
  • Quem especifica seus requisitos?
  • Quem responderá a perguntas sobre o produto de dados?
  • Quem conserta quando quebra?

Nome do produto de dados: cada produto de dados tem um nome exclusivo para ser identificado e acessado dentro de uma organização. Normalmente, o nome do produto deve seguir a estratégia de nomenclatura comum.

Casos de uso e consumidor: este bloco de construção descreve a razão por trás da existência do produto de dados. O design de produtos de dados segue a filosofia “Product Thinking”. Sempre começamos com as necessidades do consumidor.

Para identificar o propósito do produto de dados, descrevemos casos de uso analíticos e objetivos organizacionais. Compreender os casos de uso é essencial para especificar os dados necessários para a implementação. O consumidor do futuro produto de dados pode ser nossa própria equipe de domínio ou equipes de domínio diferentes.

Output Ports: as portas de saída definem o formato e o protocolo de consumo em que os dados podem ser expostos. Por exemplo, a porta de saída pode ser uma tabela de banco de dados, arquivo, API ou visualizações.

Metadados: além da especificação da porta de saída, o produto de dados deve definir seus metadados.

  • A parte de propriedade descreve o nome de domínio, proprietário do produto, unidade organizacional, licença, versão e data de expiração provável do produto de dados;
  • A parte do esquema de dados descreve atributos, tipos de dados, restrições e relacionamentos com outros elementos na unidade de dados (por exemplo, dependências funcionais);
  • A parte semântica fornece descrição sobre o modelo lógico da unidade de dados;
  • O bloco de segurança descreve as regras de segurança aplicadas ao uso do produto de dados, por exemplo, atributos públicos, organizacionais, internos e PII.

A discussão sobre os atributos necessários do conjunto de dados e seu significado contribui para a compreensão da equipe sobre os dados em si.

Input Ports: este bloco de construção descreve os dados de entrada para o produto de dados futuro. As portas de entrada estão recebendo o mecanismo dos dados que constituirão o produto de dados. As portas de entrada definem o formato e o protocolo em que os dados podem ser lidos. Distinguimos aqui entre sistemas operacionais de origem e outros produtos de dados, que podem ser internos ou provenientes de outros domínios.

Projeto de produto de dados: este é o bloco de construção principal, onde projetamos os componentes internos do produto de dados. Este é o local para especificar tudo entre as portas de entrada e saída. É aqui que deve ser descrito tudo o que é preciso para projetar um produto de dados em um nível conceitual. Por exemplo, você pode descrever a ingestão de dados, armazenamento, transporte, disputa, limpeza, transformações, enriquecimento, aumento, análise, instruções SQL ou serviços de plataforma de dados.

Observabilidade: além da especificação de metadados, o design do produto de dados implica em informações para observabilidade.

  • O Quality Metrics descreve os requisitos e métricas de qualidade de dados, como precisão e integridade, bem como a conformidade com as políticas de governança de dados;
  • As métricas operacionais podem incluir intervalo de alteração, atualização, estatísticas de uso, disponibilidade, número de usuários, versão de dados, etc.;
  • Os SLOs para produtos de dados permitem a disciplina de construir confiabilidade em cada produto de dados. Especificamos aqui os limites para as métricas acionarem alarmes.

Observe que esta não é uma lista extensa de metadados e pontos de observabilidade. Certifique-se de definir todas as informações necessárias em sua organização para estabelecer a arquitetura de malha de dados.

Linguagem ubíqua: descreva uma linguagem comum que é compartilhada entre todos os envolvidos no projeto. Geralmente, é uma terminologia de domínio específica do contexto que é relevante para sistemas operacionais e produtos de dados.

Classificação: neste bloco, especificamos a natureza dos dados expostos, ou seja, classificamos nosso produto de dados como alinhado à origem, agregado ou alinhado ao consumidor.

A triggo.ai é pioneira e especialista em MDS – Modern Data Stack & DataOps no Brasil, desenvolvemos produtos e soluções que permitem nossos clientes atingir o melhor ROI para Data Analytics & AI. Fale com um de nossos especialistas!