La Paradoja Centralista: por qué tu equipo de datos es un cuello de botella (y no es culpa suya)

No voy a pedirte que imagines una escena. Voy a contarte una que me pasó.

Estaba en un proyecto, tranquilamente, cuando cayó una auditoría regulatoria. De esas que no avisan. De esas que necesitan datos para ayer.

Fuimos al equipo central de datos. La respuesta: “Tres meses.”

Tres. Meses. Para una auditoría que necesitaba datos ya.

A base de escalar el problema (reunión con dirección, repriorizar, mover cielo y tierra) conseguimos mejorar los plazos. Pero ¿a qué coste? Sacando de la cola otras peticiones que, vale, quizá no eran tan urgentes, pero sí eran necesarias para quien las había pedido. El de Marketing que llevaba seis semanas esperando su dashboard. El controller que necesitaba cerrar su reporte trimestral. Todos desplazados.

Y aquí viene la parte que nadie cuenta: cuando los equipos ven que la cola central es un agujero negro donde las peticiones entran y no salen, ¿qué hacen? Exacto. Montan lo suyo. Se crean sus propios Excel, sus propios extracts, sus propias mini-bases de datos sin ningún tipo de gobierno. Duplicidades por todas partes. Zonas sin gestión. Datos que nadie audita.

Y lo peor: cada uno de esos apaños nace como “algo temporal”. Un plan táctico para salir del paso. “Ya lo migraremos al sistema oficial cuando haya capacidad.” Pero esa capacidad nunca llega. Y lo temporal se convierte en permanente. Capa sobre capa, parche sobre parche, hasta que un día miras tu ecosistema de datos y lo que tienes es lo que en ingeniería de software se llama una Big Ball of Mud: una bola gigante de barro donde todo está conectado con todo, nadie sabe exactamente qué depende de qué, y tocar cualquier pieza da miedo porque no sabes qué se va a romper.

El remedio acaba siendo peor que la enfermedad.

Y mientras tanto, la pregunta sigue ahí: si hoy tenemos bases de datos en la nube que procesan petabytes en segundos, si Spark procesa en minutos lo que antes tardaba horas, si tenemos dbt, Airflow, Databricks, Snowflake y mil herramientas más…

¿Por qué los equipos de datos somos más lentos que en 2005?

El problema no es la tecnología. El problema es que las empresas “data-centric” se han chocado de frente con un muro organizativo. Lo llamamos La Paradoja Centralista.

Entendiendo la Paradoja Centralista

Durante años, el manual de buenas prácticas decía: “Crea un único equipo central de Ingeniería de Datos. Ellos ingestan, limpian y sirven los datos a toda la compañía.”

Funcionaba cuando tenías tres informes y una base de datos Oracle. Pero en 2025, con 15 líneas de negocio pidiendo dashboards en tiempo real, modelos de ML que necesitan features frescas cada semana y un regulador que te pide demostrar el linaje de cada número que publicas… ya no funciona.

Lo que tienes es una paradoja insostenible con dos síntomas clarísimos.

Síntoma 1: El Cuello de Botella (IT lo hace todo, pero no escala)

Un equipo central de 8-12 ingenieros de datos intentando dar servicio a Marketing, Riesgos, Finanzas, Operaciones, Compliance, Actuariado y Producto. Al mismo tiempo. Con las mismas personas.

Es matemáticamente imposible que un solo equipo crezca al ritmo de las necesidades analíticas de toda una organización. Si el año pasado tenías 40 peticiones mensuales y este año tienes 120, necesitarías triplicar el equipo. Pero RRHH aprueba una contratación. Quizá dos si hay suerte.

El resultado: una cola de peticiones que crece más rápido que tu capacidad de entregarlas. El Time-to-Value se dispara de días a meses. Y cuando la cola se convierte en un agujero negro, los equipos de negocio hacen lo único que pueden: montar sus propias soluciones. Excel con macros. Extracts manuales. Mini-bases de datos en Access o Google Sheets. Nadie les puede culpar: tienen un negocio que sacar adelante.

