Engenharia de dados

Porque uma análise sobre dados em que ninguém confia não é usada, e o investimento em ferramentas de visualização sobre uma base pouco fiável produz painéis bonitos que toda a gente contorna com uma folha de cálculo própria. É o padrão mais comum em organizações que investiram na ordem errada.

A confiança constrói-se com verificações automáticas que correm antes de os dados ficarem disponíveis: contagens dentro de intervalos esperados, chaves sem duplicados, campos obrigatórios preenchidos, e coerência entre tabelas relacionadas. Uma cadeia que falha em silêncio é pior do que uma que não corre.

E com uma regra que parece severa e não é: quando uma verificação falha, os dados não ficam disponíveis. Publicar dados que falharam a verificação com um aviso significa que alguém os vai usar sem ler o aviso, e a confiança perde-se na primeira decisão tomada sobre um número errado.

O mesmo que a qualquer outro tratamento, com uma agravante: cadeias de dados juntam fontes, e a junção pode tornar identificável o que isoladamente não era. Uma avaliação feita fonte a fonte não cobre o resultado, e é preciso avaliar o conjunto.

Na prática, isto significa decidir cedo que campos são necessários no destino analítico e excluir o resto na ingestão. Trazer tudo porque pode vir a ser útil é o padrão habitual e produz um repositório com dados pessoais que ninguém usa e que todos têm de proteger.

Prazos de conservação aplicam-se também aqui, e são a obrigação mais frequentemente esquecida em repositórios analíticos. Dados que deviam ter sido eliminados do sistema de origem sobrevivem no destino analítico durante anos, e essa é uma das descobertas mais comuns numa auditoria.

Na Polónia ou na rede global para a maior parte do trabalho de construção, porque é trabalho assíncrono com sobreposição suficiente numa reunião diária, e a diferença de custo é substancial sem penalizar o resultado.

Em Portugal quando o trabalho toca dados pessoais de produção e o cliente prefere evitar a questão de transferência internacional, o que é uma preferência legítima e frequentemente a mais barata quando se conta o custo do enquadramento jurídico.

Nenhum dos modelos dispensa um interlocutor do vosso lado que conheça o negócio. Engenharia de dados sem acesso a quem sabe o que os números significam produz cadeias tecnicamente corretas sobre modelos que não descrevem a realidade, e isso não se resolve com mais engenharia.

Descrevendo o que cada campo significa em linguagem de negócio e não repetindo o nome técnico por outras palavras. Data de criação documentada como a data em que o registo foi criado não documenta nada; documentada como o momento em que o cliente submeteu o pedido, que pode ser anterior à criação do registo, documenta.

Incluindo o que foi deliberadamente deixado de fora e porquê. Essa segunda parte falta em quase toda a documentação de dados e é exactamente a que responde à pergunta que alguém faz seis meses depois, quando procura um campo e não percebe se não existe ou se foi excluído por uma razão.

E mantendo-a junto do código que constrói o modelo, não num documento separado. Documentação que vive noutro sítio diverge do que existe em três meses, e uma documentação errada é pior do que nenhuma porque alguém confia nela.