Descubra como Data Mesh transforma usa domínios de dados focados no negócio para promover a descentralização analítica e autonomia dos times.

Uma das principais dúvidas que as empresas encontram no momento de iniciar a arquitetura de Data Mesh esta relacionada aos domínios de dados.

Veja também nosso artigo sobre Data Product (a base fundamental para a visão do Data Mesh).

Para democratizar os dados na organização, não devemos considerar apenas permitir que os usuários se conectem com o uso de DataViz, mas evoluir uma visão com a perspectiva de produtos de dados e domínios de dados.

Muitas organizações investiram em um data lake central e em uma equipe de dados com a expectativa de impulsionar seus negócios com base em dados. No entanto, após alguns ganhos iniciais rápidos, eles percebem que a equipe central de dados, muitas vezes, se torna um gargalo . 

Esse time não consegue lidar com todas as questões analíticas da gerência e dos proprietários do produto com rapidez suficiente e isso se torna um grande problema, afinal, tomar decisões oportunas baseadas em dados é crucial para se manter competitivo. Por exemplo: é uma boa ideia oferecer frete grátis durante a Black Week? Os clientes aceitam prazos de entrega mais longos, porém mais confiáveis? Como a mudança na página de um produto influencia a taxa de finalização de compra e devolução?

A equipe de dados deseja responder a todas essas perguntas rapidamente. Na prática, porém, eles enfrentam dificuldades porque precisam gastar muito tempo consertando pipelines de dados quebrados após alterações no banco de dados operacional. No pouco tempo que resta, a equipe de dados precisa descobrir e compreender os dados de domínio necessários . Para cada pergunta, eles precisam aprender conhecimento do domínio para fornecer insights significativos. Obter o conhecimento de domínio necessário é uma tarefa difícil.

O que é um domínio de dados?

Na arquitetura Data Mesh, um domínio de dados é um agrupamento lógico de dados, geralmente alinhados à origem ou ao consumidor, juntamente com todas as operações que seus objetos suportam.

O diagrama abaixo mostra um exemplo de como os domínios de dados podem funcionar na prática. Os próprios domínios podem ser categorizados livremente podendo ser alinhados à origem, alinhados ao cliente ou agregados de dados. Cada domínio em si está alinhado não com um conjunto de tecnologias, mas com a parte do negócio que suporta.

