Los lagos y almacenes centralizados acumulan demanda: un solo equipo de datos debe entender todas las áreas, priorizar cientos de requests y mantener pipelines que crecen más rápido que el personal. El data mesh reparte esa responsabilidad siguiendo la estructura del negocio.
Cuatro principios que lo sostienen
- Propiedad descentralizada por dominio: cada área gestiona sus propios datos.
- Datos como producto: cada dataset se trata como un producto con clientes y nivel de servicio.
- Infraestructura como servicio: una plataforma común facilita crear y servir productos sin repetir trabajo.
- Gobernanza federada: reglas globales aplicadas localmente, no impuestas por un comité central.
Ninguno de los cuatro basta por sí solo. Quedarse solo en "repartir equipos" sin plataforma ni contratos produce islas de datos sin interoperabilidad. La clave es el equilibrio entre autonomía del dominio y estándares compartidos.
Principio 1 · propiedad por dominio
El dato se organiza alrededor de los dominios de negocio (ventas, logística, cliente), no de las tecnologías. Quien mejor entiende un dato es quien lo genera, así que esa persona o equipo lo mantiene, lo documenta y responde por él.
Principio 2 · datos como producto
Tratar un conjunto de datos como producto significa que tiene dueño, una interfaz clara, consumidores reales y un acuerdo de calidad. La pregunta pasa de "¿está cargado en el lago?" a "¿es confiable, descubrible y está listo para quien lo consume?".
- Direccional e identificable: tiene una dirección única estable.
- Descubrible: se puede encontrar y entender su propósito.
- Confiable: con contratos de calidad y nivel de servicio.
- Interoperable: sigue estándares comunes que permiten combinarlo.
- Nativo de seguridad: protege datos sensibles por diseño.
Principio 3 · infraestructura como servicio
Para que un dominio publique un producto de datos sin reinventar ingesta, cómputo, monitoreo y control de acceso, una plantaforma de autoservicio ofrece esos capacidades empaquetadas. Es lo que hace que la descentralización escale en vez de fragmentarse.
Principio 4 · gobernanza federada
La gobernanza deja de ser un gatekeeper central y pasa a ser un conjunto de políticas globales (seguridad, metadatos, interoperabilidad) que cada dominio aplica localmente, ayudado por la plataforma. Se coordina; no se impone.
| Aspecto | Lago/almacén centralizado | Data mesh |
|---|---|---|
| Propiedad del dato | Equipo central de datos | Cada dominio de negocio |
| Escalabilidad | Cuello de botella en el centro | Escala con los dominios |
| Calidad | Revisada al final | Contrato del producto, de origen |
| Gobernanza | Comité central | Federada con estándares globales |
| Riesgo típico | Sobrecarga del centro | Fragmentación sin plataforma |
Interoperabilidad: el pegamento
El precio de la autonomía es la consistencia. Sin estándares compartidos de identificación, metadatos y formatos, cada dominio habla su propio idioma y el mesh se vuelve un archipiélago. Los contratos y el catálogo global son el pegamento.
Errores frecuentes
- Cambiar de siglas sin dar a los dominios capacidad real ni plataforma.
- Ignorar los contratos de producto y volver a depender de pedidos ad hoc.
- Confundir gobernanza con imposición y generar fricción en vez de autonomía alineada.
Cuándo NO conviene
Para una organización pequeña, un proyecto puntual o un dominio único, un mesh aporta más fricción que valor. La descentralización paga cuando el volumen de demandantes y de dominios ya saturó el modelo central.
Ejemplo resuelto: de un lago monolítico a dominios
Una empresa con un equipo central de datos que no da abasto decide transitar al mesh por etapas:
- Identificar dominios de negocio con datos de alto uso y dueños claros.
- Definir el primer producto de datos con contrato de calidad y SLA.
- Levantar una plataforma de autoservicio que empaquete ingesta y monitoreo.
- Publicar estándares globales y un catálogo común de metadatos.
- Migrar gradualmente, midiendo reducción de la cola del equipo central.
¿Para qué sirve en la realidad?
El mesh es una respuesta organizacional al problema de escalar datos: acerca la responsabilidad al conocimiento del negocio. Bien ejecutado, reduce la dependencia del equipo central sin sacrificar gobernabilidad.
¿Qué problema organizacional intenta resolver principalmente un data mesh?
Un data mesh bien implementado elimina por completo los estándares globales de datos.
En el enfoque de datos como producto, cada dataset se sirve con un de calidad y un nivel de servicio.
Clasifica cada práctica según el modelo al que pertenece.
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
Une cada principio del mesh con su idea central.
Data mesh
Toca una tarjeta para ver la respuesta.
Data mesh: cuatro principios
- Data mesh
- Dominios
- propiedad cerca del negocio
- propiedad cerca del negocio
- equipos multidisciplinarios
- Dominios
- contrato de calidad
- autoservicio
- federada
- fragmentacion
Principles of Data Mesh (Martin Fowler)Explicacion de referencia de los cuatro principios y sus implicaciones técnicas.
Gestión de datos (Wikipedia)Contexto sobre administración de datos que el mesh busca descentralizar.
Tu empresa tiene un equipo central de datos desbordado por pedidos de tres áreas de negocio muy distintas. ¿Qué señales indicarían que conviene probar un data mesh, y con qué dominio empezarías el primer producto de datos?
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.