A Evolução da Governança de Dados Capítulo 4 — A Governança não deveria apenas validar Produtos de Dados, ela deveria ajudar a construí-los

Olá, governantes!®
Existe uma característica que se repete em praticamente todas as organizações que decidem estruturar um programa de Governança de Dados. Depois de definir papéis, estabelecer domínios, implantar um catálogo corporativo e organizar seus processos, cria-se a expectativa de que a Governança finalmente passará a acompanhar o desenvolvimento dos Produtos de Dados.
À primeira vista, isso parece representar uma evolução natural, afinal, aproximar a Governança da operação sempre foi um objetivo desejado, o problema é que, em muitas organizações, essa aproximação continua acontecendo tarde demais.
Ainda é comum que a Governança seja acionada quando um Produto de Dados já foi desenvolvido, quando suas regras de negócio foram implementadas, quando consumidores já dependem daquele ativo para tomar decisões e quando alterações estruturais passam a representar custos, atrasos ou retrabalho. Nesse momento, a Governança costuma assumir atividades como revisar metadados, validar critérios de qualidade, classificar informações sensíveis, definir responsabilidades ou registrar ativos no catálogo corporativo e todas essas práticas são importantes, a questão é que elas acontecem quando as decisões mais relevantes já foram tomadas.
Durante muito tempo, esse modelo pareceu suficiente, porque os projetos possuíam ciclos mais longos, os ambientes eram menos distribuídos, existia espaço para etapas formais de validação antes que um ativo fosse disponibilizado para o negócio, ou essa etapa nem era relevantes.
Hoje, entretanto, a realidade é diferente, os Produtos de Dados evoluem continuamente, pipelines são modificados com frequência, novas integrações surgem em ritmo acelerado e decisões críticas são tomadas diariamente por equipes multidisciplinares, esperar que a Governança participe apenas ao final desse processo significa aceitar que sua principal contribuição ocorrerá quando boa parte das escolhas já não puder mais ser influenciada.
Foi justamente observando essa dinâmica que há algum tempo comecei a questionar uma ideia que, talvez o papel da Governança nunca tenha sido validar Produtos de Dados, já que sua maior contribuição esteja em criar as condições para que esses produtos já nasçam alinhados aos princípios de qualidade, responsabilidade, segurança, compartilhamento e geração de valor que a organização considera essenciais.
Essa mudança de perspectiva parece sutil, mas altera profundamente a forma como enxergamos a atuação da Governança. No modelo tradicional, ela representa uma etapa do processo, responsável por verificar se um Produto de Dados atende aos padrões previamente estabelecidos, já na perspectiva que proponho, a Governança deixa de ser uma fase e passa a representar uma capacidade incorporada ao próprio desenvolvimento.
Questões relacionadas à qualidade dos dados, às regras de negócio, às responsabilidades, aos metadados, à classificação das informações e aos mecanismos de evolução deixam de ser requisitos avaliados ao final do projeto e passam a orientar sua construção desde o primeiro momento.
É justamente para representar essa forma de pensar que adoto, neste artigo, a expressão Governança by Design. Não a utilizo como um novo framework nem como uma proposta para substituir os modelos consolidados de Governança de Dados, para mim, ela representa um princípio, práticas de Governança produzem mais valor quando são incorporadas desde a concepção dos Produtos de Dados e acompanham toda a sua evolução, em vez de serem adicionadas apenas como uma etapa de validação ao final do desenvolvimento. Mais do que um nome, trata-se de uma mudança de postura e a Governança deixa de observar o produto depois de pronto e passa a participar da forma como ele é concebido.
Essa mudança também desfaz um equívoco recorrente, quando se fala em incorporar a Governança ao desenvolvimento, é comum surgir a preocupação de que isso represente mais reuniões, novos formulários, aprovações adicionais ou aumento da burocracia. Na minha visão, acontece exatamente o contrário, quanto mais cedo os princípios de Governança fizerem parte da construção de um Produto de Dados, menor será a necessidade de controles corretivos, revisões posteriores e retrabalho. O objetivo não é aumentar a quantidade de processos, mas reduzir a distância entre quem constrói os dados e quem define os princípios que garantem sua confiabilidade.
Isso muda, inclusive, a natureza das perguntas que fazemos durante um projeto, em vez de questionar, ao final, se um Produto de Dados possui um responsável definido, critérios mínimos de qualidade ou metadados suficientes, essas discussões passam a acontecer no momento em que o produto está sendo concebido. Quem responderá por sua evolução?
Quais regras de negócio precisam ser preservadas? Quais atributos são críticos para o negócio? Como sua qualidade será monitorada? Que informações precisam estar disponíveis para que outros times reutilizem esse ativo com segurança? Essas perguntas não pertencem ao encerramento do projeto, elas pertencem ao seu início.
Talvez seja justamente por isso que tantas iniciativas de Governança sejam percebidas como burocráticas, não porque seus princípios sejam excessivos, mas porque frequentemente entram na conversa quando as equipes já seguiram outro caminho.
Solicitar mudanças estruturais em um Produto de Dados que já está em produção dificilmente será interpretado como apoio. Para quem está comprometido com entregas ao negócio, isso quase sempre será percebido como retrabalho. Quando a mesma discussão acontece durante a concepção do produto, entretanto, ela deixa de ser um obstáculo e passa a fazer parte da própria engenharia da solução.
Essa é, talvez, a principal mudança de perspectiva que proponho nesta série. A Governança não deve começar quando um ativo precisa ser catalogado, auditado ou revisado. Ela deve começar quando alguém decide construir um Produto de Dados, é nesse momento que as decisões capazes de sustentar sua qualidade, sua evolução e sua confiabilidade começam a ser tomadas.
Há uma diferença importante entre construir um Produto de Dados funcional e construir um Produto de Dados sustentável, o primeiro resolve uma necessidade imediata, o segundo continua gerando valor quando novos consumidores surgem, quando regras de negócio evoluem, quando tecnologias mudam e quando aquele ativo passa a sustentar decisões cada vez mais relevantes para a organização. É essa sustentabilidade que a Governança oferece quando deixa de atuar como um mecanismo de validação e passa a integrar o próprio processo de construção.
Ao observar organizações que conseguiram escalar seus ecossistemas de dados, percebo que elas compartilham uma característica comum. A Governança raramente aparece como uma área que interrompe projetos para aprovar entregas, ela está presente na forma como os times trabalham, nos padrões de engenharia, nas plataformas, nos componentes reutilizáveis, nos mecanismos automatizados de qualidade e na maneira como responsabilidades são distribuídas, em outras palavras, ela deixa de depender da intervenção constante das pessoas porque passa a fazer parte do próprio sistema de trabalho.
Talvez seja esse o verdadeiro significado da Governança by Design, não um novo modelo de Governança, mas uma forma diferente de compreender quando ela realmente começa. Produtos de Dados não deveriam ser entregues para depois serem governados, deveriam ser concebidos para já nascerem governados.
Essa reflexão nos conduz naturalmente ao próximo passo da nossa jornada. Incorporar princípios de Governança desde a concepção dos Produtos de Dados transforma a forma como trabalhamos, mas ainda não resolve um desafio igualmente importante: como sustentar essa abordagem quando a organização passa a desenvolver dezenas ou centenas de Produtos de Dados simultaneamente?
Em algum momento, depender apenas das pessoas deixa de ser suficiente. Escalar essa visão exigirá que plataformas, processos e automações passem a incorporar esses mesmos princípios. É essa transição da prática para a capacidade organizacional que discutiremos no próximo capítulo.

Comentários