Pero el daño colateral es brutal: duplicidades por todas partes, datos sin linaje, zonas enteras sin gestión ni gobierno. Cada solución táctica que se queda como “definitiva” añade una capa más a la bola de barro. Y cuando llega una auditoría (y siempre llega), no solo tienes que responder con datos: tienes que encontrarlos primero en un archipiélago de silos que nadie documenta.

Si te suena, no estás solo. Un estudio de Monte Carlo Data estimaba que los equipos de datos dedican el 40% de su tiempo a tareas reactivas: apagar fuegos, responder peticiones ad-hoc y arreglar pipelines rotos. Solo el 26% del tiempo se dedica a construir cosas nuevas.

Síntoma 2: La Ceguera de Negocio

Tus ingenieros de datos son unos cracks en Spark, Airflow o dbt. Saben optimizar un pipeline para que vuele. Saben particionar tablas, gestionar esquemas y desplegar en Kubernetes.

Pero no conocen el significado del dato.

Esto no es culpa suya. Es una consecuencia del modelo centralizado. Un ingeniero de datos genérico no tiene por qué saber qué diferencia una “Prima Neta” de una “Prima Bruta”. Ni qué significa un “Saldo Medio Ponderado a Coste Amortizado”. Ni cuándo un “Cliente” deja de ser “Cliente” y pasa a ser “Ex-Cliente” según la normativa IFRS 17.

Por otro lado, el actuario de Riesgos, la analista de Marketing o el controller de Finanzas conocen perfectamente estos conceptos. Viven con ellos todos los días. Pero no saben (ni deben saber) programar un pipeline en Spark.

El resultado es un bucle infinito de iteraciones:

1. Negocio escribe un requisito (normalmente ambiguo, en un Word).
2. Ingeniería lo interpreta (normalmente mal, porque le falta contexto).
3. Se construye un pipeline.
4. Negocio lo revisa: “No, esto no es lo que pedí. Falta el ajuste por tipo de cambio.”
5. Vuelta al paso 2.
6. Repetir 4-7 veces.

Cada iteración tarda días. Multiplica eso por 120 peticiones. El resultado: desconfianza mutua, frustración y decisiones lentas.

“El que sabe, no puede. El que puede, no sabe.”

La Trampa: “¡Pues hagamos Data Mesh!”

Llegados a este punto, alguien en una sala de reuniones (normalmente alguien que acaba de leer el libro de Zhamak Dehghani) levanta la mano y dice la palabra mágica: “Descentralicemos. Que cada departamento sea dueño de sus datos.”

Suena genial en la teoría. Resuelve la paradoja de un plumazo: el que sabe de Riesgos construye el producto de datos de Riesgos. El que sabe de Marketing construye el de Marketing. Cada dominio es autónomo. La gente de Negocio, que conoce el significado, trabaja codo con codo con los ingenieros de su propio equipo.

Pero cuando las empresas intentan llevar esto a la práctica, se encuentran con un enemigo aún peor que el cuello de botella: la anarquía de los silos.

La metáfora de la cocina: por qué los silos son un desastre

Para entender por qué esto falla, pensemos en un restaurante profesional.

En una cocina seria, el trabajo se organiza por estaciones especializadas. Hay un dominio de salsas (el salsero), un dominio de pastas, un dominio de carnes, un dominio de repostería. Cada estación es experta en lo suyo. El salsero hace las mejores salsas del mundo. El de pastas hace unos tallarines que te cambian la vida. El de carnes clava el punto de cocción siempre.

Esto es exactamente lo que propone Data Mesh: cada dominio se especializa en su producto de datos. Riesgos es el experto en datos de riesgos. Marketing en datos de campañas. Finanzas en datos contables. Cada uno es autónomo, cada uno conoce profundamente su materia.

Hasta aquí, perfecto. La autonomía funciona. Cada estación produce un producto impecable dentro de su especialidad.

Pero ahora llega el momento de la verdad.

El maître (el CEO, el regulador, el CFO) entra en la cocina y pide un plato complejo. No quiere un bol de tallarines sueltos. No quiere una salsa en un cazo. Quiere un plato compuesto: unos tallarines con salsa boloñesa, queso parmesano rallado y una guarnición de verduras salteadas.

Es decir: necesita que las salidas de VARIAS estaciones se combinen en un único plato coherente.

