Em muitas empresas as pessoas estão familiarizadas com o conceito de Acordos de Nível de Serviço (SLAs), às vezes chamados de Contratos de Serviço. Esses acordos escritos descrevem os detalhes do que um cliente espera de um provedor de serviços, bem como o que pode acontecer se o provedor de serviços não atender a essas expectativas.
Os contratos de dados, geralmente empregados em uma arquitetura federada, servem a um propósito semelhante. Exceto, em vez de se referir a serviços, um contrato de dados é um acordo entre um provedor de serviços e consumidores de dados. Refere-se ao gerenciamento e uso pretendido de dados entre diferentes organizações ou, às vezes, dentro de uma única empresa.
O objetivo? Garantir dados confiáveis e de alta qualidade para todas as partes envolvidas.
Mas o que é um contrato de dados e como ele se parece?
Apesar do nome intimidador, os contratos de dados não são tão complicados quanto parecem à primeira vista. E eles podem ser incrivelmente úteis para melhorar a responsabilidade em todos os ativos de dados. Abaixo, além de explorar o que é um contrato de dados, veremos por que eles são necessários, quando usá-los e como implementá-los.
Por que os contratos de dados são necessários?
Em primeiro lugar, vamos pensar por que precisamos de contratos de dados.
As equipes de dados dependem de sistemas e serviços, muitas vezes internos, que geram dados que são levados ao Data Warehouse e se tornam parte de diferentes processos. No entanto, os engenheiros de software responsáveis por esses sistemas não têm a tarefa de manter e muitas vezes desconhecem essas dependências de dados. Portanto, quando eles fazem uma atualização em seu serviço que resulta em uma alteração de esquema, esses sistemas de dados fortemente acoplados travam.
Outro caso de uso igualmente importante são os problemas de qualidade de dados. Eles surgem quando os dados trazidos para o Data Warehouse não estão em um formato utilizável pelos consumidores de dados. Um contrato de dados que impõe determinados formatos, restrições e significados semânticos pode mitigar tais instâncias.
Sabemos que as organizações estão lidando com mais dados do que nunca e as responsabilidades por esses dados são frequentemente distribuídas entre os domínios; esse é um dos princípios-chave de uma abordagem de Data Mesh.
O nome pode ser um pouco enganador neste caso – os contratos de dados não são documentos legais detalhados, mas um processo para ajudar os produtores e consumidores de dados a estarem na mesma página.
Quanto mais amplamente distribuídos os dados se tornam, mais importante é ter uma solução que garanta a transparência e crie confiança entre as equipes que usam dados que não são seus.
O que há em um contrato de dados?
Para quem nunca viu, a ideia de criar contratos de dados pode ser assustadora. Mas, depois de definir um formato para um contrato de dados, garantindo a máxima legibilidade, criar um pode ser tão simples quanto algumas linhas de texto.
Os contratos de dados podem abranger coisas como:
- Quais dados estão sendo extraídos
- Tipo e frequência de ingestão
- Detalhes de propriedade/ingestão de dados, seja individual ou em equipe
- Níveis de acesso a dados necessários
- Informações relacionadas à segurança e governança (por exemplo, anonimização)
- Como a ingestão de dados afeta qualquer sistema(s)
Como os contratos de dados podem diferir substancialmente com base no tipo de dados a que se referem, bem como no tipo de organização em que estão sendo usados, ainda não vimos um grau significativo de padronização quando se trata de formatos e conteúdo de contrato de dados. No entanto, um conjunto de melhores práticas ainda pode surgir no futuro, como vimos com a Especificação OpenAPI.
Quem é responsável pelos contratos de dados?
Embora não sejam necessariamente os implementadores, a decisão de executar contratos de dados cabe aos líderes de dados. Vale ressaltar, no entanto, que eles exigem entrada e adesão de todas as partes interessadas envolvidas no consumo de dados.
Os consumidores de dados tendem a ser os participantes mais motivados, pois os contratos de dados claramente facilitam suas vidas. Os produtores de dados, como engenheiros de software, podem precisar de algum convencimento para mostrar a eles como os contratos de dados podem beneficiar a organização e melhorar a qualidade dos dados sem muito esforço adicional.
Para esse fim, vale a pena apontar que os contratos de dados geralmente são perenes e não precisam de muita manutenção contínua. Além de ajustes e atualizações ocasionais de controle de versão para detalhes de contato, etc., eles não devem criar um fardo significativo quando estiverem em funcionamento.
Quando os contratos de dados devem ser implementados?
Você pode supor que a resposta para a questão de quando implementar contratos de dados seria “quanto mais cedo melhor”. Mas digamos que você ainda esteja trabalhando para obter adesão organizacional para uma abordagem de Data Mesh. Adicionar contratos de dados à mistura pode complicar as coisas e traz o risco de as partes interessadas ficarem sobrecarregadas.
Pode valer a pena garantir que você tenha tudo encaminhado – pipelines de dados estáveis e confiáveis que estão funcionando sem problemas – antes de mergulhar nos contratos de dados. Por outro lado, “se sua equipe está buscando qualquer tipo de iniciativa de Data Mesh, é o momento ideal para garantir que os contratos de dados façam parte dela”.
Claro, perguntas como “quando os contratos de dados devem ser implementados?” e “quanto tempo leva para implementar contratos de dados?” tendem a ter respostas semelhantes: em ambos os casos, “depende”.
Em outras palavras, este não é (nem precisa ser) um processo da noite para o dia. E, quando você começar, você pode manter as coisas simples. Assim que estiver armado com o conhecimento que você coletou dos membros da equipe e outras partes interessadas, você pode começar a implementar contratos de dados.
O que vem a seguir para os contratos de dados?
Historicamente, o gerenciamento de dados dentro de uma organização sempre foi responsabilidade de uma equipe dedicada. Ou, em alguns casos, a missão de apenas um Cientista de Dados corajoso (e possivelmente sobrecarregado). Em tais situações, os contratos de dados não eram realmente necessários para manter a ordem.
À medida que as organizações avançam em direção a uma abordagem de Data Mesh – arquitetura orientada por domínio, plataformas de dados de autoatendimento e governança federada – esse não é mais o caso. Quando os dados são vistos como um produto, com diferentes equipes e subequipes contribuindo para sua manutenção, mecanismos para manter tudo acoplado e funcionando sem problemas são muito mais importantes.
O contrato de dados ainda é uma ideia relativamente nova. Eles são uma tentativa inicial de melhorar a manutenção dos pipelines de dados e os problemas decorrentes da quebra de um monólito, portanto, provavelmente veremos mais iterações e outras abordagens surgindo no futuro.
No momento, no entanto, eles podem ser apenas a melhor solução à nossa disposição para evitar problemas de qualidade de dados decorrentes de alterações inesperadas no esquema.
David Matos
Referências: