Governança de dados: Governança e Arquitetura de Dados

Introdução a Governança e Arquitetura de Dados - Apresentação

Apresentando a experiência e formação

Olá. Eu sou Alan, gerente de governança de dados e inteligência artificial em uma seguradora no Brasil.

Trabalho há mais de cinco anos como docente na FIAP, nos cursos de MBA e na POSTEC. Também gravo conteúdos na Alura, e provavelmente você já me viu em alguns cursos sobre governança de dados e governança de inteligência artificial.

Eu sou licenciado em Ciências Econômicas, tenho um MBA em Dados e Analítica e, agora, estou cursando um mestrado também em Computação, em Governança de Dados.

Fornecendo audiodescrição e introduzindo o tema

Audiodescrição: Por questões de acessibilidade, eu sou um homem branco, de pele clara, com cabelo e barba escuros, muito curtos. Ao fundo está o estúdio da FIAP, um estúdio com fundo azul, um azul neon bonito. Estou vestindo uma camiseta preta.

Hoje nós vamos conversar um pouco sobre governança de dados.

Obrigado.

Introdução a Governança e Arquitetura de Dados - O que é Governança de Dados e onde entra a Arquitetura

Apresentando o encontro e contextualizando o tema

Olá, vamos ao nosso primeiro encontro. Eu prometo que será uma conversa tranquila. Nós vamos falar sobre governança de dados de forma lógica, para que você entenda a importância dessa área e dessa disciplina dentro de uma empresa.

Para iniciar, surge uma pergunta: por que precisamos falar de governança de dados e arquitetura de dados juntas? Elas não são áreas distintas dentro da empresa? Muitas pessoas estudam governança de dados separada da arquitetura, e isso é um problema, porque, na prática, elas devem atuar em conjunto para que as decisões e os processos dentro da empresa funcionem. As áreas de governança de dados e de arquitetura de dados precisam dialogar e planejar. Uma regra definida pela governança de dados deve ser validada, compreendida e aplicada pela arquitetura. Caso contrário, teremos regras definidas que ninguém aplica. Não adianta definir regras se a forma como os dados são armazenados, integrados e acessados não as suporta.

Se definimos uma regra na área de governança de dados, a arquitetura precisa avaliar se, do jeito que está desenhada, essa regra é factível, possível e se não vai gerar problemas para o negócio.

Definindo governança de dados

E, afinal, o que é governança de dados? Se você chegou aqui por acaso — o que imaginamos que não seja o caso —, nós estamos compondo este treinamento dentro de uma trilha de aprendizagem de governança de dados. De forma breve, governança de dados é a área que define responsabilidades, garante a qualidade, controla o uso e os riscos dos dados, tudo isso para contribuir para que os dados gerem valor para o negócio. Queremos que os dados sejam reutilizados, que os indicadores sejam consistentes e que realmente sustentem decisões acertadas, para que a pessoa gestora deixe de decidir por impulso ou intuição e passe a utilizar dados de forma mais precisa.

Governança de dados não é uma ferramenta nem um documento. Na prática, é quem define as regras sobre os dados. Se na sua empresa há uma área de governança de dados, essa área está planejando como os dados serão acessados em todas as etapas: desde o processo de ingestão de informações dentro do nosso data lake até a utilização pela pessoa usuária. Tudo isso com o objetivo de garantir qualidade, segurança e consistência, como comentamos no início, para gerar valor ao negócio.

Apontando erros comuns na governança sem arquitetura

Um erro comum é tratar a governança de dados como um conjunto de regras desconectadas da prática. É comum vê-la como políticas sem suporte técnico, papéis sem visibilidade e regras difíceis de aplicar. Outro equívoco é achar que governança de dados se resolve apenas com políticas e comitês. Entra uma área, publica uma série de políticas, começa a promover comitês semanais ou mensais e considera que isso é governança de dados. Esse é um erro recorrente. Quando a arquitetura não trabalha junto com a área de governança de dados, esse cenário tende a acontecer.

