Manufatura Japonesa e Arquitetura de Dados
Tudo está conectado.
Se ainda não fizeste :
Conheça mais sobre o Data Creators.
Siga no Linkedin e veja os resultados do Data Creators no Instagram.
A área de dados muitas vezes parece complexa. Complicada. Cheia de termos que mais confundem que esclarecem. Mas talvez o problema não seja a complexidade em si. Talvez estejamos apenas olhando para o problema da forma errada.
Vamos começar com uma pergunta simples.
O que a manufatura japonesa tem a ver com a arquitetura de dados moderna?
Tudo.
Em 1950, um estatístico americano chamado W. Edwards Deming viajou ao Japão para ensinar controle estatístico de qualidade. Seus ensinamentos transformaram a indústria japonesa. Mais tarde, a Toyota aperfeiçoou esses conceitos com o que conhecemos hoje como Toyota Production System (TPS).
A maioria de nós já ouviu falar do sistema Toyota. Muitos conhecem seu princípio fundamental: produção puxada em vez de empurrada (O famoso Just in Time). Os mesmos princípios podem te dar uma nova visão sobre o nosso trabalho com dados.
Importante dizer que este não é um ataque a arquitetura Medallion. Na verdade é apenas um exemplo para provar o ponto que quero transmitir.
Vamos lá.
PS: Eu sou Engenheiro de Produção (e não de dados), então este texto tem esse viés. Lembre, esta é a minha perspectiva sobre as coisas.
O problema da arquitetura Medallion
Antes de fazer a conexão com o modelo Toyota, preciso te mostrar o que está errado com uma das arquiteturas mais adotadas e faladas: a Arquitetura Medallion.
Tu provavelmente já a conhece. Ela divide os dados em três camadas:
Bronze - dados brutos
Silver - dados limpos e conformados
Gold - tabelas de negócio curadas
Parece lógico, não? Camadas progressivas. Cada uma melhor que a anterior.
Mas existe um problema fundamental aqui que quase ninguém fala.
A Medallion é um sistema de empurrar dados. Os engenheiros de dados extraem tudo que podem das fontes. Empurram para a camada Bronze. Depois empurram para Silver. E finalmente para Gold.
O resultado? Montanhas de dados movidos sem propósito claro. Um sistema inchado, caro e ineficiente.
Não parece familiar apenas para quem trabalha com dados?
Esta abordagem tem um nome na manufatura: produção empurrada.
Era exatamente assim que funcionavam as fábricas americanas antes da revolução Toyota. Produzir, produzir, produzir - independente da demanda real. Estoques enormes. Desperdício massivo. Baixa flexibilidade.
A Toyota percebeu há setenta anos o que a indústria de dados está apenas começando a entender agora.
Produção Puxada vs. Empurrada na Toyota
O sistema de produção Toyota inverteu a lógica tradicional das fábricas americanas. Em vez de simplesmente produzir em grandes lotes e empurrar o produto para o próximo estágio (criando estoques enormes entre etapas), a Toyota introduziu o conceito de produção puxada.
Na produção puxada, o processo subsequente "puxa" apenas o que precisa do processo anterior. Nada mais, nada menos. Exatamente quando necessário.
Imagine uma linha de montagem. Na estação B, um operador precisa de uma peça específica da estação A. No sistema Toyota, ele sinaliza essa necessidade (frequentemente usando cartões Kanban). A estação A então produz apenas o que foi requisitado.
Este sistema eliminou estoques desnecessários, reduziu desperdícios, aumentou a qualidade e criou flexibilidade para responder a mudanças de demanda.
O sistema puxado aplicado a dados
Agora, voltemos aos dados.
Se aplicarmos o pensamento Toyota à arquitetura de dados, o que teríamos?
Um sistema onde os dados são puxados pela necessidade de negócio em vez de empurrados pelas fontes.
Esta é a essência de uma arquitetura moderna que considera dados como produto (ou matéria prima que gerará conhecimento, leia mais na nossa série de negócios).
Ao contrário da abordagem Medallion, que começa empurrando todos os dados possíveis para dentro do sistema, a abordagem puxada começa com o fim em mente:
Quais perguntas de negócio queremos responder?
Quais métricas precisamos monitorar?
Quais decisões queremos apoiar com dados?
Somente depois de responder estas perguntas puxamos os dados necessários.
O fluxo de trabalho se inverte completamente. Os requisitos de negócio puxam a modelagem semântica. A modelagem semântica puxa os dados agregados. Os dados agregados puxam apenas os dados brutos necessários.
Esta é uma mudança de mentalidade simples. Mas como já sabemos, simples não quer dizer que seja fácil.
Na verdade, é uma transformação profunda na forma como pensamos sobre dados.
Os sete desperdícios na manufatura e nos dados
A Toyota identificou sete tipos clássicos de desperdício (muda) na manufatura. Todos eles também existem na área de dados quando usamos arquiteturas como a Medallion:
Superprodução - Na Medallion, ingerimos todos os dados possíveis, muito além do que realmente precisamos. Quantas tabelas estão realmente sendo usadas?
Tempo de espera - Usuários de negócio esperando que dados passem por todas as camadas antes de ficarem disponíveis. Dias ou semanas de espera quando poderiam ter acesso em horas.
Transporte - Movimentação excessiva de dados entre camadas. Cada movimento custa tempo, dinheiro e aumenta o risco de erros.
Processamento desnecessário - Transformações aplicadas sem saber se serão úteis. Limpezas e padronizações genéricas aplicadas a campos que talvez nunca sejam consultados.
Estoque - Armazenamento de dados que não geram valor. Terrabytes ou até petabytes de dados raramente ou nunca acessados.
Movimentação - Equipes diferentes trabalhando nos mesmos dados, duplicando esforços entre camadas. Analistas refazendo transformações que já deveriam estar prontas.
Defeitos - Erros que se propagam entre camadas. Problemas de qualidade difíceis de rastrear porque passaram por múltiplas transformações.
Como eu já disse várias vezes, tudo está conectado.
Se tu pensas que o seu trabalho é só codar, não poderias estar mais enganado.
Contexto é tudo
Na Toyota, o contexto importa. Cada peça existe por um motivo. Cada processo tem um propósito claro. Nada é feito sem entender seu papel no produto final.
É claro que isso é na teoria. Eu nunca trabalhei na Toyota para comprovar isso. Mas o importante aqui é a filosofia e o entendimento.
Na arquitetura Medallion, perdemos o contexto. As camadas Bronze e Silver têm pouca ou nenhuma conexão com o propósito final dos dados. Qualidade e governança são aplicadas sem entender o uso real.
Invertendo o fluxo, o contexto é rei. Começamos com os casos de uso e modelos semânticos. Estes definem quais dados precisamos e como devem ser estruturados.
O contexto não é apenas preservado - ele direciona todo o fluxo de trabalho.
A ilusão de progresso
Precisamos questionar: desde quando organizar dados em Bronze, Silver e Gold realmente ajuda os times de dados a entregar mais valor?
A Arquitetura Medallion dá uma sensação psicológica de progresso. Parece que estamos avançando, melhorando os dados a cada camada. Mas estamos realmente medindo se isso está acontecendo? Ou apenas criamos uma ilusão de controle?
Imagine que tu decidiste reformar tua casa. Existem duas abordagens:
Na primeira abordagem ("empurrada"):
Tu compras todos os materiais possíveis antes de começar - tintas de todas as cores, ferramentas variadas, móveis diversos
Contratas profissionais para preparar todos os cômodos simultaneamente
Aplicas um processo padronizado em cada ambiente, independente de suas necessidades específicas
Só depois descobres se o resultado atende às necessidades reais da tua família
Na segunda abordagem ("puxada"):
Tu decides exatamente como queres usar cada ambiente
Priorizas os cômodos mais importantes para tua rotina diária
Compras apenas os materiais necessários para cada etapa específica
Avalias o resultado de cada ambiente antes de seguir para o próximo
A primeira abordagem parece mais organizada e abrangente. Mas o que acontece? Gastas dinheiro com materiais que nunca usarás. Alguns cômodos ficam desconfortáveis porque foram reformados sem considerar seu uso real. E tens uma casa bonita que não funciona bem para tua vida cotidiana.
É exatamente assim que funciona a arquitetura Medallion. Parece organizada e completa, mas movimenta enormes volumes de dados sem saber se serão úteis, aplica transformações genéricas que podem não servir aos casos de uso reais, e cria uma infraestrutura cara e rígida que dificulta adaptações futuras.
A abordagem puxada é como a reforma 1: entende primeiro para que a casa (ou os dados) servirá, e só então investe recursos nas mudanças que realmente importam.
Kaizen aplicado a dados
O princípio da melhoria contínua (Kaizen) é central no sistema Toyota. Não se trata de grandes revoluções, mas de pequenas melhorias constantes.
A arquitetura Medallion é rígida. Mudanças exigem retrabalho em múltiplas camadas. Testar novas abordagens é complexo e arriscado.
No modelo puxado, cada produto de dados é independente e pode evoluir continuamente. Podemos experimentar, medir resultados e iterar rapidamente.
Isso permite uma evolução orgânica da arquitetura de dados, guiada por necessidades reais de negócio.
De operador a especialista
Um elemento frequentemente ignorado do sistema Toyota é como ele transformou o papel do trabalhador. Operários não eram apenas executores de tarefas, mas especialistas em seus processos, constantemente buscando melhorias.
Da mesma forma, o modelo puxado de dados transforma o papel de engenheiros e analistas de dados. Em vez de apenas mover dados entre camadas, eles se tornam especialistas nos domínios de negócio que atendem.
(Daí que surgiu o engenheiro de analytics..)
Não são mais apenas "pessoas técnicas" - são pontes entre tecnologia e negócio, com profundo conhecimento de ambos os mundos.
O perigo da adoção sem compreensão
Existe um problema fundamental que observo no mercado atual. Engenheiros e analistas estão adotando a arquitetura Medallion não porque ela é a melhor solução para seus problemas específicos, mas porque "alguém disse que é uma boa prática".
Esta aceitação sem questionamento é perigosa.
A arquitetura Medallion não é intrinsecamente ruim. Para certos casos de uso e contextos organizacionais, pode ser apropriada. O problema está na adoção cega, sem entender os princípios fundamentais por trás dela.
Vi equipes implementando camadas Bronze, Silver e Gold simplesmente porque viram em uma apresentação de um fornecedor cloud ou em um post no LinkedIn. Sem questionar se aquela estrutura resolve seus problemas reais.
Como diria o sábio: "Não procure apenas aprender o método, mas o pensamento por trás do método."
Cada organização tem necessidades únicas. Cada equipe de dados enfrenta desafios específicos. Tentar aplicar uma arquitetura "tamanho único" sem adaptação ao contexto é uma receita para o fracasso.
Este é o verdadeiro valor de um profissional: não são as técnicas específicas, mas a filosofia de questionar continuamente se estamos resolvendo os problemas certos da maneira certa.
A transformação não é apenas técnica
Um ponto crucial: a transformação da Toyota não foi puramente técnica. Foi também cultural.
Da mesma forma, adotar um modelo puxado de dados não é apenas sobre mudar ferramentas ou diagramas. É sobre mudar como pensamos sobre dados.
É abandonar a mentalidade de "coletar todos os dados possíveis" e adotar "coletar apenas os dados que importam”.
É deixar de ver dados como um ativo técnico e passar a vê-los como produtos a serviço do negócio.
Esta mudança cultural é ao mesmo tempo o maior desafio e a maior oportunidade na transformação.
Sinceramente, essa é a parte mais difícil.
Simplicidade além da complexidade
Existe uma frase atribuída a Oliver Wendell Holmes: "Busco a simplicidade do outro lado da complexidade."
A área de dados se afogou em complexidade. Criamos arquiteturas enormes, ferramentas sofisticadas, processos intrincados.
Mas a verdadeira inovação muitas vezes está em reduzir a complexidade, não em adicioná-la.
O sistema Toyota mostrou que princípios simples, aplicados consistentemente, podem transformar indústrias inteiras. O modelo puxado de dados promete fazer o mesmo com a gestão de dados.
A pergunta não é se devemos fazer esta transição, mas quando.
As organizações que adotarem sistemas puxados de dados mais cedo obterão vantagens competitivas significativas. As demais correm o risco de se tornarem as "montadoras americanas dos anos 80" do mundo de dados - grandes, ineficientes e ultrapassadas.
O tempo dirá quem escolheu o caminho certo. A história da manufatura já nos deu a resposta.
E a história se repete, sempre.
Conhecimento já tens, talvez falte uma perspectiva diferente.
Tudo está conectado.
Data Creators
A parte de Engenharia de Dados/Analytics é um déficit do Data Creators. Eu não sou engenheiro de dados.
Mas vamos resolver este problema.
A partir de agora teremos reuniões mensais sobre o assunto com um expert.
Se te interessa, me manda mensagem.
Mas lembre, no Data Creators não temos PowerPoints com aulinhas preparadas. Não é o objetivo.
O que eu quero para todos os DCs é que eles entendam como um Expert pensa. Como que é o modelo mental da pessoa. Como que ela decide fazer as coisas.
E para você entender isso, a única maneira é fazendo perguntas.
É ai que tá o pulo gato. Para você vir com perguntas, precisas estudar e botar a mão na massa. Não existem atalhos.
Gosto muito das ideias do Sistema Toyota: Kaizen, muri mura muda, poka yoke. E sou fã dos carros Toyota, que não quebram nunca!
Realmente está tudo conectado.
Dados são uma amostragem da realidade, que é o que importa no final das contas.
Muito bom! A maior parte do tempo do meu trabalho como analista ainda é entender quais dados, dentre milhares, são relevantes para o projeto. Depois corrigir estes dados e a análise fica com menor parte do tempo não me permitindo fazer análises mais robustas por causa do prazo. Realmente falta entendimento do negócio no time de engenharia e por isso eles tem o pensamento de melhor sobrar do que faltar.