Muitas equipes de dados acreditam que já têm uma plataforma porque o provisionamento virou script. Um comando cria o bucket, outro sobe o job Spark, outro gera o pipeline de CI. Tom De Wolf, Architect and Innovation Lead da consultoria belga ACA Group, publicou no martinfowler.com um texto que desmonta essa sensação ao aplicar ao data mesh o modelo de maturidade de engenharia de plataformas da CNCF. Uma nota de transparência: trabalhei como Senior Data Engineer na Thoughtworks, empresa à qual o site é ligado, até junho de 2026.
O tema importa agora porque muitas empresas investem em infraestrutura como código esperando autonomia dos domínios e acabam com mais fragmentação, não menos. Minha tese é direta: o que falta na maioria das plataformas de dados não é automação, é a abstração de produto de dados, e construí-la é uma decisão de design, não a compra de uma ferramenta.
Provisionar rápido não é ter arquitetura coerente
Para entender por que scripts não fecham a conta, vale lembrar o que o data mesh pede. Goedegebuure et al. (2024) consolidam a visão dos praticantes sobre "the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance". Plataforma self-service e dados como produto aparecem lado a lado: a plataforma existe para servir produtos, não componentes soltos. O problema, segundo De Wolf, é que as tecnologias de dados "typically lack the necessary abstractions for concepts like data contracts or data products".
O modelo da CNCF tem quatro níveis (Provisional, Operational, Scalable e Optimizing), avaliados em cinco aspectos: investimento, adoção, interfaces, operações e mensuração. Scripts de Terraform por componente moram no nível Operational. Eles eliminam a fila de tickets, mas, como De Wolf descreve, o desenvolvedor continua sozinho para integrar rede, papéis de segurança, armazenamento, pipelines e segredos.
O resultado é o que ele chama de produtos de dados "Frankenstein", parecidos na superfície porque usam as mesmas tecnologias, mas "architecturally inconsistent under the hood". Para o argumento, isso mostra que velocidade de provisionamento e coerência arquitetural são coisas diferentes, e otimizar a primeira não entrega a segunda.
O que aprendi colocando garantias nos dados
Se a automação de componentes não basta, onde está o valor? Minha experiência aponta para as garantias que acompanham o dado. Nos últimos anos, arquitetei pipelines em nuvens diferentes: GCP na Thoughtworks, GCP e AWS num engajamento multicliente na BairesDev, além de construir uma plataforma em Azure na Programmers. Em todos esses papéis, a tarefa ia além de mover dados: era entregar dados com SLA e qualidade que alguém pudesse cobrar.
Na WEX, um banco americano, isso significou aplicar padrões de governança e compliance alinhados à regulação financeira e automatizar checagens de qualidade com Great Expectations. Na BairesDev, implementei observabilidade com DataDog e Monte Carlo, usando detecção de anomalias com ML para fazer valer SLAs de qualidade. O resultado mais concreto veio da WEX: as checagens automatizadas reduziram em 30% os incidentes críticos de dados.
O que isso prova para a tese é que o ganho não veio de criar recursos mais depressa, e sim de amarrar garantias verificáveis ao dado. É exatamente isso que uma abstração de produto de dados deveria oferecer por padrão, em vez de deixar cada equipe reinventar a mesma cola.
A interface é uma decisão de design
Daí a pergunta central: o que essa interface de produto de dados deve possuir? No nível Scalable descrito por De Wolf, o desenvolvedor declara portas de entrada e saída, o código de transformação e os contratos de dados, e a plataforma injeta "automated policy checks, audit logging, access controls, and data quality verification". Na minha leitura, ela precisa ser dona de quatro coisas:
- o contrato, com esquema e garantias versionados;
- as checagens de qualidade, rodando a cada carga;
- o acesso, derivado do contrato e não pedido por ticket;
- a linhagem, registrada no momento da criação.
Nenhuma ferramenta de prateleira decide isso por você, porque é uma escolha sobre o que o caminho padrão contém. Anjum (2026) conclui que "the evidence supports treating platforms as products, combining delivery metrics with developer experience surveys, and designing golden paths as enablers instead of mandates". Ou seja, o caminho padrão funciona quando facilita a vida de quem constrói, e isso exige desenho deliberado de produto, não um catálogo de módulos.
O limite: nem toda empresa precisa do nível 3
A objeção mais forte é sobre a régua. De Wolf afirma que o nível Scalable é "the minimal level for success" para o data mesh. Para organizações grandes, com muitos domínios, concordo. Mas essa é a opinião de um praticante que lidera data mesh numa consultoria que vende esse tipo de trabalho, e a curva de adoção que ele apresenta é conceitual, sem dados por trás.
A evidência empírica sugere que o gargalo nem sempre é técnico. Bode et al. (2023) relatam que "organizations have difficulties with the transition toward federated governance associated with the data mesh concept, the shift of responsibility for the development, provision, and maintenance of data products, and the comprehension of the overall concept". Se a transferência de responsabilidade já é difícil para quem adota o modelo, uma empresa pequena, com uma equipe central competente, pode simplesmente não precisar de data mesh.
Isso não enfraquece a tese; delimita seu alcance. Com ou sem malha, quem confunde scripts com plataforma terá o mesmo problema: componentes rápidos e produtos inconsistentes.
Conclusão
Os argumentos convergem no mesmo ponto. A automação por componente resolve fila, não arquitetura; o valor real aparece quando garantias viajam com o dado; e definir essas garantias é trabalho de design de produto, adote a empresa data mesh ou não.
Minha recomendação é concreta: antes de escrever o próximo módulo de Terraform, escreva a especificação de um produto de dados da sua empresa, com contrato, qualidade, acesso e linhagem. Se a plataforma não consegue criar esse produto inteiro a partir de uma única declaração, você ainda não tem uma plataforma. Tem um conjunto de scripts.
Referências
- Tom De Wolf (2026). The Data Product Platform Navigator. martinfowler.com, newsletter de origem.
- Bode, J.; Kühl, N.; Kreuzberger, D.; Hirschl, S.; Holtmann, C. (2023). Towards Avoiding the Data Mess: Industry Insights from Data Mesh Implementations. arXiv preprint 2302.01713 (later IEEE Access). “Our results show, among other insights, that organizations have difficulties with the transition toward federated governance associated with the data mesh concept, the shift of responsibility for the development, provision, and maintenance of data products, and the comprehension of the overall concept.”
- Goedegebuure, A.; Kumara, I.; Driessen, S.; Di Nucci, D.; Monsieur, G.; van den Heuvel, W.; Tamburri, D. A. (2024). Data Mesh: a Systematic Gray Literature Review. ACM Computing Surveys (arXiv 2304.01062). “The review provides insights into practitioners' perspectives on the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance.”
- Anjum, M. A. (2026). Platform engineering and internal developer portals: a multivocal literature review. Frontiers in Computer Science. “For practitioners, the evidence supports treating platforms as products, combining delivery metrics with developer experience surveys, and designing golden paths as enablers instead of mandates.”