A área de governança de dados, sem esse pilar de suporte, passa a ter pouca influência sobre as demais áreas e contribui menos para que os dados fluam corretamente dentro da empresa. As regras até existem, mas ninguém consegue aplicá-las no dia a dia — algo que observamos com frequência. A governança de dados, separada das áreas operacionais responsáveis por disponibilizar o dado para o negócio, produz esse tipo de resultado.

Esclarecendo o papel da arquitetura de dados

E onde se encaixa a arquitetura de dados nesse contexto? A arquitetura de dados é quem define e aplica onde os dados ficam, como se integram, quem acessa, quais controles são ou não possíveis de realizar e por quê. Portanto, arquitetura de dados também não é apenas tecnologia; é um conjunto de decisões que define como os dados fluem dentro da organização. Essas decisões podem facilitar ou inviabilizar a governança. Por isso, a governança de dados deve atuar em conjunto com a arquitetura.

Eu fui mentor em um MBA na FIAP em arquitetura de dados, e lá falávamos muito sobre essa importância da interação entre as áreas.

Orientando a arquitetura ao negócio

Em nossa experiência profissional, víamos a área de arquitetura muito isolada, em um canto escuro dentro da área de tecnologia. Consideramos isso prejudicial, porque ela precisa estar junto ao negócio, entendendo de verdade para que aquele conjunto de dados, quando estiver disponível, vai atender todo o trabalho que vocês estão realizando. No fim, trata-se de atender a um dashboard (painel) a partir do qual a liderança, na outra ponta, decide fechar ou não uma franquia, uma filial, ou expandir ou não um mercado.

A área de arquitetura de dados deve ter orientação ao negócio. E a área de governança de dados, junto com a arquitetura, tende a atender ao negócio; ambas, em conjunto, têm mais probabilidade de trabalhar de uma maneira que beneficie a empresa como um todo.

Relacionando decisões de arquitetura e impactos na governança

Em síntese, a arquitetura não é apenas tecnologia: envolve decisões técnicas, impactos organizacionais e efeitos diretos na governança. Dependendo de como a arquitetura for desenhada, a governança pode se tornar difícil, complicada de aplicar. As regras que propomos com base em práticas de mercado podem esbarrar na própria arquitetura, que cria impedimentos e afirma que não vai funcionar sem mudar o desenho. Por isso, as áreas precisam dialogar.

Quando decidimos, por exemplo, centralizar ou descentralizar os dados, ou quando definimos camadas ou domínios, isso impacta diretamente responsabilidades, controles e riscos. Portanto, a arquitetura não é somente uma decisão técnica; também é uma decisão organizacional. As pessoas responsáveis pela governança de dados precisam apoiar a arquitetura para que as decisões adotadas estejam alinhadas à estratégia da companhia.

Alinhando governança e arquitetura para resultados práticos

Governança e arquitetura formam uma prática viável e, mais do que viável, necessária. Se você quer ter uma área de governança de dados robusta na empresa, é preciso manter uma relação próxima com as áreas de arquitetura para entender o que estão fazendo e atuar em conjunto. A governança define o que precisamos controlar, e a arquitetura define como isso será possível: quais regras e quais aplicações precisam ser concebidas, desenvolvidas e implementadas para que as regras impostas pela governança de dados sejam aplicáveis e não fiquem apenas em um nível alto para cumprir um requisito de auditoria e afirmar que existe uma área de governança. Elas devem ser aplicáveis e funcionar. Quando governança e arquitetura de dados estão alinhadas, as decisões deixam de ser teóricas, passam a funcionar na prática e começam a produzir efeitos. Essa é a verdadeira vantagem de uma área de governança de dados dentro da empresa.

Uma linguagem comum entre negócio, dados e tecnologia é o cerne. É o que uma empresa busca para ser realmente orientada por dados. Trata-se de uma relação que deve acontecer: arquitetura com negócio, arquitetura com governança e governança com negócio. Embora essas áreas, na empresa, sejam bastante específicas e cada uma tenha seu objetivo, precisam se relacionar para que as decisões ocorram de forma conjunta, produtiva e benéfica para a organização. Enquanto o negócio olha para valor e risco, a área de dados observa significado e qualidade, e a tecnologia foca a implementação — como fazer tudo isso funcionar e fluir dentro da empresa.

