Data Product Platform Navigator: modelo de maturidade para plataformas de dados self-service

O texto de Tom De Wolf parte de um diagnóstico que quem trabalha com data mesh conhece: existe uma lacuna de plataforma. Computação, armazenamento, ingestão, catálogo, motor de consulta e ferramentas de qualidade não trazem abstrações nativas para data contract ou data product. Um data product completo depende da combinação de várias dessas peças, então nenhuma tecnologia isolada cobre o conjunto. A saída proposta é uma camada de plataforma por cima das tecnologias existentes, que reduza a carga cognitiva e organize a experiência em torno de contratos e produtos de dados.

Para medir o avanço, o autor usa o Platform Engineering Maturity Model da CNCF: quatro níveis (Provisional, Operational, Scalable, Optimizing) avaliados em cinco aspectos (Investment, Adoption, Interfaces, Operations, Measurement). No Nível 1, o desenvolvedor depende de contatos pessoais para obter repositório Git, pipeline de CI, bucket S3 e jobs de processamento, e dois times podem acabar com stacks diferentes (Iceberg com Spark num caso, BigQuery com dbt Cloud no outro). No Nível 2, os pedidos viram tickets ou scripts de IaC como Terraform, mas o desenvolvedor ainda precisa costurar tudo sozinho, e isso empurra muita gente para uma shadow IT.

A cobertura anterior do CEVIU toca temas vizinhos, mas não acompanha este modelo. Em 11 de fevereiro de 2026, o CEVIU noticiou "Cinco Recomendações Essenciais para Times de Plataforma em 2026", com dados sobre times que falham em medir sucesso e que enfrentam dificuldade de adoção, dois pontos que aparecem no modelo da CNCF como aspectos de Measurement e Adoption. Em 19 de fevereiro de 2026, "Conectando Apache Iceberg a Microsserviços em Produção" tratou de uma plataforma self-service da Wix. Não se trata de evolução do mesmo projeto, e sim de contexto complementar.

Para quem opera plataforma de dados, a leitura útil é usar a grade de níveis e aspectos como diagnóstico, não como meta de checklist. Se a adoção está baixa, o problema pode estar em Interfaces (o desenvolvedor ainda cola as peças na mão) ou em Operations (falta um time de produto ouvindo as dores). Mapear o estado atual por aspecto ajuda a priorizar investimento e a explicar a escolha para a gestão.