Arquitetura de dados: a base de decisões com inteligência nos negócios

Imagine que você está construindo uma casa, um projeto complexo que envolve diversas frentes. Quando falamos da arquitetura, nos referimos a tudo o que esteja associado à organização dessa construção. Já inteligência é o termo que se relaciona à forma como as atividades são acompanhadas: o registro das informações, a identificação de padrões e outros dados que orientam as escolhas ao longo da obra.

Esse exemplo é similar ao da construção de um software. Enquanto a arquitetura de dados foca na criação da estrutura, a inteligência de dados extrai valor dessa estrutura. Juntas, a arquitetura e a inteligência de dados resultam em sistemas preparados para escalar e absorver mudanças sem retrabalho. Além disso, usar os próprios dados para guiar essa jornada viabiliza ajustes e estratégias personalizadas e preventivas, o que se torna um diferencial competitivo.

Vale um momento de autodiagnóstico: sua empresa consegue confiar nos próprios dados? Esses dados estão reunidos em um único ambiente ou espalhados por ERP, CRM, planilhas e sistemas internos? Como eles são consolidados e com qual frequência? Suas decisões são baseadas em evidências ou em percepções? Se alguma dessas perguntas gerou dúvidas, pode ser que a arquitetura e inteligência de dados necessitem de ajustes.

Navegue pelo conteúdo:

• ‍Decifrando a arquitetura de dados
• ‍Arquitetura e inteligência de dados nas decisões
  
• ‍Qual o preço desses desafios nos negócios?
• Inteligência de Dados
• Explorador de dados: um exemplo prático da Caiena
  
• Como resolvemos os dilemas do Observatório Fundação Itaú?
• Como escolher fornecedores para arquitetura e inteligência de dados?
• FAQ
  
• Qual a diferença entre arquitetura e inteligência de dados?
• Qual a importância da arquitetura de dados nas empresas?
• Como escolher fornecedores para arquitetura e inteligência de dados

O livro "Decifrando Arquitetura de Dados", de James Serra, é uma referência para quem deseja se aprofundar nas aplicações práticas da arquitetura de dados em tecnologia. Para além dessa referência, a arquitetura de dados pode ser considerada como a etapa da criação do produto digital com maior retorno em relação à qualidade, planejamento e custo. 

Portanto, é possível definir que a arquitetura de um sistema, ou seja, sua estrutura e organização em vários componentes computacionais que possuem interação entre si, é a busca da resposta técnica para uma estratégia de negócio. Logo, ao definir uma arquitetura deve-se planejar para que ela seja a apropriada para todos os requisitos de subsistemas e componentes do software em questão.

Assim como existem diversos tipos de arquitetura de dados, existem diversas relações entre essas escolhas com as de outras frentes das organizações. Em alguns casos, a arquitetura pode ser vista de forma individual, específica por aplicação, mas essa divisão pode resultar em softwares de maior custo e com integrações mais sujeitas a falhas ao longo do tempo.

Quando cada conjunto de aplicações possui sua própria semântica em relação aos objetivos de negócio, podem surgir ilhas de informação. Vamos avaliar um exemplo: se uma aplicação define o termo “preço” como preço líquido, enquanto outra inclui em “preço” valores de impostos, cria-se uma dissonância semântica entre ambas.

Outro desafio de arquitetura de dados são as ilhas de automação: conjuntos limitados de atividades de negócio que não se comunicam com o processo global. Vamos usar como exemplo uma aplicação de atendimento de saúde que trata apenas do atendimento sem considerar o propósito e o local da atividade dentro do processo global. Isto requer que os usuários busquem informações não disponíveis na aplicação – mesmo que já tenham sido registradas em alguma outra aplicação da mesma organização. Além do retrabalho, surge o problema da duplicação de informações, que pode distorcer análises futuras. 

Divergências de arquitetura podem gerar custos e exigem tempo de trabalho das equipes de tecnologia, que precisam reunir as informações e processos que não foram projetados inicialmente para funcionar em conjunto.

Sendo assim, é importante que as decisões de arquitetura prezem pela escalabilidade e permitam separar procedimentos que acontecem em background, assim como tenham bem determinadas as responsabilidades dos usuários gestores de cada etapa e as lógicas de aplicações. 

Ferramentas de medição e monitoramento de inteligência de dados identificam gargalos na arquitetura de projetos de tecnologia e apoiam a criação de medidas de escalabilidade, aproveitando-se da estrutura proposta para reduzir indisponibilidades durante manutenções e picos de demanda.

Junto a decisões de arquitetura de software, como de arquitetura de telemetria, ferramentas de monitoramento são fundamentais para medir a demanda, a utilização dos recursos e proporcionar um ambiente sustentável de análise e incremento da infraestrutura e do software. Essa prática orienta os decisores às escolhas sadias, que correspondam aos cenários e aos problemas reais que a organização deseja sanar com este produto digital.

Quando estruturamos o Explorador de Dados para o Observatório da Fundação Itaú, um dos objetivos era oferecer autonomia para os gestores da plataforma, assim como uma interface para usuários do observatório visualizarem dados e indicadores. Porém, partimos de bases heterogêneas, que deveriam ser cruzadas entre si e gerar análises autônomas – onde entra a inteligência de dados. Para isso, criamos uma arquitetura de dados consistente. É na soma desses dois fatores que encontramos o valor dessa funcionalidade.