En datos, este “plato compuesto” tiene nombres muy concretos: un reporte de Risk Data Aggregation (RDA). Un cierre contable. Un informe regulatorio de Solvencia II. Una visión 360 de cliente. Cualquier entregable que cruce dominios.

Y aquí es donde se desmorona todo.

Porque cada estación ha optimizado para su propio mundo. El de pastas ha hecho unos noodles asiáticos de arroz (perfectos para su contexto). El salsero ha hecho una salsa napolitana para pizza (perfecta para el suyo). Y el de quesos ha preparado un tofu marinado (porque en su dominio eso es “queso”).

Ahora intenta montar ese plato. Tienes noodles de arroz con salsa de pizza y tofu marinado. Cada ingrediente es excelente por separado. Juntos, son un Frankenstein culinario.

Traslademos esto a los datos de una aseguradora:

• El dominio de Marketing gestiona campañas, leads e interacciones. Para ellos, un “Cliente” es cualquier persona que ha interactuado con una campaña, haya comprado o no. Su tabla tiene 23.000 registros.
• El dominio de Riesgos gestiona pólizas, siniestros y scoring. Para ellos, un “Cliente” es el titular de una póliza activa. Su tabla tiene 8.500 registros.
• El dominio de Ventas gestiona pipeline comercial. Para ellos, un “Cliente” es un lead con actividad en los últimos 90 días. Su tabla tiene 12.000 registros.

Los tres son especialistas brillantes. Los tres tienen razón dentro de su dominio. Pero ningún dominio se ha preocupado de que su definición de “Cliente” sea compatible con la del vecino.

Ahora llega el CFO y pide el RDA. Este reporte necesita cruzar clientes de los tres dominios con sus pólizas, sus posiciones financieras y su actividad comercial. Es el “plato compuesto”.

¿Qué número de clientes ponemos? Marketing dice 23.000. Riesgos dice 8.500. Ventas dice 12.000. Los importes no cuadran. Las claves no cruzan. Los períodos temporales no coinciden.

Noodles de arroz con salsa de pizza.

No es un problema de tecnología. No importa si usas Snowflake, Databricks o un clúster de Hadoop montado con chicle. Si cada dominio ha definido “Cliente” optimizando para su propio contexto sin pensar en el emplatado final, el plato cruzado siempre será un desastre.

¡Felicidades! Habrás sustituido un cuello de botella centralizado por un archipiélago de feudos inconexos. Cada isla produce datos impecables dentro de sus fronteras, pero incapaces de combinarse con los de las demás.

El verdadero reto: necesitas un idioma común (sin volver a centralizar)

Volvamos a la cocina. ¿Cómo resuelve un restaurante profesional este problema?

No volviendo a centralizar (eso sería que el chef ejecutivo cocine todo él solo, y ya vimos que eso no escala). Lo que hace es establecer acuerdos entre estaciones.

El salsero sigue siendo el especialista en salsas. Pero el chef ejecutivo ha definido un contrato: “Si una salsa va a acompañar pasta italiana, debe tener base de tomate San Marzano, textura X y punto de sal Y.” El salsero mantiene su autonomía para crear variaciones, pero respeta el contrato cuando su salsa va a combinarse con productos de otra estación.

Es decir: cada estación sigue siendo dueña de su producto, pero existe un acuerdo sobre cómo se “enchufan” las piezas cuando hay que montar un plato cruzado.

En ingeniería de software, este concepto tiene nombre: se llama Shared Kernel (Núcleo Compartido), un patrón de Domain-Driven Design. No es una base de datos centralizada. No es un equipo central que controla todo. Es un acuerdo mínimo sobre la identidad de los conceptos que cruzan dominios: qué es exactamente un Cliente, qué es un Contrato, qué es un Producto.

En nuestra aseguradora, el Shared Kernel definiría:

“Cliente es una persona física o jurídica con un NIF válido que ha tenido al menos una interacción contractual con la compañía.”

Esa es la identidad compartida. Es el “enchufe estándar” que todos respetan. No dice cómo debe usar Marketing ese Cliente, ni qué campos necesita Riesgos. Eso sigue siendo cosa de cada dominio.