Arquitetura Data Mesh (fonte: https://www.datamesh-architecture.com/ )

Não importa como você estruture um domínio de dados, um princípio não muda: os domínios de dados devem pertencer à equipe mais próxima dos dados.

Atualmente, as organizações investem em design orientado por domínio, equipes de domínio autônomas (também conhecidas como equipes alinhadas ao fluxo ou equipes de produto) e em uma arquitetura descentralizada de microsserviços. 

Essas equipes possuem e conhecem seu domínio , incluindo as necessidades de informação do negócio. Elas projetam, constroem e executam seus aplicativos web e APIs por conta própria. Apesar de conhecerem o domínio e as necessidades de informação relevantes, as equipes do domínio têm de contatar a equipe central de dados para obter os insights necessários baseados em dados.

Com o eventual crescimento da empresa e do volume de dados, a situação das equipes de domínio e central piora. Uma saída é transferir a responsabilidade pelos dados da equipe central para as equipes de domínio. Esta é a ideia central por trás do conceito de malha de dados: descentralização orientada a domínio para dados analíticos . Uma arquitetura de malha de dados permite que as equipes de domínio realizem análises de dados entre domínios por conta própria e interconectem os dados, semelhante às APIs em uma arquitetura de microsserviços.

A importância dos domínios de dados para as empresas

Os domínios de dados exigem uma nova maneira de pensar sobre como a maioria das empresas estrutura e trata os seus dados.

Na ausência de domínios claramente demarcados, muitas organizações armazenam dados corporativos e estes são mantidos por uma única equipe central de dados. Essa equipe “é proprietária” dos dados do ponto de vista técnico. Quaisquer alterações em sua estrutura ou formato exigem que os proprietários de negócios registrem solicitações de alteração à equipe de engenharia.

Este modelo funciona para muitas empresas… até certo ponto. Com o tempo, essas estruturas de dados grandes e monolíticas tornam-se mais difíceis de navegar. Desenvolvem-se interdependências complexas entre equipes, exigindo que cada equipe entenda os esquemas de dados de outras equipes para realizar tarefas até mesmo mundanas.

A abordagem de equipe única também não se adapta bem. À medida que mais e mais solicitações chegam, a equipe de engenharia de dados se torna um gargalo e fica cada vez mais para trás. Além disso, a equipe de engenharia de dados não é a verdadeira proprietária dos dados – os produtores de dados são. Isso limita o que a engenharia de dados pode realmente fazer, aumentando ainda mais o atrito entre eles e os usuários finais dos dados.

Os domínios de dados resolvem isso dividindo os esquemas de dados em definições independentes pertencentes e mantidas pela equipe de negócios que possui os dados. A equipe é proprietária do armazenamento de dados e de todos os processos – geração, coleta, transformações de pipeline de dados, APIs, relatórios, etc. – que o acompanham. Sua saída é um produto de dados – um contêiner ou uma unidade de dados que resolve diretamente um problema de cliente ou negócio.

Esta é uma marca registrada dos domínios de dados: eles são descentralizados. As equipes de domínio trabalham de forma independente enquanto registram seus produtos de dados – suas fontes e destinos de dados, relatórios, etc. – com uma autoridade central, como um catálogo de dados .

Cada equipe de domínio é responsável por manter seus limites de dados e as operações que os suportam.

Domínios de dados versus propriedade centralizada

A mudança da propriedade do domínio para as equipes de negócios significa que os domínios de dados, teoricamente, promovem maior precisão nos dados. Isso ocorre porque essa equipe conhece seu negócio melhor do que outras pessoas na organização e, portanto, está na melhor posição para tomar decisões sobre como os dados são estruturados e gerenciados.

Os domínios de dados também promovem separações de interesses mais claras. Isso torna mais fácil integrar engenheiros de dados e software em um projeto. Os novos engenheiros não precisam entender todo o cenário de dados de uma empresa para começar. Eles só precisam entender os dados e as operações suportadas pela sua parte do negócio.

Essa separação de preocupações também simplifica a sincronização entre equipes. Com domínios de dados, uma equipe pode decidir quais dados serão expostos a outras equipes e quais dados permanecerão internos. Também pode definir operações de dados padrão por meio de APIs. Isso permite que as equipes interajam entre si usando contratos claramente definidos , em vez de compreender as complexidades (geralmente não documentadas) de seus esquemas de dados completos.

Finalmente, os domínios de dados podem permitir tempos de desenvolvimento mais rápidos e um tempo mais curto para lançamento no mercado de novos produtos de dados. As equipes de domínio são menores e mais focadas do que uma equipe geral de engenharia de dados. Isso permite que eles trabalhem mais como uma pequena equipe de engenharia de software orientada a produtos de dados. A equipe pode definir um escopo de trabalho rigoroso, enviar novas versões de seus produtos de forma iterativa e fazer alterações rápidas em resposta às mudanças nas condições.

Como funcionam os domínios de dados

Então, como funciona um domínio de dados na prática?

Cada organização terá sua própria implementação exclusiva. Mas aqui estão algumas diretrizes gerais sobre como migrar para uma abordagem orientada a domínios.

Inicializando e desenvolvendo um domínio de dados

Em uma arquitetura full data mesh, as equipes de domínio de dados geralmente são apoiadas por uma plataforma de dados centralizada. Essa plataforma padroniza o armazenamento, a transformação, as ferramentas e as práticas de dados.

Isso permite que as equipes de domínio de dados permaneçam focadas nas partes específicas do domínio de seus negócios, em vez de reinventar a roda em relação ao gerenciamento de dados. Também garante suporte técnico consistente e governança de dados entre equipes.

Em uma infraestrutura de autoatendimento, uma equipe de domínio de dados pode solicitar armazenamento de dados, capacidade de computação e outras ferramentas necessárias para projetar e implementar seu domínio e produtos de dados. Isso permite que as equipes de domínio operem com um grande grau de independência da equipe centralizada da plataforma de engenharia de dados, acelerando assim a entrega de produtos de dados.

Projetando um domínio de dados

Ao projetar um domínio de dados, as equipes precisam responder a algumas questões fundamentais:

  • Onde estamos obtendo nossos dados?
  • Qual é a aparência do nosso esquema de dados?
  • Que transformações devemos aplicar aos nossos dados de origem para trabalhar com eles de forma eficiente?
  • Como outras equipes acessam nossos dados?
  • Quem tem quais direitos sobre quais conjuntos de dados?
  • Quais dados devem ser públicos e quais dados devem ser internos à nossa equipe?
  • Quais dados precisam ser marcados como confidenciais – por exemplo, informações de identificação pessoal (PII)?

Antes de mudar para uma estrutura de domínio de dados, as empresas devem definir ferramentas e convenções para codificar estas decisões de design. Essas ferramentas devem ser parte padrão de uma infraestrutura de dados de autoatendimento.

A propriedade do domínio de dados é um princípio fundamental da arquitetura de Data Mesh e oferece vários benefícios para organizações maiores. Ao tratar cada domínio de dados como uma unidade independente, as empresas podem democratizar os dados, torná-los mais acessíveis e permitir envios mais rápidos, mais estabilidade e acoplamento menos frágil entre equipes.

No entanto, é importante notar que a propriedade do domínio de dados também introduz novos desafios, tais como a necessidade de modelos fortes de propriedade federada e de novas capacidades para as equipas da Plataforma. 

Ao considerar cuidadosamente estes desafios e implementar soluções adequadas, as organizações podem colher todos os benefícios da propriedade do domínio de dados e construir uma abordagem de gestão de dados mais escalável e ágil.

Se você quer entender melhor sobre como funciona a arquitetura Data Mesh e como essa abordagem pode ajudar a sua empresa, converse com um de nossos especialistas. Estamos prontos para ajudar você a trazer ainda mais resultados com dados.