Governança de Dados para Instituição Financeira

Uma instituição do setor financeiro operava com dados distribuídos entre sistemas transacionais e ambientes analíticos, sem uma fronteira clara entre os dois mundos.

Eram mais de mil tabelas sustentando decisões de negócio e obrigações regulatórias, sem responsáveis declarados por domínio e sem um lugar único onde descobrir o que existia, de onde vinha e quem podia acessar.

O projeto estruturou uma prática de governança de dados que começou pela estratégia e terminou no dia a dia dos times, tratando governança como responsabilidade distribuída e não como um controle central.

O crescimento dos ambientes de dados havia acompanhado as necessidades de cada área, sem um modelo comum por trás.

Com isso, perguntas fundamentais ficavam sem resposta confiável:

• Quem é o responsável por este dado?
• Este número veio do sistema transacional ou de uma transformação analítica?
• Quem pode acessar o quê, e sob qual justificativa?
• Onde este dado é produzido e quais áreas dependem dele?
• Esta métrica significa o mesmo aqui e no sistema de origem?

A ausência de fronteira entre o analítico e o transacional era o problema de fundo: consultas analíticas alcançavam dados operacionais, e definições divergiam entre relatórios sem que ninguém pudesse arbitrar qual estava correta.

O custo aparecia na entrada. Para uma pessoa começar a trabalhar com dados eram necessários dois dias de pedidos de acesso, explicações informais e descoberta por conversa.

O trabalho foi dividido em quatro frentes, executadas em paralelo e com dependências explícitas entre si:

• Estratégia: definir o que governança significava para a instituição, quais domínios existiam e quais obrigações cada um carregava.
• Stewardship: nomear responsáveis por domínio e transformar essa responsabilidade em rotina, não em cargo simbólico.
• Catálogo e infraestrutura: dar um lugar único para descobrir, documentar e classificar os dados, sustentado por infraestrutura própria.
• Analytics engineering: estabelecer o padrão de transformação analítica e o modelo de distribuição dos dados entre os domínios.

A primeira decisão estrutural foi separar de forma explícita o mundo transacional do analítico.

Os sistemas transacionais passaram a ser a fronteira de origem, governada e com controle de acesso próprio. O ambiente analítico passou a consumir esses dados por contratos definidos, em vez de alcançá-los diretamente, com o Snowflake como plataforma analítica e o Trino como query engine federada sobre as fontes.

O domínio virou a unidade de organização. Foram desenhados oito domínios de dados, cada um com responsável, escopo e obrigações próprias.

Sobre essa base foi montado um modelo de data mesh: cada domínio publica seus dados como produto, com responsável declarado, documentação no OpenMetadata e regras de acesso associadas. Os consumidores encontram no catálogo o que existe e sob quais condições podem usar.

A implementação começou pelo inventário: mais de mil tabelas mapeadas e classificadas por domínio e sensibilidade.

Com o mapa em mãos, os oito domínios foram redesenhados e os stewards designados, passando a participar das decisões sobre seus domínios — quem acessa, o que significa cada campo, o que pode ser publicado.

O OpenMetadata entrou em operação em seguida, primeiro como registro do que já existia e depois como porta de entrada para novos dados. O Trino deu aos consumidores uma interface de consulta única sobre fontes que antes exigiam acessos separados.

Na frente analítica, o dbt foi adotado como padrão de transformação, dando aos analytics engineers um modelo versionado, testável e documentado. Os produtos de dados resultantes passaram a ser distribuídos entre os domínios segundo o modelo de mesh.

O trabalho de cultura acompanhou cada etapa: governança só se sustenta quando as rotinas dos times a incorporam, e não quando depende de uma equipe central para funcionar.

• Snowflake
• Trino
• dbt
• OpenMetadata
• Classificação por domínio e sensibilidade
• Controle de acesso por domínio
• Data mesh como modelo de distribuição

A mudança mais relevante não foi técnica, foi de responsabilidade.

Dados deixaram de ser um ativo difuso, pertencente a todos e a ninguém, e passaram a ter donos declarados que respondem pela qualidade, pelo significado e pelo acesso ao que publicam.

Os times de negócio ganharam um lugar para descobrir o que existe antes de pedir, e os times técnicos ganharam critérios para decidir o que expor e para quem. O analítico deixou de competir com o transacional.

O efeito mais visível foi na entrada: o que antes custava dois dias de articulação informal passou a levar uma hora, porque a descoberta, a documentação e a regra de acesso passaram a estar no mesmo lugar. Isso tornou viável habilitar mais de cem pessoas a consumir dados de forma autônoma.

A prática escalou para além do escopo inicial porque passou a ser executada pelos próprios domínios, em vez de depender de um time central de governança.

2 dias → 1 horaOnboarding de uma pessoa ao ambiente de dados

• 8 domínios de dados redesenhados, cada um com responsável declarado, escopo definido e obrigações próprias.

• Mais de 1.000 tabelas mapeadas e classificadas por domínio e sensibilidade.

• 100% dos dados transacionais governados, com controle de acesso associado ao domínio e à sensibilidade do dado, no lugar de permissões herdadas.

• Mais de 100 pessoas habilitadas a descobrir e consumir dados de forma autônoma pelo catálogo.

• Onboarding de 2 dias para 1 hora, com descoberta, documentação e regra de acesso no mesmo lugar.

• Fronteira definida entre analítico e transacional, encerrando o acesso direto de cargas analíticas aos sistemas de origem.

• dbt adotado como padrão de analytics engineering e distribuição em mesh, com cada domínio publicando seus dados como produto para os demais.