Repartir la carga no es lo mismo que organizar el flujo 🚌
Cuando escuchan "data mesh", muchos líderes dan por sentado que la solución es darle a cada área autonomía sobre sus datos. Lo que se olvida es que autonomía sin acuerdos produce caos. Y el caos no escala.
Un data mesh bien implementado no elimina el orden central, lo redistribuye con reglas claras. Uno mal implementado solo mueve el desorden de lugar.
El data mesh es una arquitectura descentralizada que organiza la información por dominio de negocio (ventas, logística, clientes) y trata cada conjunto de datos como un producto que ese equipo debe mantener con calidad. Nació para romper el cuello de botella de un equipo técnico central que lo gestiona todo.
Piensen en cómo funciona el transporte urbano. Una ciudad pequeña opera bien con pocas rutas centralizadas. Una ciudad grande necesita múltiples líneas por zona. Pero si cada zona diseña sus rutas sin un mapa común ni normas de conexión compartidas, los pasajeros no llegan a ningún lado. No hay movilidad. Solo hay buses sueltos.
Repartir la carga no es lo mismo que organizar el flujo. Eso es exactamente lo que ocurre cuando una empresa adopta el data mesh sin gobernanza. Cada área genera sus propias definiciones. Lo que ventas llama "cliente activo" ya no coincide con lo que llama finanzas. Las decisiones se toman sobre datos que no se hablan.
El data mesh sí tiene sentido en organizaciones grandes, con equipos maduros en cada dominio y múltiples unidades de negocio con volúmenes distintos de datos. En esos contextos, centralizar todo en un equipo crea cuellos de botella reales. Distribuir tiene lógica.
Pero no tiene sentido cuando la organización apenas construye su primer gobierno de datos, ni cuando nadie tiene claro quién es dueño de qué. Agregar complejidad sobre una base frágil no acelera nada.
La pieza más omitida del data mesh es la gobernanza federada, que es el conjunto de normas compartidas que permite que los dominios sean autónomos sin volverse incompatibles. Es el mapa de rutas, la señalización común, el sistema de conexiones. Sin eso, cada bus opera a su propio ritmo.
Según el IBM Data Differentiator, el 82% de las empresas reporta que los silos de datos interrumpen flujos críticos y el 68% de sus datos sigue sin analizarse. El data mesh busca resolver eso. Pero sin estructura, solo redistribuye los mismos silos en más lugares.
Primero, evalúe si sus dominios tienen madurez para responder por sus datos. Luego, defina acuerdos mínimos de calidad antes de distribuir. Después, implemente un dominio a la vez. Por último, conserve un equipo central que garantice que las normas se cumplan en toda la red.
Versión en inglés
Distributing Load Is Not the Same as Organizing Flow 🚌
When people hear "data mesh," many leaders assume the solution is giving each department autonomy over its data. What gets forgotten is that autonomy without agreements produces chaos. And chaos doesn't scale.
A well-implemented data mesh doesn't eliminate central order, it redistributes it with clear rules. A poorly implemented one just moves disorder to a different place.
Data mesh is a decentralized architecture that organizes information by business domain (sales, logistics, customers) and treats each dataset as a product that the team must maintain with quality. It was born to break the bottleneck of a central technical team that manages everything.
Think about how urban transportation works. A small city operates well with few centralized routes. A large city needs multiple lines per zone. But if each zone designs its routes without a common map or shared connection standards, passengers don't get anywhere. There's no mobility. Just buses going around.
Distributing load is not the same as organizing flow. That's exactly what happens when a company adopts data mesh without governance. Each department generates its own definitions. What sales calls an "active customer" no longer matches what finance calls it. Decisions are made based on data that don't talk to each other.
Data mesh makes sense in large organizations with mature teams in each domain and multiple business units with different data volumes. In those contexts, centralizing everything in one team creates real bottlenecks. Distributing makes sense.
But it doesn't make sense when the organization is just building its first data governance, or when no one has clear ownership. Adding complexity on a fragile foundation doesn't accelerate anything.
The most omitted piece of data mesh is federated governance, which is the set of shared standards that allows domains to be autonomous without becoming incompatible. It's the route map, the common signage, the connection system. Without it, each bus operates at its own pace.
According to IBM Data Differentiator, 82% of companies report that data silos interrupt critical flows and 68% of their data remains unanalyzed. Data mesh seeks to resolve that. But without structure, it only redistributes the same silos in more places.
First evaluate whether your domains have the maturity to answer for their data. Then define minimum quality agreements before distributing. Then implement one domain at a time. Finally keep a central team that ensures standards are met across the network.