Afinal, arquitetura e inteligência de dados não se resumem a dashboards ou gráficos bonitos. Neste caso, para além da aparência, criamos uma arquitetura de dados que atendesse às reais demandas da Fundação Itaú de forma consistente e confiável, e que também aumentasse a autonomia dos usuários, transformando dados em conhecimento.

Durante o desenvolvimento, a equipe da Caiena se deparou com um dilema comum em organizações que produzem conhecimento: muitos conteúdos que abasteceriam o Explorador de Dados tinham a sua própria estrutura, nomenclaturas e lógica de organização.

Para resolver isso, a Caiena construiu uma arquitetura de dados capaz de sustentar o crescimento da plataforma, buscando soluções para questões estruturais que essa característica se tornasse um problema de interface ou gerasse prejuízos. Algumas das decisões de arquitetura de dados foram:

• Integração das diferentes bases em um data lake utilizando Snowflake;
• Criação de um modelo unificado de dados;
• Padronização de indicadores, filtros e categorias;
• Desenvolvimento de um dicionário comum de dados;
• Revisão, sanitização e reorganização das bases existentes;
• Definição de uma estrutura preparada para receber novas pesquisas continuamente.

Com a implementação do Explorador de Dados, os usuários passaram a criar análises personalizadas sem necessidade de apoio técnico, e a plataforma tornou-se mais escalável e preparada para evoluir ao longo do tempo. 

O que esse case da Caiena mostra é um caminho de raciocínio aplicável a outros contextos: identificar onde estão as ilhas de informação, unificar a semântica antes de construir interfaces, e garantir que a estrutura seja sustentável conforme o volume de dados aumente.  

Se o seu projeto de tecnologia enfrenta esse desafio em suas bases de dados, indicadores ou relatórios que dependem de intervenção manual, o problema provavelmente está na camada de arquitetura e inteligência de dados, muito além da visualização.

Existem diversas empresas de tecnologia que fornecem serviços voltados à arquitetura e inteligência de dados. Nessa decisão, os gestores dos projetos precisam avaliar com atenção a forma como a empresa lida com o ecossistema do negócio, não simplesmente a tecnologia, considerando critérios como:

• Metodologia para o diagnóstico;  
• Validação de hipóteses antes de propor arquitetura;
• As decisões técnicas devem ser compreensíveis mesmo para quem não é da área; 
• Ao final, a entrega deve deixa a equipe interna capaz de operar e evoluir o produto, sem necessidade de dependência de suporte contínuo. 

Uma empresa de tecnologia que domina as aplicações de arquitetura e inteligência de dados sabe a importância de manter um alinhamento nas entregas para que a excelência apareça na integração entre sistemas, na consolidação de bases e na construção de data lakes ou warehouses, entre outras etapas que impactam nos indicadores executivos, por exemplo. 

Para isso, é necessário saber lidar com metodologias claras, que possibilitam um bom diagnóstico do contexto, entendimento dos usuários, envolvem validações e a implementação de produtos preparados para crescer, sem bloqueios gerados por dependências de fornecedores.

Se esse é o seu contexto, a Caiena pode te ajudar nessa jornada. Criamos plataformas digitais sob medida para cada contexto, desde a descoberta inicial, o desenvolvimento, até a transferência de tecnologia. Já apoiamos diversas organizações a estruturarem seus dados para tomarem melhores decisões, com arquitetura sustentável e inteligência de dados. Se está tentando descobrir como isso se encaixa no seu caso, entre em contato para entendermos o seu contexto.

A Arquitetura de Dados é a camada estrutural: como os dados são modelados, armazenados, integrados e governados. Isso inclui decisões como onde os dados residem (data warehouse, data lake, lakehouse), como se integram entre sistemas (pipelines, ETL/ELT), quem pode acessar o quê (governança, segurança) e quais padrões garantem consistência (schemas, catálogos, qualidade). Já a Inteligência de dados é a camada de uso. Ela transforma dados organizados em entendimento e decisão. Isso cobre analytics, BI, modelos preditivos e dashboards. O resultado aqui é a interpretação, algo que uma pessoa ou um sistema usa para agir.

A arquitetura de dados é a etapa que antecede o desenvolvimento de software, mas, mais do que isso, representa uma decisão que define se o sistema vai crescer sem acumular custo invisível. Um modelo de dados mal pensado no início pode não demonstrar problemas de imediato, mas eles aparecerão meses depois, em forma de retrabalho, integrações frágeis e relatórios pouco confiáveis. Arquitetura bem-feita não garante qualidade por si só, mas reduz a distância entre uma pergunta de negócio nova e uma resposta confiável a essa pergunta, o que é, na prática, a diferença entre dívida técnica e capacidade de decisão.

Ao escolher um fornecedor para projetos de arquitetura e inteligência de dados, o critério mais relevante é a forma como ele traduz um problema de negócio em decisões técnicas. Fornecedores maduros mantêm essa tradução coerente em cada etapa — na integração entre sistemas, na consolidação de bases, na construção de data lakes ou warehouses — porque sabem que qualquer falha ali se propaga até os indicadores que a liderança executiva acompanha de fato.