Data mesh: qué es, cómo funciona y por qué no sustituye la gobernanza de datos

Data mesh es una forma de organizar la arquitectura de datos de una empresa distribuyendo la responsabilidad entre las áreas de negocio que generan los datos, en lugar de concentrar todo en un único equipo central. En vez de un equipo de datos en el medio, cuidando un único data lake para toda la empresa, cada dominio (compras, ventas, logística, finanzas) pasa a ser dueño de sus propios datos y a tratarlos como un producto que otras áreas van a consumir.

Parece un detalle de arquitectura, asunto de equipo técnico. Pero el data mesh toca el punto más sensible de las empresas: quién responde por el dato. Y ahí la conversación deja de ser sobre tecnología y se vuelve una conversación sobre gobernanza de datos. En este artículo explico qué es data mesh, cómo funciona, quién lo usa, qué herramientas le dan soporte y dónde están las oportunidades. Y, sobre todo, por qué no elimina la necesidad de datos maestros bien gobernados. Si esa base está mal, el data mesh solo distribuye el problema.

Qué es data mesh, de forma directa

Data mesh es un modelo de arquitectura y de organización de datos basado en dominios. La idea central es que los datos analíticos de una empresa no deberían ser tratados por un único equipo central que no conoce el negocio a fondo, sino por las áreas que producen y entienden esos datos en el día a día.

El concepto fue formalizado por Zhamak Dehghani y ganó fuerza porque muchas empresas vivieron el mismo problema: el equipo central de datos se volvió un cuello de botella. Todo reporte, todo indicador, toda integración pasaba por una única fila. Las áreas se quejaban de lentitud, y el equipo de datos se quejaba de que no entendía las reglas de cada área. El data mesh nace como respuesta a esto, proponiendo distribuir la responsabilidad en lugar de centralizarla. Es un cambio de arquitectura, pero antes que eso es un cambio de responsabilidad, y todo cambio de responsabilidad dentro de una empresa es, en el fondo, un cambio de gobernanza.

Cómo funciona: los cuatro principios del data mesh

El data mesh se apoya en cuatro principios que funcionan juntos. El primero es la propiedad orientada a dominio: cada área pasa a ser dueña de sus datos. Quien conoce la regla del negocio es quien responde por el dato, y eso tiene sentido, porque nadie entiende mejor el dato de proveedor que quien negocia con proveedores todos los días.

El segundo es el dato como producto. Aquí está el giro de mentalidad. El dato deja de ser un archivo tirado en una carpeta y pasa a tratarse como producto, con dueño, documentación, calidad monitoreada y un consumidor en mente. Quien produce el dato necesita pensar en quién lo va a usar, como un equipo de producto piensa en el cliente.

El tercero es la plataforma self-service. Para que cada dominio cuide sus propios datos sin depender de un equipo central para cada tarea, la empresa necesita una infraestructura que permita publicar, encontrar y consumir datos sin reinventar la rueda en cada proyecto. Sin esa plataforma, el data mesh se vuelve solo una idea bonita que nadie ejecuta.

El cuarto es la gobernanza federada, el principio que más gente ignora cuando se deslumbra con la distribución. Aun con cada dominio cuidando sus datos, existen reglas comunes que valen para todos: definiciones, estándares de calidad, políticas de seguridad y privacidad. Y, siempre que es posible, esas reglas se aplican de forma automática dentro de la plataforma, no en un documento que nadie lee. Fíjate en el equilibrio: los tres primeros principios distribuyen, y el cuarto vuelve a coser todo. Sin el cuarto, data mesh no es descentralización, es fragmentación.

Data mesh y MDM: por qué uno no sustituye al otro

Aquí está el punto del que casi nadie habla, y es donde vive el riesgo. El data mesh trata de la arquitectura analítica, de cómo fluyen los datos hacia reportes y decisiones. Master Data Management trata de los datos maestros, los maestros de cliente, proveedor, material y producto que sostienen toda la operación. Son cosas diferentes, y el data mesh no resuelve el problema que el MDM existe para resolver.