Construindo uma linguagem comum no curso

Este curso vai trabalhar exatamente essa ponte: criar uma linguagem comum entre negócio, dados e tecnologia. Em alguns momentos, vamos nos concentrar mais em governança; em outros, falaremos sobre tecnologia e arquitetura. Também abordaremos a importância do negócio. Será uma conversa tranquila e leve, para que você entenda, assimile e correlacione com seu dia a dia na empresa. Se você já trabalha em uma empresa estruturada, com governança e arquitetura, poderá refletir, enquanto falamos, sobre muitas situações do cotidiano. E, se estiver em um nível de influência razoável, poderá, já no dia seguinte, propor uma sugestão e iniciar um processo diferente.

Nos vemos nos próximos vídeos. [♪]

Introdução a Governança e Arquitetura de Dados - Arquitetura de Dados: decisões que moldam o uso do dado

Contextualizando a arquitetura de dados

Olá, vamos para outra etapa, outro passo em nossa jornada. Para quem, assim como nós, teve uma experiência profissional em que a área de arquitetura era pouco acessível — como no exemplo do vídeo anterior, aquele canto escuro em tecnologia, onde nem sequer conhecíamos os nomes das pessoas —, hoje vamos tratar de forma direta e específica da arquitetura de dados.

Arquitetura é muito mais do que tecnologia. Quando falamos de uma área de arquitetura de dados, muitas pessoas pensam imediatamente em ferramentas e plataformas, mas não se trata apenas disso. Arquitetura é, antes de tudo, um conjunto de decisões que influenciam diretamente como os dados são organizados, integrados e utilizados na organização.

Relacionando decisões de arquitetura aos desafios de acesso

Se trabalhamos em uma área onde os dados são de difícil acesso, não atendem exatamente ao que o negócio precisa ou há reclamações constantes sobre a qualidade e a disponibilidade desses dados, muitas decisões passaram pela área de arquitetura e, em alguns casos, o distanciamento em relação ao negócio está causando esse tipo de situação dentro da empresa.

Como comentamos, trata-se de um conjunto de decisões que abrangem onde os dados são armazenados, como se conectam, como circulam e quem acessa. Cada decisão responde a perguntas simples, porém fundamentais: onde está, onde é acessado e por onde circula?

Comparando a arquitetura centralizada e seus impactos

Quanto às arquiteturas, existem algumas linhas de decisão que as áreas de arquitetura das empresas adotam, dependendo do nível de maturidade da organização. A primeira delas é a arquitetura centralizada, que concentra todos os dados em um repositório único, em um data lake (lago de dados) único e centralizado. Todas as pessoas passam a acessar esse repositório. Isso facilita o controle, a padronização e a governança de dados, sendo muito positivo em termos de organização e governança.

Por outro lado, essa abordagem pode reduzir a autonomia das áreas. As decisões tendem a se tornar mais burocráticas. Vamos considerar um cenário em que uma área precise decidir pela manhã, avaliar o resultado à tarde e, no dia seguinte, já ter outro plano de ação, outra implementação, outro relatório. Tudo isso pode ser prejudicado por uma arquitetura centralizada — a menos que a empresa seja como o Google, com uma equipe grande capaz de dar vazão à alta demanda que surge no negócio diariamente. Assim, se por um lado a centralização auxilia na governança, por outro prejudica a autonomia das áreas de negócio.

Apresentando arquiteturas integradas e riscos de silos

Também existe outra forma de organizar os dados frequentemente implementada pelas áreas de arquitetura: as arquiteturas integradas, nas quais os dados ficam distribuídos pelas áreas de negócio, mas conectados entre si. Essa abordagem exige bons mecanismos de integração e um trabalho consistente com plataformas e ferramentas, porém é viável. Requer padrões claros e governança para que não se torne uma terra de ninguém.

