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.