Pero cuando Marketing habla de un “Cliente” con NIF 12345678A, Riesgos sabe exactamente de qué Cliente se trata. Y cuando el CFO pide el RDA, los dominios pueden cruzar sus datos porque todos parten de la misma identidad base.

Luego, cada dominio añade su propia capa de contexto especializado:

• Marketing añade: historial de campañas, canales de contacto, scoring de engagement.
• Riesgos añade: pólizas activas, siniestralidad, nivel de riesgo.
• Ventas añade: estado del pipeline, actividad reciente, probabilidad de cierre.

Cada estación sigue cocinando lo suyo. Pero ahora, cuando el maître pide el plato compuesto, los tallarines son italianos, la salsa es boloñesa y el queso es parmesano. Todo encaja.

La clave: el Gobierno del Dato tiene que ser software, no un PDF

Aquí es donde falla el 90% de las empresas.

Creen que el Gobierno del Dato es un comité burocrático que aprueba documentos. Un grupo de 12 personas que se reúne cada dos semanas para validar definiciones de campos en un Excel y producir un “Glosario de Negocio” en PDF que se sube a la intranet y que nadie vuelve a leer jamás.

El Glossary 2.0 que está en la página 47 del manual de gobierno dice que “Cliente” se define como… espera, ¿cuál era la versión vigente? ¿La del PDF de enero o la del Word de marzo? ¿Alguien actualizó los pipelines cuando cambió la definición?

Por supuesto que no.

El problema es fundamental: la documentación (lo que el dato SIGNIFICA) vive separada del código (lo que el dato HACE). Son dos mundos paralelos que se desincronizan el día uno y divergen un poco más con cada sprint.

Qué significa “Gobierno Operable” en la práctica

Pensad en cómo funciona el desarrollo de software moderno.

Ningún equipo serio escribe la documentación de su API en un PDF separado del código. Usan OpenAPI (Swagger): un fichero YAML que vive en el mismo repositorio que el código. Si añades un endpoint nuevo, lo defines en el YAML y el tooling genera automáticamente la documentación, los tests y hasta los stubs del cliente. Si cambias el YAML, el código se ve forzado a cambiar también.

Es imposible que la documentación se desincronice del código. Son la misma cosa.

¿Por qué en datos seguimos haciendo lo contrario?

Imaginad que la definición de qué es un “Cliente” no está en un PDF en SharePoint. Está en un catálogo ejecutable: un fichero estructurado (YAML, JSON, lo que quieras) que describe:

• La identidad: cuáles son los campos que definen unívocamente a un Cliente (NIF, tipo de persona).
• Las reglas de calidad: el NIF no puede ser nulo, debe tener formato válido, la fecha de alta debe ser anterior a hoy.
• Las relaciones: un Cliente puede tener N Contratos. Un Contrato pertenece a exactamente 1 Cliente.
• El versionado: cuándo cambió la definición por última vez, quién la aprobó, qué versión era la anterior.

Y ahora, la magia: cuando “lanzas” esa definición, un motor la lee y genera automáticamente:

• Las tablas base en tu data warehouse (con la estructura exacta que la definición dicta).
• Las validaciones de calidad (que corren antes de cada carga).
• La documentación actualizada (que es el propio catálogo, no un PDF aparte).
• Los contratos de datos para los consumidores downstream.

Tres cosas cambian radicalmente cuando haces esto:

1. Es imposible que documentación y código se desincronicen. Son la misma cosa. No hay “pues en el PDF ponía otra cosa”. Si cambias la definición, el pipeline se regenera con ella.
2. El gobierno deja de ser un “policía” que frena el desarrollo y se convierte en el “motor” que lo acelera. Añadir una columna nueva no requiere tocar cinco pipelines a mano: actualizas la receta y el motor regenera todo lo necesario.
3. Y la más importante: el propio usuario de negocio puede generar sus productos de datos. Sin depender de otro departamento. Sin esperar tres meses en una cola.

Esto es lo que cambia de verdad el juego. No es solo que “se tarda menos”. Es que desaparece la dependencia.