Un ejemplo del tipo que aparece mucho en las empresas. Una organización adopta data mesh y distribuye la responsabilidad por dominio. Compras cuida los datos de proveedor, finanzas cuida al proveedor desde la óptica del pago y el área fiscal desde la óptica del impuesto. Cada uno es dueño de su pedazo. Solo que, si no existe un dato maestro único de proveedor, con una definición común de quién es ese proveedor, cada dominio va a ver un proveedor diferente. El reporte de compras va a decir que la empresa tiene ocho mil proveedores, finanzas va a decir seis mil, y nadie va a saber qué número es el correcto. El data mesh distribuyó la responsabilidad, pero distribuyó junto con ella el problema de definición.

Por eso repito que data mesh sin gobernanza de datos maestros es distribuir el desorden con más elegancia. La propiedad por dominio solo funciona cuando existe una capa de datos maestros gobernada, con golden record, con una definición única de qué es cliente, proveedor y material. Lo mismo vale para la IA: muchas empresas quieren usar data mesh para acelerar la entrega de datos a modelos de inteligencia artificial, pero si los datos maestros están duplicados o mal clasificados, la IA va a decidir sobre una base agujereada, solo que más rápido y en más lugares al mismo tiempo. La velocidad no arregla el dato malo. Como abordo en el libro Master Data Management: Fundamentos e Aplicações (libro en portugués), publicado por la editorial Brasport, la calidad del dato maestro es la base sobre la cual se sostiene cualquier arquitectura moderna. El data mesh no cambia eso. Solo hace que esa base sea aún más importante.

Quién usa data mesh y quién es responsable

El data mesh no es para toda empresa, y eso hay que decirlo con claridad. Tiene más sentido en organizaciones grandes, con muchos dominios, muchas fuentes de datos y un equipo central que se volvió un cuello de botella. Las empresas más pequeñas, con pocas fuentes y un volumen manejable, suelen resolverse mejor con una arquitectura centralizada bien hecha. Adoptar data mesh demasiado pronto solo agrega complejidad sin retorno.

Sobre la responsabilidad, el data mesh redistribuye roles. Cada dominio necesita gente que responda por sus datos, lo que acerca la figura del data owner y del data steward a las áreas de negocio. El dueño del dato deja de ser una abstracción y se vuelve alguien dentro de compras, de logística, de ventas. Existe además un grupo que cuida la gobernanza federada, un equipo de plataforma que cuida la infraestructura y, en la cima, alguien que responde por la estrategia de datos de toda la empresa, un rol que suele recaer en el Chief Data Officer. O sea, el data mesh no elimina los roles de gobernanza, los esparce por la empresa. Quien imagina que distribuir los datos significa necesitar menos gobernanza entendió el concepto al revés.

Qué herramientas dan soporte al data mesh

No existe una herramienta única llamada data mesh que se compre e instale. El data mesh es un modelo, y lo que existe son herramientas que apoyan cada parte de él. Para el catálogo de datos y para encontrar los productos de datos, el mercado usa soluciones como Collibra, Alation y Microsoft Purview. Para la capa de plataforma y procesamiento a escala, aparecen nombres como Snowflake, Databricks y las nubes de datos de los grandes proveedores. Para la calidad y la observabilidad, existen herramientas como Ataccama e Informatica. Y, para la base de datos maestros, que sostiene la definición común entre los dominios, el mercado usa plataformas de MDM como SAP Master Data Governance, Informatica, Stibo Systems, Reltio, Semarchy, Profisee y Ataccama.

Fíjate que la lista de MDM sigue ahí, en medio de una arquitectura data mesh. No es coincidencia. Es la confirmación práctica de que los datos maestros gobernados siguen siendo el cimiento, sea la arquitectura centralizada o distribuida. La elección de la herramienta debe partir del problema de la empresa y de su madurez, nunca del discurso del proveedor.

Cómo aprender y las oportunidades de carrera

Quien quiere entender data mesh de verdad necesita empezar por la base, y la base es gobernanza y datos maestros. Aprender data mesh sin entender calidad de datos, definición de datos, roles de gobernanza y ciclo de vida del dato maestro es aprender el techo sin el cimiento. Un buen camino pasa por dominar los fundamentos de la gestión de datos, estudiar el DAMA-DMBOK, que es el cuerpo de conocimiento de referencia del área, y considerar la certificación CDMP de DAMA cuando el objetivo sea consolidar la carrera. El error más común es quedarse atrapado en el vocabulario de moda, data mesh, data fabric, data lakehouse. Quien entiende gobernanza y datos maestros evalúa cualquiera de estos conceptos con criterio, en lugar de correr detrás del término del momento.

