Uno de los principales desafíos que enfrentan las organizaciones que dependen de datos para operar, competir e innovar es la escalabilidad. En este sentido, tienen la necesidad de escalar las capacidades analíticas mientras los modelos centralizados muestran señales de agotamiento.
Ante esto, Data Mesh aparece como una propuesta que replantea cómo se gestionan, comparten y gobiernan los datos para ayudar a las empresas a responder con rapidez y autonomía
Índice de temas
¿Qué es Data Mesh y por qué importa para la estrategia de datos de su empresa?
De acuerdo con IBM, Data Mesh es una arquitectura de datos descentralizada que organiza los datos por dominio empresarial, como marketing, ventas o atención al cliente. De esta manera, los productores de datos de dominio tratan sus datos como un producto, lo que permite encontrar, comprender y utilizar los datos de toda la organización.
Data Mesh nace como respuesta al desgaste de los modelos centralizados, que comienzan a mostrar sus limitaciones a medida que aumenta la complejidad del negocio. En lugar de concentrar toda la operación analítica en un solo equipo central, distribuye la responsabilidad entre los dominios que generan y conocen los datos.
El enfoque de Data Mesh se basa en cuatro principios fundamentales. Tal como indica el Departamento de Defensa de los Estados Unidos (DOD), estos son:
- La propiedad del dominio exige que los equipos de dominio se responsabilicen de sus datos; los datos analíticos deben organizarse en torno a los dominios, y la propiedad de los datos analíticos y operativos se transfiere a los equipos de dominio.
- Los datos como producto proyectan una filosofía de pensamiento de producto sobre los datos analíticos; es decir, existen consumidores de los datos más allá del dominio. El equipo de dominio es responsable de satisfacer las necesidades de otros dominios proporcionando datos de alta calidad.
- La plataforma de infraestructura de datos de autoservicio aplica el concepto de plataforma a la infraestructura de datos. Un equipo especializado proporciona funcionalidades, herramientas y sistemas independientes del dominio para crear, ejecutar y mantener productos de datos interoperables entre todos los dominios.
- La gobernanza computacional federada logra la interoperabilidad de todos los productos de datos mediante la estandarización, promovida a través de toda la malla de datos por el grupo de gobernanza. El objetivo principal es crear un ecosistema de datos que cumpla con las normas de la organización y las regulaciones del sector.
El objetivo final de Data Mesh es lograr que los datos acompañen el ritmo del negocio, y las empresas que lo adoptan suelen enfrentar escenarios en los que los enfoques tradicionales colapsan. Algunos casos son múltiples dominios que generan información en silos, diversas fuentes internas y externas, volúmenes masivos de datos transaccionales y operativos, y una demanda acelerada de analítica avanzada e inteligencia artificial.
Según datos de Market Research Future, el tamaño del mercado de Data Mesh se estimó en US$ 1.520 millones en 2024. Además, se proyecta que pasará de US$ 1.778 millones en 2025 a US$ 8.550 millones en 2035. Estas cifras representan una tasa de crecimiento anual compuesta (CAGR) del 17,0% durante el período 2025-2035.
¿En qué se diferencia Data Mesh de Data Lake o de Data Warehouse?
Data Mesh no es sinónimo de Data Lake ni de Data Warehouse. Estos tres enfoques responden a necesidades distintas y surgen en contextos diferentes a lo largo de la evolución de la arquitectura de datos.
Según Data Science Council of America, Data Lake sirve como repositorio central para todo tipo de datos generados en los diferentes segmentos del negocio. Esto incluye flujos de datos estructurados, registros de chat, correos electrónicos, imágenes y vídeos. Este enfoque opera más rápido que las bases de datos tradicionales, recopila datos durante un período prolongado y captura toda la información.
Mientras tanto, Data Warehouse es un repositorio estructurado para el almacenamiento de datos mediante consultas. Este enfoque colabora con un sistema de almacenamiento de datos operativos (ODS) para agregar información de diversas bases de datos organizacionales.
A continuación, una síntesis de las principales diferencias entre Data Mesh, Data Lake y Data Warehouse:
| Aspecto | Data Mesh | Data Lake | Data Warehouse |
| Objetivo principal | Descentralizar la gestión de datos para distribuir la propiedad y producción de data products por dominio. | Consolidar datos crudos en un repositorio central, sin modelado previo. | Ofrecer datos limpios, estructurados y listos para análisis corporativo. |
| Modelo de gobierno | Federado: cada dominio gestiona la calidad, la seguridad y el acceso siguiendo estándares globales. | Centralizado: un equipo de datos controla almacenamiento, acceso y políticas. | Centralizado pero optimizado: gobierno unificado y políticas claras para BI. |
| Fuentes de datos | Cualquier fuente relevante al dominio; integración distribuida. | Prácticamente ilimitadas: logs, IoT, bases relacionales, archivos, multimedia. | Datos operativos y transaccionales ya estructurados o regularizados. |
| Alcance organizacional | Alto: involucra procesos, cultura, responsabilidades y autonomía de equipos. | Medio: centraliza almacenamiento, sin modificar la estructura organizativa. | Medio-alto: requiere procesos formales de calidad y operaciones BI. |
| Arquitectura | Distribuida y orientada a dominios; cada dominio publica data products. | Centralizada en un repositorio único con múltiples zonas. | Centralizada con modelos dimensionales o tabulares para análisis. |
| Procesamiento | Propio de cada dominio, pero estandarizado por plataforma común. | Flexible: procesamiento diferido u on demand, ETL/ELT opcional. | ETL/ELT obligatorio y altamente gobernado. |
| Aplicaciones típicas | Organizaciones ágiles con múltiples dominios que escalan datos rápidamente. | Exploración analítica, ciencia de datos, ML, ingestión de grandes volúmenes. | Reporting corporativo, BI, KPIs, analítica estructurada. |
| Escalabilidad | Escala por dominio: cada equipo gestiona su propio crecimiento. | Alta, especialmente en cloud: storage barato y elasticidad total. | Alta, pero ligada al rendimiento de modelos estructurados y consultas. |
¿Cuándo sí y cuándo no conviene adoptar Data Mesh?
Quien introdujo el concepto de Data Mesh fue Zhamak Dehghani, directora de tecnología en Thoughtworks, especializada en arquitectura distribuida y tecnologías emergentes. Tal como indica TDWI, ella misma plantea que, si las partes interesadas experimentan dificultades para encontrar y acceder a los datos adecuados, puede que este enfoque sea la solución idónea.
Sin embargo, la decisión de adoptar Data Mesh no es tan simple y requiere un análisis profundo por parte de las organizaciones. Por esta razón, Paulo Caroli, autor, conferenciante y consultor especializado en transformaciones ágiles, Lean Inception y OKR, creó la Evaluación de Preparación para Data Mesh a partir de los aportes de Dehghani.
La evaluación de Caroli consiste en un gráfico radial con ocho aspectos puntuados de bajo a alto. De esta manera, si las puntuaciones finales son altas, el autor recomienda adoptar Data Mesh. No obstante, en el caso contrario, sugiere no hacerlo.
Los criterios que se tienen en cuenta en la evaluación son:
- Complejidad organizativa
- Estrategia orientada a los datos
- Apoyo de la dirección
- Tecnología de datos como pilar fundamental
- Adopción temprana
- Ingeniería moderna
- Organización orientada al dominio
- Compromiso a largo plazo
No obstante, también hay señales claras de que no es el momento de adoptar Data Mesh. Un error común es hacerlo en empresas con pocos dominios o con estructuras demasiado centralizadas, donde la descentralización no aporta valor y solo agrega complejidad.
Otro caso problemático aparece cuando la organización intenta copiar la arquitectura de microservicios sin acompañarla con un gobierno federado real. Dado que dividir los equipos y repositorios no resuelve los problemas de datos, esto puede terminar en una colección de silos nuevos.
Por último, conviene evitar Data Mesh cuando hay “falso self-service”. Esto sucede cuando se promete autonomía, pero las plataformas no están listas, los catálogos no funcionan, los permisos no escalan y los data products requieren tickets al equipo central para cualquier cambio.
¿Qué cambios organizativos exige (roles, responsabilidades y gobierno federado)?
La adopción de Data Mesh implica un gran cambio en la forma en que las organizaciones conciben el flujo de datos y la distribución de responsabilidades. Además de incorporar nuevas herramientas, es necesaria una reconfiguración estructural, ya que las áreas dejan de operar de manera aislada y pasan a convertirse en dominios con autonomía.
En este esquema se presentan nuevos roles y responsabilidades dentro de las organizaciones. Entre ellos, según un artículo académico de la Universidad de Tilburg, se encuentran:
- Equipos de la plataforma de datos: son responsables de construir y mantener la plataforma de datos de autoservicio. También crean modelos de infraestructura como código (IaC) que los desarrolladores de productos pueden usar para aprovisionar y configurar los recursos de infraestructura y los servicios de la plataforma para alojar y administrar productos de datos. Necesitan poseer habilidades en ingeniería de software y de datos.
- Product Owners: son responsables de ofrecer y gestionar los productos de datos en sus dominios. Deben garantizar que los productos de datos sean interoperables y cumplan los requisitos de los consumidores. Por lo general, son responsables de las actividades de gobernanza a nivel de dominio.
- Desarrolladores de productos: crean y publican productos de datos en Data Mesh utilizando las herramientas y los servicios que proporciona la plataforma de autoservicio.
- Agregadores de productos: crean y proporcionan productos de datos compuestos. Se diferencian de quienes crean productos de datos atómicos, alineados con la fuente, y de quienes crean productos de datos compuestos.
- Consumidores de productos: utilizan datos de los productos. Los agregadores de productos también son consumidores de productos, ya que consumen múltiples productos de datos y los agregan en productos de datos compuestos.
- Equipos de gobernanza federada: están compuestos por representantes de diferentes dominios de toda la organización y gobiernan la red globalmente.
¿Cómo luce una hoja de ruta pragmática de 6–12 meses hacia Data Mesh?
La transición hacia Data Mesh no empieza por un rediseño total de la arquitectura. En cambio, se debe priorizar un enfoque de incrementos controlados para ajustar procesos y generar resultados accionables desde el inicio. De este modo, en una ventana de 6 a 12 meses, una hoja de ruta pragmática se organiza en cuatro trimestres de trabajo consecutivos, cada uno orientado a consolidar un avance medible:
- Dominio piloto con su primer data product y contrato de datos: el punto de partida es seleccionar un dominio de negocio con una necesidad concreta y un flujo de datos bien identificado. Allí se construye el primer data product con su respectivo contrato de datos. Este dominio piloto sirve como terreno de pruebas para comprender cómo se articulan las responsabilidades entre los equipos.
- Plataforma mínima: una vez que el dominio piloto empieza a aportar valor, el siguiente paso es habilitar una plataforma mínima que normalice tareas repetitivas. Esto incluye mecanismos estándar de ingesta, un catálogo que permita descubrir activos de datos y los primeros controles sistematizados de calidad. La finalidad es reducir fricciones y permitir que los data products se publiquen con consistencia, seguridad y trazabilidad.
- Incorporación de 2 o 3 dominios adicionales y políticas federadas: con el andamiaje mínimo en funcionamiento, la organización puede escalar a dos o tres dominios más. La prioridad es lograr que cada equipo adopte los principios de Data Mesh sin perder autonomía, mientras se consolidan políticas federadas de seguridad, cumplimiento, nomenclatura, metadatos y reutilización.
- Hardening de observabilidad, costos y SLOs de datos: al llegar al cuarto trimestre, la organización puede concentrarse en robustecer capacidades transversales. Por ejemplo, la observabilidad de pipelines y data products, la gestión de costos asociada al consumo y la publicación de datos, y SLOs más precisos para disponibilidad, puntualidad y calidad. Este endurecimiento prepara la base para escalar más dominios y tomar decisiones informadas.
¿Qué KPIs empresariales y técnicos debería usted usar para medir ROI?
Al implementar Data Mesh, la medición del ROI exige observar al mismo tiempo indicadores de negocio y métricas técnicas. Desde el punto de vista empresarial, uno de los KPI más reveladores es el tiempo a insight. Esto es el número de días u horas que pasan desde que surge una pregunta del negocio hasta que se obtiene una respuesta accionable basada en datos confiables. Cuando el Data Mesh funciona, esto se reduce gracias a dominios autónomos que producen datos listos para usar.
A esto se suma la medición de ingresos o ahorros por caso de uso. Esta métrica permite expresar en términos económicos el impacto concreto de cada data product. A su vez, resulta clave monitorear el NPS de datos, que captura la satisfacción interna de los equipos que consumen la información y muestra si la organización percibe que los productos de datos realmente agregan valor.
Con respecto al plano técnico, los KPIs ayudan a verificar si los data products se construyen y evolucionan con la velocidad y calidad que requiere el negocio. El lead time de los data products revela cuántos días se necesitan para pasar de una idea a una versión productiva. Asimismo, permite evaluar si la autonomía por dominios acelera o frena la entrega de valor.
Por otro lado, el cumplimiento de contratos evidencia si los productos cumplen con los estándares comunes, mientras que el seguimiento de errores por millón mide la estabilidad y la confiabilidad. Por último, el costo por consulta o por caso de uso permite entender si la arquitectura distribuida escala de manera sostenible.
¿Cómo alinear Data Mesh con IA (incluida GenAI) y cumplimiento normativo local?
En la era de la IA, en la que la calidad y la gobernanza de los datos se vuelven cada vez más importantes para la gestión de los modelos, Data Mesh puede ser una herramienta clave. En este sentido, el informe Estado del Data Lakehouse, de Dremio, halló que la mejora de la calidad de los datos (64%) y de la gobernanza de datos (58%) son los principales objetivos al implementar Data Mesh.
Desde IT Masters Mag consideramos que alinear Data Mesh con las iniciativas de IA requiere entender que ambos modelos dependen de un mismo activo crítico, que son datos confiables, contextualizados y gobernados de forma consistente.
En un enfoque distribuido, cada dominio se convierte en un productor de datos y también en un entrenador potencial de modelos. Esto los vuelve responsables de la salud y trazabilidad de la información que los alimenta. Además, cuando se incorpora GenAI al ecosistema, la exigencia aumenta, ya que los modelos generativos requieren rastrear la procedencia de los datos, documentar su uso permitido y validar si los prompts, outputs o finetunings respetan reglas internas de seguridad y privacidad.
Por último, con respecto a la dimensión normativa, es necesario que Data Mesh incorpore desde el diseño las obligaciones locales. Esto incluye leyes de protección de datos personales, retención, portabilidad, soberanía, auditoría y requisitos sectoriales como los presentes en banca, salud o energía.
En definitiva, la combinación de Data Mesh e IA solo puede escalar de manera segura si los dominios cuentan con guardrails técnicos y legales explícitos. Así, cada producto de datos puede ser consumible, auditable y alineado con el marco regulatorio vigente en cada país.