Para poner números: en proyectos donde he trabajado, modelar manualmente una sola tabla fuente en Data Vault 2.0 (análisis + diseño + DDLs + DMLs + tests + documentación) costaba entre 16 y 32 horas de trabajo. Multiplica eso por 100, 200 o 2.000 fuentes y ya tienes un horizonte de años-persona solo para la capa base. Cuando automatizas la generación desde un catálogo ejecutable, ese tiempo baja a 1-2 horas por tabla. Un 93% menos. Y lo que es más importante: esas 1-2 horas las puede hacer el propio analista de negocio, no un ingeniero de datos especializado.

La capa base de un modelo como Data Vault es lo suficientemente simple y estandarizada como para automatizarla de forma robusta. Cuando lo haces, lo que antes era un cuello de botella (el equipo central picando SQL a mano) se convierte en una herramienta que el propio negocio puede utilizar. El actuario, el controller, el analista de riesgos pueden crear sus propios productos de datos, con la garantía de que lo que generan es auditable, coherente con el resto del ecosistema y escalable.

Sin romper nada. Sin duplicidades. Sin zonas sin gobierno. Sin añadir otra capa a la bola de barro.

¿Recuerdas la auditoría que conté al principio? La de los tres meses de espera. Con este modelo, el equipo de Compliance no habría necesitado pedirle nada a nadie. Habría definido su producto de datos, el motor lo habría generado, y el dato habría estado disponible para la siguiente carga. Sin sacar de la cola al de Marketing. Sin que nadie monte un Excel paralelo por desesperación.

Ese es el cambio real: no es hacer lo mismo más rápido. Es que cada equipo pueda hacerlo por sí mismo, de forma gobernada.

Por qué esto importa AHORA

Quizá estés pensando: “Vale, suena bien, pero mi empresa ya tiene algo que funciona más o menos.”

El problema es que el “más o menos” tiene fecha de caducidad. Hay tres fuerzas que están apretando a los equipos de datos en 2025 como nunca antes:

• Fuerza 1: La presión regulatoria. DORA, IFRS 17, BCBS 239, el AI Act europeo… Todas estas normativas tienen algo en común: exigen que puedas demostrar el linaje de cada dato, desde el origen hasta el reporte final. Cuando cae una auditoría no te da tres meses: te da tres días.
• Fuerza 2: La velocidad del mercado. Tus competidores están lanzando productos de datos (modelos de ML, dashboards en tiempo real, automatizaciones) en semanas. Si a tu equipo le cuesta semanas modelar una sola tabla fuente, estás sobreviviendo en lugar de competir.
• Fuerza 3: El coste de la deuda técnica. Cada pipeline artesanal que escribes a mano es deuda que paga intereses. Esos Excel “temporales” que llevan tres años en producción, esas extracciones manuales y esos parches forman la Big Ball of Mud.

La combinación de estas tres fuerzas hace que el modelo artesanal de picar SQL a mano sea insostenible. No necesitas más ingenieros ni un equipo central más grande. Necesitas que cada equipo pueda crear sus propios productos de datos de forma autónoma, gobernada y con calidad nativa.

Y para que no suene a teoría: he especificado plataformas para entornos con más de 2.000 fuentes de datos y más de 50.000 artefactos gestionados (DDLs, DMLs, tests de calidad, transformaciones). A esa escala, la artesanía no es una opción. O industrializas o no llegas.

Lo que viene: de la teoría a la cocina (literalmente)

Este artículo es el primero de una serie de 12 semanas. A lo largo de los próximos meses voy a desgranar cómo implementar esto en la práctica, paso a paso, sin humo:

• Cómo construir el Shared Kernel usando patrones de Data Vault 2.0.
• Cómo aplicar Domain-Driven Design a los datos para que la arquitectura refleje el negocio.
• Cómo pasar de la artesanía a una Data Factory automatizada.
• Cómo conseguir que los equipos trabajen en paralelo sin pisarse y sin romper la coherencia global.

La próxima semana vamos a entrar en la cocina. Literalmente.

Vamos a usar la metáfora completa de un restaurante profesional para entender cada capa de una arquitectura de datos moderna: desde los ingredientes en bruto (los datos crudos del sistema origen), pasando por la mise en place, hasta el emplatado final.

Y veremos que, igual que en una cocina profesional, la clave no está en tener mejores sartenes, sino en tener mejores recetas.