Nós tivemos uma experiência profissional em que estávamos nessa terra de ninguém, porque os dados estavam descentralizados, havia pouca conexão entre eles e as áreas criavam seus próprios silos.

Esse é o principal problema que a área de Governança de Dados nasce para tentar resolver: eliminar silos de informação e dados descentralizados e desorganizados.

Quando implementamos uma arquitetura integrada, com os dados nas pontas mais integrados entre si, a governança se torna mais difícil, mas ainda assim funciona. O que não pode acontecer é o exemplo que mencionamos: dados descentralizados que não se conectam.

Avaliando autonomia, escalabilidade e governança

Nesse ponto, há uma decisão: o que fazemos? Damos autonomia à área local? Priorizamos escalabilidade? O que é melhor? Arquiteturas distribuídas oferecem mais autonomia às áreas de negócio para escalar decisões, mas, sem uma governança bem definida, aumentam o risco, a inconsistência, a duplicidade e a perda de controle.

A arquitetura também define se o acesso é simples ou burocrático, se é centralizado ou distribuído. Tudo isso impacta diretamente a velocidade com que o negócio percebe o uso do dado. Podemos criar um processo muito rigoroso para que a pessoa possa acessar um dado, seja ele sensível ou não. Tudo isso precisa passar pela área de Arquitetura, em conjunto com a área de Governança, para que o negócio acesse o que necessita.

Há um contraponto: se controlamos e governamos em excesso, tiramos autonomia e velocidade das áreas; se damos toda a autonomia e a velocidade que as áreas precisam, perdemos controle e governança. Esse é um cabo de guerra constante nas áreas de negócio.

Planejando segurança e qualidade desde o projeto

A arquitetura influencia diretamente qualidade e segurança, porque esses aspectos não são adicionados depois; nascem no projeto. A ideia é que, ao desenhar a arquitetura, já pensemos como serão tratadas as questões de segurança e de controle de qualidade para que a implementação nasça corretamente. Nesse processo, já durante o projeto, definimos onde serão feitas as provas de qualidade, como será o controle de acesso, quais controles e quais etapas precisamos implementar de modo a satisfazer as áreas de Segurança e Governança sem comprometer a autonomia de que o negócio precisa. Tudo isso deve ser projetado e definido já na concepção do modelo que pretendemos implementar.

Resumindo, ao final, a arquitetura é o que define quanto o dado realmente vale para o negócio: quão disponível e fácil deixamos esse dado nas mãos do negócio e quão controlado e governado mantemos esse mesmo dado. Esse contraponto precisa encontrar um equilíbrio: garantir segurança para que não haja risco de vazamentos, nada que manche a reputação ou prejudique a imagem da empresa no mercado, nem coloque em risco os dados de clientes — algo essencial para a empresa — e, ao mesmo tempo, cuidar da agilidade das áreas de negócio.

Concluindo com riscos de má arquitetura e próximos passos

Uma arquitetura mal planejada transforma a Governança em um esforço constante de correção, o que é muito ruim. Precisamos trabalhar para que, na concepção dos modelados e das implementações que a Arquitetura vai realizar, já nasça um equilíbrio adequado, de forma que tenhamos governança, segurança, controle de acesso etc. e, ao implementar tudo isso, também garantamos agilidade e informação com a qualidade de que o negócio tanto necessita.

Eu espero que tenha ficado um pouco claro. Nós vamos avançar nos próximos vídeos. Agradeço. [♪]

Sobre o curso Governança de dados: Governança e Arquitetura de Dados

O curso Governança de dados: Governança e Arquitetura de Dados possui 102 minutos de vídeos, em um total de 42 atividades. Gostou? Conheça nossos outros cursos de Governança de Dados em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Introdução a Governança e Arquitetura de Dados
• Fundamentos de Governança e Arquitetura de Dados
• Interações entre Governança de Dados e Arquitetura
• Estudos de Caso em Governança e Arquitetura de Dados
• Criando um processo para representar relações entre dados com grafos