Muchos equipos de datos creen que ya tienen una plataforma porque el aprovisionamiento se ha convertido en un script. Un comando crea el bucket, otro despliega el job de Spark, otro genera el pipeline de CI. Tom De Wolf, Architect and Innovation Lead de la consultora belga ACA Group, ha publicado en martinfowler.com un texto que desmonta esa sensación al aplicar al data mesh el modelo de madurez de ingeniería de plataformas de la CNCF. Una nota de transparencia: trabajé como Senior Data Engineer en Thoughtworks, empresa a la que está vinculado el sitio, hasta junio de 2026.
El tema importa ahora porque muchas empresas invierten en infraestructura como código esperando autonomía de los dominios y acaban con más fragmentación, no menos. Mi tesis es clara: lo que falta en la mayoría de las plataformas de datos no es automatización, sino la abstracción de producto de datos, y construirla es una decisión de diseño, no la compra de una herramienta.
Aprovisionar rápido no es tener una arquitectura coherente
Para entender por qué los scripts no bastan, conviene recordar lo que pide el data mesh. Goedegebuure et al. (2024) consolidan la visión de los profesionales sobre "the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance". La plataforma de autoservicio y los datos como producto aparecen juntos: la plataforma existe para servir productos, no componentes sueltos. El problema, según De Wolf, es que las tecnologías de datos "typically lack the necessary abstractions for concepts like data contracts or data products".
El modelo de la CNCF tiene cuatro niveles (Provisional, Operational, Scalable y Optimizing), evaluados en cinco aspectos: inversión, adopción, interfaces, operaciones y medición. Los scripts de Terraform por componente viven en el nivel Operational. Eliminan la cola de tickets, pero, como describe De Wolf, el desarrollador sigue solo a la hora de integrar red, roles de seguridad, almacenamiento, pipelines y secretos.
El resultado es lo que él llama productos de datos "Frankenstein", parecidos en la superficie porque usan las mismas tecnologías, pero "architecturally inconsistent under the hood". Para el argumento, esto demuestra que la velocidad de aprovisionamiento y la coherencia arquitectónica son cosas distintas, y optimizar la primera no garantiza la segunda.
Lo que aprendí al vincular garantías a los datos
Si automatizar componentes no basta, ¿dónde está el valor? Mi experiencia apunta a las garantías que acompañan al dato. En los últimos años he diseñado pipelines en distintas nubes: GCP en Thoughtworks, GCP y AWS en un proyecto multicliente en BairesDev, y construí una plataforma en Azure en Programmers. En todos esos puestos, la tarea iba más allá de mover datos: se trataba de entregar datos con SLA y una calidad que alguien pudiera exigir.
En WEX, un banco estadounidense, eso supuso aplicar estándares de gobierno y cumplimiento alineados con la regulación financiera y automatizar comprobaciones de calidad con Great Expectations. En BairesDev implanté observabilidad con DataDog y Monte Carlo, con detección de anomalías basada en ML para hacer cumplir los SLA de calidad. El resultado más concreto llegó en WEX: las comprobaciones automatizadas redujeron un 30% los incidentes críticos de datos.
Lo que esto demuestra para la tesis es que la mejora no vino de crear recursos más deprisa, sino de vincular garantías verificables al dato. Eso es justo lo que una abstracción de producto de datos debería ofrecer por defecto, en lugar de dejar que cada equipo reinvente el mismo pegamento.
La interfaz es una decisión de diseño
De ahí la pregunta central: ¿qué debe controlar esa interfaz de producto de datos? En el nivel Scalable que describe De Wolf, el desarrollador declara puertos de entrada y salida, el código de transformación y los contratos de datos, y la plataforma inyecta "automated policy checks, audit logging, access controls, and data quality verification". A mi juicio, debe ser responsable de cuatro cosas:
- el contrato, con esquema y garantías versionados;
- las comprobaciones de calidad, ejecutadas en cada carga;
- el acceso, derivado del contrato y no solicitado por ticket;
- el linaje, registrado en el momento de la creación.
Ninguna herramienta comercial decide esto por ti, porque es una elección sobre lo que contiene el camino por defecto. Anjum (2026) concluye que "the evidence supports treating platforms as products, combining delivery metrics with developer experience surveys, and designing golden paths as enablers instead of mandates". Es decir, el camino por defecto funciona cuando facilita la vida de quien construye, y eso exige un diseño de producto deliberado, no un catálogo de módulos.
El límite: no todas las empresas necesitan el nivel 3
La objeción más fuerte tiene que ver con el listón. De Wolf afirma que el nivel Scalable es "the minimal level for success" para el data mesh. Para organizaciones grandes, con muchos dominios, estoy de acuerdo. Pero es la opinión de un profesional que dirige el área de data mesh en una consultora que vende este tipo de trabajo, y la curva de adopción que presenta es conceptual, sin datos que la respalden.
La evidencia empírica sugiere que el cuello de botella no siempre es técnico. Bode et al. (2023) señalan 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". Si transferir la responsabilidad ya es difícil para quien adopta el modelo, una empresa pequeña con un equipo central competente puede, sencillamente, no necesitar data mesh.
Esto no debilita la tesis; acota su alcance. Con o sin malla, quien confunda scripts con plataforma tendrá el mismo problema: componentes rápidos y productos incoherentes.
Conclusión
Los argumentos convergen en un mismo punto. La automatización por componente resuelve colas, no arquitectura; el valor real aparece cuando las garantías viajan con el dato; y definir esas garantías es trabajo de diseño de producto, adopte o no la empresa el data mesh.
Mi recomendación es concreta: antes de escribir el próximo módulo de Terraform, escribe la especificación de un producto de datos de tu empresa, con contrato, calidad, acceso y linaje. Si tu plataforma no puede crear ese producto completo a partir de una única declaración, todavía no tienes una plataforma. Tienes un conjunto de scripts.
Referencias
- Tom De Wolf (2026). The Data Product Platform Navigator. martinfowler.com, newsletter de origen.
- 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.”