Numa casa cheia, se cada garçom anota o pedido do jeito que quiser, numa agenda diferente, a cozinha não sabe o que preparar e o caixa não sabe o que cobrar. Em algum momento, dois garçoms vão dizer coisas diferentes sobre a mesma mesa. Com dado é igual: quando ninguém é dono de verdade de uma informação, cada área usa a sua versão, e a empresa discute relatório em vez de discutir decisão.
Esse é o problema que a governança e a arquitetura de dados existem para resolver. E, na minha opinião, é um dos papéis mais mal compreendidos da TI hoje: tem gente que acha que é só comprar um catálogo de dados; tem gente que acha que é só escrever política. Não é nem um, nem outro.
Governança de dados x gestão de dados
A mesma lógica que vale para governança de TI vale aqui. Governança decide o que a empresa espera dos dados: quem é dono, quais regras valem, o que é prioridade. Gestão e arquitetura fazem isso acontecer: catálogo, integração, qualidade, infraestrutura. Confundir as duas é comum, e o efeito colateral é sempre o mesmo: a TI vira responsável por decisões que são do negócio.
O modelo federado: quem é dono do quê
O pulo do gato da governança de dados moderna é o modelo federado, com três papéis:
- Data Owner: é do negócio. Decide o que aquele dado significa e quais regras ele segue. É o “dono do cardápio”.
- Data Steward: aplica essas regras no dia a dia, cuida da qualidade e resolve dúvida de quem usa o dado. É quem está na linha de frente.
- Data Custodian: normalmente é a TI, guarda e protege o dado tecnicamente, mas não decide o que ele significa.
Sem esses três papéis combinados, decisão vira empurra-empurra. “Isso é da TI” e “isso é do negócio” são as duas frases que mais atrasam um programa de dados.
Um “ITIL” para dados: o DAMA-DMBOK
Se você já conhece a ITIL (vou escrever sobre ela aqui no blog), o DAMA-DMBOK cumpre um papel parecido, só que para dados: é um corpo de conhecimento com boas práticas de gestão de dados, reconhecido no mercado, que organiza disciplinas como governança, qualidade, metadados, modelagem, segurança e arquitetura. Não é lei, é referência. Serve de mapa, não de maquete pronta.
Arquitetura que conecta, não que empilha
Toda empresa grande tem sistema transacional, plataforma de integração, lakehouse, ferramenta de analytics, BI e, cada vez mais, IA consumindo tudo isso. O erro clássico é tratar cada peça nova como um projeto isolado, e no fim você tem cinco “verdades” diferentes sobre o mesmo cliente.
Arquitetura de dados boa faz o oposto: define princípios e padrões que conectam essas peças, preservando a liberdade de trocar fornecedor. Hoje é comum ver essa conversa girando em torno de ferramentas como Databricks (para lakehouse, processamento e governança via catálogos como o Unity Catalog) e Informatica (para integração, qualidade, catálogo e MDM), mas o princípio importa mais que a marca: a arquitetura precisa sobreviver à troca de fornecedor.
Metadados, catálogo e linhagem: o “RG” dos dados
Sem catálogo, ninguém sabe que um dado existe. Sem glossário de negócio, duas áreas usam o mesmo nome para coisas diferentes. Sem linhagem, ninguém sabe de onde veio um número nem o que vai quebrar se ele mudar. E sem observabilidade, um problema de qualidade só aparece quando o relatório já saiu errado para a diretoria.
Qualidade não é tudo igual: Critical Data Elements
Nem todo campo merece o mesmo cuidado. A prática mais eficiente é identificar os Critical Data Elements: os poucos dados que, se errados, custam caro (CPF de cliente, saldo, data de vencimento). Em cima deles, você coloca regra, controle, meta de qualidade e, principalmente, investigação de causa raiz, não só correção pontual. É o mesmo princípio do gerenciamento de problemas na ITIL: tratar a causa, não só o sintoma.
Dado como produto: domínios e contratos
Uma tendência que vale conhecer é tratar dado como produto: cada domínio de negócio (vendas, cobrança, operação) publica seus dados com um “contrato” claro, dizendo formato, qualidade e regras de uso, em vez de cada consumidor quebrar a cabeça para entender uma base. É a lógica do data mesh: descentralizar a responsabilidade pelo dado, sem perder padrão.
Dado mestre e golden record
Quando o mesmo cliente existe de três formas diferentes em três sistemas, alguém precisa decidir qual é a versão verdadeira. Isso é MDM (gestão de dados mestres): o processo de harmonizar essas versões num golden record, a fonte oficial que todo o resto deveria consultar.
Governança não é só tecnologia: é gente e decisão
A parte técnica é necessária, mas não é suficiente. Governança de dados boa também significa: conversar com Segurança, Privacidade, Jurídico e Compliance para aplicar a LGPD de forma prática; entrar nos grandes programas corporativos desde o início, para não criar silo novo; e, cada vez mais, medir o valor econômico dos dados (o chamado FinOps de dados), para a conversa com a diretoria deixar de ser sobre tecnologia e passar a ser sobre resultado.
Para levar pra casa
Governar dados tem o mesmo espírito de governar TI: decidir o “o quê” separado do “como”, dar dono a cada coisa e medir se o combinado está sendo cumprido. A diferença é que, aqui, o ativo que você está organizando é a verdade da empresa sobre ela mesma. Quem resolve isso bem não entrega só uma plataforma; entrega confiança no número que vai para a reunião de diretoria.
