La arquitectura tradicional de datos tiene un problema fundamental: un equipo central de datos (3-10 personas) es responsable de gestionar, transformar y servir los datos de toda la empresa. Este equipo se convierte en cuello de botella: cada nuevo reporte, cada nueva integración, cada cambio de esquema pasa por ellos. El resultado: colas de semanas para dashboards, datos desactualizados, y frustración generalizada.
Data mesh propone una solución radical: descentralizar la propiedad de los datos. Cada dominio de negocio (ventas, finanzas, RRHH, operaciones) es responsable de sus propios datos, los publica como “data products” con calidad garantizada, y los consume de forma autoservicio.
Los 4 Principios de Data Mesh
flowchart TB
A[Data Mesh] --> B[1. Domain Ownership<br/>Cada área es dueña de sus datos]
A --> C[2. Data as Product<br/>Datos con SLAs y documentación]
A --> D[3. Self-Service Platform<br/>Infraestructura para autonomía]
A --> E[4. Federated Governance<br/>Estándares globales, autonomía local]
Principios Explicados
| Principio |
Modelo Centralizado |
Data Mesh |
| Ownership |
Equipo de datos central es dueño de todo |
Cada dominio es dueño de sus datos |
| Calidad |
Equipo central garantiza calidad (intenta) |
Cada dominio garantiza calidad de sus products |
| Servicio |
Consumidores piden reportes al equipo central |
Consumidores acceden a data products self-service |
| Gobernanza |
Centralizada, reglas para todos |
Federada: estándares globales + autonomía local |
| Escalabilidad |
Lineal (más equipo central) |
Proporcional (cada dominio crece independiente) |
Data Products
¿Qué es un Data Product?
| Componente |
Descripción |
Ejemplo |
| Datos |
El dataset en sí |
Tabla de facturas procesadas del mes |
| Metadata |
Descripción, schema, origen |
“Facturas extraídas por OCR del SGD, actualizado diario” |
| SLA |
Freshness, completeness, accuracy |
“Actualizado cada 24h, 99% completo, 97% preciso” |
| Documentación |
Cómo usar, limitaciones |
README + data dictionary |
| API/Acceso |
Cómo consumir |
REST API, tabla en data warehouse, archivo Parquet |
| Owner |
Quién es responsable |
“Equipo de Cuentas por Pagar” |
Data Products para Gestión Documental
| Dominio |
Data Product |
Consumidores |
| Operaciones Doc |
“Documentos Procesados” (volumen, tipo, tiempo) |
BI, Gerencia |
| Compliance |
“Estado de Retención” (docs por vencer, cumplimiento) |
Legal, Auditoría |
| RRHH |
“Legajos Digitales” (completitud, vencimientos) |
RRHH, Gerencia |
| Finanzas |
“Facturas Procesadas” (montos, proveedores, SLA) |
Contabilidad, Compras |
| Legal |
“Contratos Activos” (vencimientos, renovaciones, riesgo) |
Legal, Gerencia |
Arquitectura
Modelo Descentralizado
flowchart TB
subgraph "Dominio: Finanzas"
A1[SGD Facturas] --> A2[Pipeline ETL<br/>del dominio]
A2 --> A3[Data Product:<br/>"Facturas Procesadas"]
end
subgraph "Dominio: Legal"
B1[SGD Contratos] --> B2[Pipeline ETL<br/>del dominio]
B2 --> B3[Data Product:<br/>"Contratos Activos"]
end
subgraph "Dominio: RRHH"
C1[SGD Legajos] --> C2[Pipeline ETL<br/>del dominio]
C2 --> C3[Data Product:<br/>"Legajos Digitales"]
end
subgraph "Plataforma Self-Service"
D[Data Catalog<br/>Descubrir data products]
E[BI Self-Service<br/>Dashboards por dominio]
F[Governance<br/>Estándares, calidad]
end
A3 & B3 & C3 --> D --> E
F --> A2 & B2 & C2
Implementación Pragmática
| Fase |
Semanas |
Actividades |
| 1. Identificar dominios |
1-2 |
Mapear 3-5 dominios de datos principales |
| 2. Primer data product |
3-6 |
Un dominio publica su primer data product con SLA |
| 3. Plataforma |
7-12 |
Data catalog (DataHub/OpenMetadata), BI self-service |
| 4. Escalar |
13-20 |
2-3 dominios más publican data products |
| 5. Gobernanza |
Continuo |
Estándares de calidad, naming, SLAs |
Stack Recomendado
| Componente |
Open Source |
Cloud |
| Data Catalog |
DataHub, OpenMetadata |
AWS Glue Catalog, Azure Purview |
| ETL/Transform |
dbt, Airflow |
dbt Cloud, Fivetran |
| Storage |
MinIO, PostgreSQL |
S3, BigQuery, Snowflake |
| BI |
Metabase, Superset |
Power BI, Looker |
| Quality |
Great Expectations, Soda |
Monte Carlo, dbt tests |
ROI
| Concepto |
Valor |
| Implementación |
S/ 100,000 - S/ 400,000 |
| Eliminación de cuello de botella central |
S/ 150,000 - S/ 500,000/año |
| Tiempo de entrega de reportes |
De semanas a horas |
| Autonomía de dominios |
Cada área crea sus propios análisis |
| ROI primer año |
200-400% |
Conclusión
Data mesh no es una tecnología sino un cambio organizacional: descentralizar la responsabilidad de los datos a quienes mejor los entienden — los dominios de negocio. Para gestión documental, esto significa que el equipo de finanzas es dueño de las métricas de facturación, legal es dueño de las métricas de contratos, y RRHH de los legajos — cada uno publicando data products consumibles por toda la empresa. Los principios son adoptables a cualquier escala.
En AyP Digital, implementamos arquitecturas de data mesh para gestión documental: data products, catálogos y analítica self-service. Contáctanos al +51 942 867 653 o escribe a ventas@aypdigital.com.