Y la demanda existe. El área de datos sigue siendo una de las que más contratan, y la gobernanza es la parte que las empresas descubren que necesitan cuando el proyecto empieza a trabarse. Las oportunidades aparecen en roles como data steward de dominio, especialista en gobernanza de datos, arquitecto de datos, product owner de productos de datos y, en el liderazgo, Chief Data Officer. El detalle que marca la diferencia es saber traducir: el profesional que solo habla de arquitectura se queda atrapado en TI, mientras que quien le muestra a la dirección que un proveedor duplicado se convierte en compra equivocada, impuesto equivocado y decisión equivocada es el que asciende.

Principales dudas sobre data mesh

¿El data mesh sustituye al data warehouse o al data lake? No. El data mesh es un modelo de organización y responsabilidad, no una tecnología que reemplace al data warehouse. Los productos de datos de cada dominio todavía usan data warehouses, data lakes y lakehouses por debajo. Lo que cambia es quién responde por ellos y cómo se ponen a disposición.

¿El data mesh acaba con la necesidad de MDM? No, al contrario. El data mesh distribuye la responsabilidad por los datos analíticos, pero sigue dependiendo de una definición única y confiable de cliente, proveedor y material. Sin datos maestros gobernados, cada dominio ve una versión diferente de la misma entidad y los números nunca cuadran.

¿Cuál es la diferencia entre data mesh y data fabric? El data mesh es un enfoque organizacional, centrado en dominios y responsabilidad. El data fabric es más tecnológico, centrado en integrar y automatizar el acceso a los datos por medio de metadatos. No son opuestos y pueden coexistir, pero parten de puntos diferentes.

¿Toda empresa debería adoptar data mesh? No. El data mesh resuelve problemas de escala y de cuello de botella en organizaciones grandes y complejas. A las empresas más pequeñas les suele ir mejor con una arquitectura centralizada bien gobernada. Adoptarlo por moda, sin el problema que lo justifique, solo agrega complejidad.

¿Por dónde empezar si la empresa quiere caminar hacia el data mesh? Por la gobernanza y los datos maestros. Antes de distribuir la responsabilidad, es necesario tener definiciones comunes, roles claros de dueño del dato y una base de datos maestros confiable. Distribuir sin esa base es esparcir el problema.

MDM Academy: donde la base se toma en serio

Todos estos conceptos, de data mesh a datos maestros, dependen de algo que ninguna arquitectura entrega por sí sola: profesionales que entiendan la gobernanza de datos de verdad. Para eso existe la MDM Academy, la escuela de gobernanza y datos maestros de 4MDG. La propuesta es formar a quienes viven el problema de los datos en el día a día, la gente de datos maestros, compras, supply chain, TI y gobernanza, con un contenido que parte de la práctica y traduce el concepto técnico en impacto de negocio. Si quieres construir esa base y crecer en un área que solo aumenta, vale la pena conocer la MDM Academy y unirte al Club de los Datos, donde intercambiamos experiencia real sobre gobernanza, datos maestros y carrera.

Conclusión

El data mesh es una respuesta legítima a un problema real. El equipo central de datos se volvió un cuello de botella en muchas empresas, y distribuir la responsabilidad por dominios tiene sentido cuando la escala lo justifica. Pero la parte que deslumbra, la descentralización, es también la que esconde la trampa. Distribuir datos sin gobernanza y sin datos maestros confiables no resuelve el problema, solo lo esparce por más lugares.

Lo que sostiene cualquier arquitectura de datos, antigua o moderna, sigue siendo lo mismo: definición clara, dueño del dato, calidad y una base de datos maestros en la que la empresa confía. El data mesh no cambia esa verdad, solo vuelve más evidente que, sin ese cimiento, ninguna arquitectura salva a la empresa de decidir mal. La pregunta que queda es simple: antes de pensar en distribuir tus datos, ¿tu empresa confía en la definición que tiene de cliente, proveedor y material?