La Receta: Cuando Negocio deja de pedir y empieza a construir

La semana pasada os conté la historia de una auditoría que necesitaba datos para ayer y un equipo central que tardaba tres meses. Y terminé diciendo que esta semana entraríamos en la cocina.

Pues aquí estamos. Bienvenidos a la cocina.

Pero antes de encender ningún fuego, dejadme que os cuente otra historia. Una que explica por qué la cocina necesita una receta antes de que nadie toque una sartén.

En un proyecto regulatorio, el equipo de Negocio tenía clarísimo qué informe necesitaba. Las salidas estaban perfectamente definidas: campos, formatos, periodicidad. Sabían exactamente qué plato querían servir.

Lo que no sabían era de dónde salían los ingredientes.

No conocían qué tablas del data warehouse contenían los datos que necesitaban. Ni en qué formato estaban. Ni cómo se llamaban. Y lo que es peor: tampoco sabían a quién preguntar, porque nadie era “dueño” de esos datos. Y aquí es donde IT se convirtió en detective: buscando datos por nombres de campo, por descripciones, por intuición. Preguntando en reuniones si alguien conocía esa tabla. Montando una primera versión a ciegas para que Negocio la revisara.

Lo que vino después fueron meses de iteraciones. Cuentas contables que sobraban. Otras que faltaban y que tenían que cuadrar. Productos que en un sistema se llamaban de una forma, en otro de otra, y en un tercero de una tercera. Y cada vez que surgía una duda, la misma pregunta: “¿Quién sabe qué es este campo? ¿Quién decidió que esto se calcula así?” Preguntas que iban de correo en correo sin que nadie las resolviera. Porque la “receta” no existía: solo había un plato deseado y un equipo de IT adivinando los ingredientes.

Y mientras tanto, los parches que íbamos montando para ir tirando — una vista aquí, un script allá, una tabla temporal que “ya limpiaremos” — se iban quedando. Permanentemente. Cada iteración dejaba un pequeño residuo de código que nadie documentaba y que nadie se atrevía a tocar después.

Este proyecto me enseñó algo que parece obvio pero que casi nadie hace: antes de cocinar, necesitas una receta.

No un documento con la foto del plato terminado. Una receta real: qué ingredientes necesitas, dónde están, cómo se llaman, y cómo se combinan.

El Teléfono Roto más caro del mundo

Lo que acabo de describir no es un caso aislado. Es un patrón que se repite en todos los proyectos de datos en los que he participado. Voy a formalizarlo para que lo reconozcáis:

1. El responsable de un área necesita un nuevo indicador. Sabe exactamente qué quiere: “Prima neta ajustada por tipo de cambio, excluyendo reaseguro, con corte mensual.” Lo tiene clarísimo en su cabeza.

2. Lo escribe en un correo. O en un Word. O en un ticket de Jira. Lo hace lo mejor que puede, pero es un actuario, no un redactor técnico. El resultado es algo como: “Necesitamos la prima neta menos reaseguro, pasada a euros, por mes.”

3. El ticket llega al equipo central de datos. Un ingeniero lo lee. Sabe de Spark, de Airflow y de dbt. Pero no sabe qué es “prima neta” ni cuál es la diferencia con “prima bruta.” Ni si “excluyendo reaseguro” significa restar una columna o filtrar registros.

4. El ingeniero hace su mejor interpretación, construye el pipeline y lo entrega.

5. Negocio lo revisa: “No, esto no es lo que pedí. El ajuste por tipo de cambio se aplica antes de restar el reaseguro, no después. Y falta el filtro por línea de negocio.”

6. Vuelta al paso 3.

7. Repetir entre 4 y 7 veces.

Lo que debería tardar una semana acaba tardando dos meses. Multiplica eso por las 120 peticiones de la cola y ya tienes por qué el Time-to-Value en datos se mide en trimestres.

Pero lo realmente interesante no es que este proceso sea lento. Es por qué es lento.

No es un problema de capacidad. No es que el ingeniero sea malo o que el actuario no sepa explicarse. Es un problema de traducción.

Hay un concepto del negocio que tiene que cruzar una frontera entre dos mundos. El mundo de Negocio (donde los conceptos tienen significado) y el mundo de IT (donde los conceptos se convierten en código). Y cada vez que un concepto cruza esa frontera, se degrada. Como en el juego del teléfono roto: la señal pierde fidelidad con cada salto.

Y en mi proyecto regulatorio, el problema era aún peor: no solo había que traducir qué quería Negocio, sino que además había que adivinar dónde estaban los datos. Porque “Producto” se llamaba de una forma en el sistema de contratos, de otra en el de facturación y de otra en el data warehouse. Nadie había unificado esa identidad.

Lo fascinante es que en ingeniería de software este problema se resolvió hace años.

Pero antes de ir a la solución, dejadme que os cuente lo que pasa de verdad en cada iteración. Porque no es solo “se tarda más.” Es que cada vuelta del teléfono roto tiene un coste que se multiplica:

• La primera iteración tarda 2-3 semanas: el ingeniero construye el pipeline de cero, basado en su interpretación del Word.
• La segunda iteración tarda 1-2 semanas: Negocio revisa, encuentra errores, el ingeniero corrige. Pero ahora tiene que entender por qué lo que hizo no es lo que pedían.
• La tercera iteración tarda otra semana: aparecen los casos borde. “¿Y cuando el tipo de cambio es cero? ¿Y cuando no hay reaseguro? ¿Y los contratos que se cancelaron a mitad de mes?”
• La cuarta y la quinta: a estas alturas el ingeniero ya lleva un mes y medio en esta tabla. Conoce el dato mejor que nadie en IT. Pero tiene otras 119 tablas esperándole.

Y aquí hay algo que no se suele contabilizar: el coste del contexto perdido. Cada vez que el ingeniero cambia de tabla y luego vuelve, necesita reconstruir el contexto mental. ¿Qué decíamos sobre el reaseguro? ¿Era antes o después del tipo de cambio? ¿El filtro era por línea de negocio o por tipo de operación? Todo eso vive en su cabeza o en un hilo de correos de 47 mensajes que nadie va a releer jamás.

El conocimiento se genera, se pierde, se regenera y se vuelve a perder. Con cada iteración.

En ingeniería de software esto se resolvió hace años. ¿Por qué en datos seguimos en 2005?

Si trabajas en desarrollo de software, el proceso que acabo de describir te parecería absurdo.

Imagina que para crear una funcionalidad, el product owner escribiera un Word explicando qué debe hacer. Luego, un desarrollador lo leyera, lo interpretara y codificara a mano. Luego, otro equipo escribiera la documentación en una wiki. Y luego, un tercero creara los tests en otro repositorio.

Cuatro artefactos separados. Nacidos del mismo concepto. Divergiendo desde el día uno.

Nadie hace esto. Sería una locura.

En desarrollo de software moderno, este problema se resolvió con una idea simple: un solo artefacto del que se genera todo automáticamente. La documentación, el código, los tests. Si cambias el artefacto, todo cambia con él. Es imposible que se desincronicen. Son la misma cosa.

Ahora volved al mundo de los datos. ¿Cuántos artefactos separados nacen de un mismo concepto de negocio?

1. El Word/correo de Negocio — lo que el usuario quiere (en su idioma).
2. El SQL del ingeniero — la interpretación técnica (en otro idioma).
3. La documentación en la wiki — lo que alguien se acordó de escribir (desactualizada desde el día dos).
4. Los tests de calidad — si es que existen, y si es que alguien los mantiene.
5. El glosario de negocio en PDF — el que nadie abre después de la reunión de kick-off.

Cinco artefactos. Cinco fuentes de verdad. Cinco versiones del mismo concepto que divergen un poco más con cada sprint.

¿Y si pudieras tener un único artefacto que fuera al mismo tiempo la definición, el código, la documentación y los tests de tus datos?

La Receta: mucho más que un Data Contract

Aquí es donde la metáfora de la cocina encaja a la perfección.

En un restaurante profesional, la receta no la escribe el fabricante del horno. La escribe el chef. El que sabe de sabores, texturas y combinaciones. El que entiende el plato.

El fabricante del horno lo que hace es garantizar que, dada una receta, su horno la ejecuta correctamente. 200 grados durante 45 minutos. El horno no opina sobre si el plato lleva romero o tomillo. Eso es cosa del chef.

Traslademos esto al mundo de los datos.

¿Quién sabe que “Cliente” se identifica por NIF y que un Cliente puede tener N Contratos? Negocio.

¿Quién sabe que “Prima Neta = Prima Bruta − Reaseguro Cedido” y que el ajuste de tipo de cambio se aplica antes? Negocio.

¿Quién sabe que la fecha de baja no puede ser anterior a la fecha de alta y que el importe no puede ser negativo? Negocio.

Entonces, ¿por qué le pedimos a IT que escriba la receta?

Esa es la pregunta que lo cambia todo.

La receta de la abuela

Pensad en la receta de la abuela.

La abuela hace una paella que te cambia la vida. Le pides la receta. Te dice: “Un chorreón de aceite. Un puñado de arroz. Sal al gusto. Y lo dejas hasta que esté.”

Ella con esas instrucciones hace una obra maestra. Lleva 40 años haciéndola. “Un chorreón” para ella son exactamente 47 mililitros. “Hasta que esté” son exactamente 18 minutos. “Sal al gusto” es exactamente media cucharadita. Pero eso no está escrito en ningún sitio. Vive en sus manos.

Ahora imagina que tres nietos intentan seguir esas mismas instrucciones:

• El primero interpreta “un chorreón” como medio vaso. Sopa de aceite.
• El segundo interpreta “hasta que esté” como media hora. Carbón.
• El tercero interpreta “sal al gusto” como “a mi gusto”. Incomible.

La abuela prueba los tres platos y dice: “¡Pero si os lo he explicado perfectamente!”

Tres nietos. Misma receta. Tres desastres distintos.

Sustituid “abuela” por “el analista de Negocio que lleva 15 años y lo tiene todo en la cabeza”. Sustituid “nietos” por “los tres ingenieros que intentan implementar su requisito”. Sustituid “paella” por “pipeline de datos”.

Tu data warehouse es la receta de la abuela. Funciona mientras la abuela vive. El día que se jubila, se va a otro proyecto o simplemente está de vacaciones… el plato desaparece con ella.

La receta que necesitamos es otra cosa. No “un chorreón”. Sino “200ml de aceite de oliva virgen extra.” No “hasta que esté”. Sino “180°C durante exactamente 45 minutos.” No prosa ambigua que un humano interpreta. Sino una especificación que una máquina ejecuta. Siempre igual. Sin importar quién la lance.

La receta — lo que en el ámbito técnico llamaríamos un Data Contract — debería ser un artefacto que cumple cuatro propiedades:

1. Lo escribe Negocio, en lenguaje de Negocio. No dice CREATE TABLE ni SELECT FROM. Dice: “Cliente se identifica por NIF y tipo de persona. Un Cliente tiene N Contratos. La Prima Neta es Prima Bruta menos Reaseguro Cedido.”

2. Es estructurado, no prosa. No es un Word con párrafos ambiguos. Es un fichero con estructura donde cada concepto tiene su sitio. Las definiciones son precisas. Las reglas son explícitas. No hay margen para la interpretación.

3. Es ejecutable. Aquí está la clave. No es un documento que un ingeniero lee e interpreta. Es un artefacto que un sistema lee y ejecuta. El sistema toma esa receta y genera automáticamente todo lo que necesita: las tablas, las cargas, las validaciones, la documentación. Sin traducción humana. Sin teléfono roto.

4. Es agnóstico de la tecnología. La receta no dice “crea una tabla en BigQuery.” Dice qué necesita Negocio. Si mañana migras de BigQuery a Snowflake, la receta no cambia. Cambia el horno. Exactamente como en la cocina: la receta de una boloñesa es la misma da igual si la cocinas en un horno de gas o uno eléctrico.

¿Cómo se ve una receta en la práctica?

Para que no suene abstracto, veamos qué contiene una receta de verdad. No os voy a enseñar código (eso vendrá más adelante en la serie), pero sí la estructura conceptual.

Imaginad una tabla de un sistema de pólizas de una aseguradora que tiene 200 campos. Todo mezclado en la misma fila: datos del cliente, del mediador, del producto, de la sucursal y de la póliza en sí.

La receta de esa tabla diría algo como:

Fuente: Tabla de pólizas del sistema core. 200 campos.

Entidades que contiene: - Cliente: identificado por el campo ID_CLIENTE. Es una entidad global (compartida con otras fuentes). - Mediador: identificado por COD_MEDIADOR. Global. - Producto: identificado por COD_RAMO + COD_MODALIDAD (clave compuesta). Global. - Sucursal: identificada por COD_TERRITORIAL + COD_OFICINA. Global. - Póliza: identificada por NUM_POLIZA + COD_CERTIFICADO (clave compuesta). Es la entidad específica de esta fuente.

Relación principal: - Una Póliza vincula a un Cliente, a través de un Mediador, de un Producto, en una Sucursal. Esa relación captura la operación completa.

Grupos de atributos: - Los campos de nombre, NIF, dirección y scoring pertenecen a Cliente (y van a su satélite). - Los campos de comisión y canal pertenecen a Mediador. - Los campos de prima, capital, franquicia y condiciones son atributos de la Póliza.

Toda esa información está en un fichero estructurado. No en un Word. No en la cabeza de alguien. En un artefacto que el sistema puede leer, validar y ejecutar.

Ahora pensad en el esfuerzo que supondría hacer esto a mano. Un ingeniero tendría que mirar los 200 campos uno a uno, decidir qué entidad de negocio representa cada uno, escribir el SQL para crear cada tabla, cada carga, cada validación.

Con la receta, el analista de negocio agrupa los campos arrastrándolos a la entidad que corresponde. El sistema genera el resto.

¿Veis la diferencia con un diseño funcional tradicional?

Un diseño funcional es un documento que un humano lee, interpreta y traduce a código. Es el paso 2 del teléfono roto. Está sujeto a ambigüedad, a desfase y a obsolescencia.

Una receta ejecutable es un artefacto que un sistema consume directamente. No hay paso 2. No hay traducción. No hay teléfono roto.

La especificación Y la implementación son la misma cosa. Eso es lo que la ingeniería de software consiguió hace años. Y eso es lo que la receta trae al mundo de los datos.

Y lo más importante: quien la escribe es el que sabe. El actuario de Riesgos. La analista de Marketing. El controller de Finanzas. En su propio idioma. Con sus propios conceptos. Sin necesitar saber SQL, ni Python, ni dbt, ni cómo funciona un pipeline de Airflow.

“El que sabe, por fin puede.”

Un matiz importante: cuando digo que Negocio escribe la receta, no estoy diciendo que abra un fichero técnico y escriba código. Negocio usa una herramienta que le presenta los campos de la fuente y le permite agruparlos, asignarlos a entidades y definir reglas — en su idioma, con su contexto. La herramienta le guía. El resultado es la receta ejecutable. Pero quien toma las decisiones sobre qué significa cada dato es Negocio, no IT.

Pero hay una quinta propiedad que casi nadie menciona

La receta implementa el Shared Kernel.

¿Recordáis el problema de la Semana 1? Cada dominio definía “Cliente” a su manera. Marketing con 23.000 registros, Riesgos con 8.500, Ventas con 12.000. Noodles con salsa de pizza.

La receta resuelve esto de raíz. Cuando un analista crea una receta para una tabla fuente y dice “esta tabla contiene la entidad Producto”, no está inventando un Producto nuevo. Está enganchando sus datos al concepto global de Producto que vive en el catálogo compartido. Con su identidad normalizada. Con su clave de negocio única.

Da igual si en la tabla de contratos se llama COD_PRD, en la de facturación se llama COD_PRODUCTO, y en el sistema legacy se llama PROD_BASE. La receta de cada fuente dice: “Mi campo COD_PRD es el Producto del catálogo.” Y el sistema normaliza la identidad automáticamente.

Es el enchufe estándar del que hablábamos la semana pasada, pero implementado en la práctica.

Y hay algo más. La receta no solo mapea entidades. Permite descomponer una tabla plana en sus entidades de negocio reales. Volvamos a nuestra tabla de pólizas de 200 campos. Con una receta, el analista puede decir: “Estos campos de nombre y NIF pertenecen a la entidad Cliente (y van a su satélite). Estos de comisión pertenecen a Mediador. Estos de ramo y modalidad a Producto. Y el resto son atributos de la Póliza.” Cada grupo de atributos se asigna a la entidad que corresponde semánticamente. Sin escribir SQL. Declarativamente.

La tabla plana se descompone en sus entidades de negocio. Y cada entidad se conecta al catálogo global.

Esto es lo que convierte la receta en algo mucho más potente que un Data Contract convencional. No solo documenta qué quiere Negocio. También implementa el idioma común entre dominios. También normaliza las identidades. También genera el código. Es el pegamento entre la Semana 1 (el Shared Kernel) y las próximas semanas (la despensa y la mise en place de la arquitectura).

Y hay una sexta propiedad: la receta está gobernada

Esto es algo que puede parecer obvio pero que en la práctica casi nadie hace bien.

La receta tiene un dueño. Un equipo responsable. Alguien a quien acudir cuando algo no cuadra.

Parece trivial, ¿verdad? Pues pensad en cuántos data warehouses conocéis donde esto sea cierto. Donde si necesitas saber qué significa un campo, o por qué una regla de transformación es como es, o a quién preguntar cuando un número no cuadra… haya una respuesta clara.

En la mayoría de empresas que he visto, pasa una de dos cosas:

Escenario 1: No hay gobernanza. Nadie es dueño de nada. Las tablas existen porque alguien las creó hace tres años y siguen ahí. Si necesitas entender un dato, preguntas por Slack, mandas un correo, y con suerte alguien se acuerda. El conocimiento vive en la cabeza de personas que pueden cambiar de equipo o irse de la empresa. Cuando eso pasa, el dato se convierte en una caja negra.

Escenario 2: Hay gobernanza… de cartón. Existe un proceso formal. Para subir algo a producción, alguien tiene que rellenar un formulario de gobierno: nombre del campo, descripción, tipo, sensibilidad. El problema es que ese formulario lo rellena gente técnica que no conoce el dato. Lo hacen para cumplir el trámite, no para documentar la realidad. El resultado es una documentación que dice cosas como “IMP_SALDO: importe del saldo” (gracias, eso ya lo veía por el nombre del campo) o “COD_PROD: código del producto” sin explicar qué producto, de qué sistema, ni qué diferencia hay con COD_PRD de la tabla de al lado.

Es gobernanza para salir del paso. Cumple el checkbox. Pero no le sirve a nadie.

Y hay un tercer escenario que es el más traicionero: el que casi funciona. En un proyecto, alguien hizo las cosas bien. Documentó cada tabla, cada campo, cada regla de transformación. Creó un catálogo completo en Confluence. Fue un trabajo impecable. Pero no asignó owners. No declaró quién era responsable de mantener cada definición. Seis meses después, esa persona cambió de proyecto. Nadie sabía quién mantenía el catálogo. Las definiciones se fueron quedando obsoletas. Un año más tarde, el catálogo era otro PDF muerto — solo que más bonito.

El problema no era la documentación. Era que la documentación no tenía dueño.

La receta cambia esto de raíz, por tres motivos:

Primero, la receta la escribe el que conoce el dato. No un técnico rellenando un formulario, sino el analista de negocio que sabe por qué ese campo existe y qué significa. La documentación es útil porque la escribe quien tiene el contexto.

Segundo, la receta tiene un owner explícito: un equipo, un dominio, una persona responsable. Si algo no cuadra, sabes a quién preguntar. No hay “esto lo montó alguien que ya no está.” La propiedad del dato está declarada en el propio artefacto.

Tercero, y esto es lo más importante: la gobernanza no es un paso extra. No es un formulario que rellenas después de construir el pipeline. Es el propio pipeline. La receta ES la documentación, ES el mapeo, ES el contrato de calidad. No puedes crear un pipeline sin receta, y la receta ya lleva la gobernanza incorporada. No hay forma de “saltarse el trámite” porque el trámite es el artefacto.

El gobierno deja de ser un peaje que frena el desarrollo y se convierte en la infraestructura que lo habilita.

Un momento: ¿esto no es lo mismo que un diseño funcional?

Si eres arquitecto de datos, probablemente estés pensando: “Vale, pero esto suena a lo que siempre hemos hecho. Un diseño funcional, una especificación, un documento de mapeo. ¿Qué tiene de nuevo?”

La diferencia es sutil pero lo cambia todo: el diseño funcional lo lee un humano. La receta la lee una máquina.

Un diseño funcional es un documento que un humano interpreta y traduce a código. Si se equivoca, iteración. Si el diseño cambia y nadie actualiza el SQL, desincronización. Una receta ejecutable es un artefacto que un sistema consume directamente. No hay interpretación. No hay paso intermedio. Es como la diferencia entre un mapa de carreteras y un GPS con navegación: el mapa te informa, el GPS te lleva.

La receta es el primer artefacto en la historia de los datos que es simultáneamente: especificación, documentación, código y contrato. Son la misma cosa.

Volvamos a mi proyecto regulatorio

¿Recordáis el informe regulatorio donde IT hizo de detective durante meses?

Ahora que hemos visto las seis propiedades de la receta, pensad en qué habría cambiado:

Producto ya habría existido como entidad global en el catálogo. Cada fuente que contiene datos de producto (contratos, facturación, el legacy) habría tenido su mapeo declarado en su propia receta: “Mi campo COD_PRD de este sistema = Producto del catálogo.”

IT no habría hecho de detective. Cuando el informe regulatorio necesita “Producto”, el sistema ya sabe dónde está en cada fuente, cómo se llama en cada sitio, y cómo normalizarlo. El informe se habría montado cruzando recetas, no adivinando.

Y cuando algo no cuadraba, habríamos sabido a quién preguntar. ¿Las cuentas contables que sobraban? La receta de contabilidad tiene un owner. Le preguntas directamente. ¿El producto que se llama distinto en cada sistema? El owner de la entidad Producto en el catálogo es quien resuelve la ambigüedad. No un ingeniero buscando en Slack a ver si alguien se acuerda.

En nuestro proyecto, la mitad de las iteraciones no fueron por errores técnicos. Fueron porque no sabíamos a quién preguntar. “¿Este campo es el que necesitamos o es el otro?” “¿Quién sabe por qué esta cuenta aparece dos veces?” “¿Quién decidió que este filtro se aplicaba así?” Preguntas que iban de correo en correo, de reunión en reunión, durante semanas. Con un owner declarado en cada receta, esas preguntas se resuelven en minutos.

Las cuentas contables que sobraban o faltaban se habrían detectado el día uno. Porque la receta dice explícitamente qué campos participan en el informe. Si falta uno, el sistema lo sabe antes de generar nada. No después de que alguien monte un pipeline y Negocio diga “esto no cuadra.”

Y los meses de iteraciones sobre “este producto no es el que necesito, es el otro” habrían sido minutos: cambias el mapeo en la receta, el sistema regenera, Negocio valida. Sin esperar a que IT reinterprete un Word.

“El que sabe, por fin puede. Y cuando no sabe, sabe a quién preguntar.”

“Entonces, ¿los ingenieros de datos sobran?”

Si eres ingeniero de datos y has llegado hasta aquí, probablemente estés pensando: “Un momento. Si Negocio escribe la receta y el sistema genera todo automáticamente… ¿qué hago yo?”

Es la pregunta del elefante en la habitación. Y la respuesta es justo lo contrario de lo que parece.

Volvamos a la cocina. Cuando digo que “el chef escribe la receta”, no estoy diciendo que el restaurante no necesite ingenieros. Todo lo contrario. ¿Quién diseña la cocina? ¿Quién instala los hornos, las cámaras frigoríficas, los sistemas de extracción? ¿Quién se asegura de que el gas llega a cada estación, de que la ventilación funciona, de que los sistemas de seguridad están en orden?

Los ingenieros. Sin ellos no hay cocina.

Pero — y aquí está la clave — su trabajo no es cocinar. Su trabajo es que la cocina funcione. Que cualquier chef pueda entrar, leer su receta y ejecutarla sin tener que preocuparse de si el horno está calibrado.

En datos, la historia es exactamente la misma. El ingeniero de datos deja de ser el que traduce Words a SQL (un trabajo que, seamos honestos, nadie disfruta y que está por debajo de su nivel de especialización). Y pasa a ser el responsable de la plataforma:

Construye la cocina. Diseña la infraestructura: cómo se ingestan los datos, cómo se almacenan, cómo se procesan.

Mantiene los estándares. Se asegura de que las recetas de un dominio son compatibles con las de otro. Que el Shared Kernel se respeta. Que cuando Riesgos dice “Cliente” y Marketing dice “Cliente”, están hablando de la misma persona.

Garantiza la escalabilidad. Cuando la cocina pasa de servir 50 platos al día a servir 500, el ingeniero es el que amplía la capacidad.

Evoluciona la plataforma. ¿Un dominio necesita un tipo de transformación que la plataforma no soporta? El ingeniero la desarrolla y la añade como una capacidad nueva que todos los dominios pueden usar. Una vez. No una vez por cada dominio.

Es decir: el equipo de datos pasa de ser el cuello de botella (todos dependen de ellos para todo) a ser el habilitador (ellos crean la plataforma, los dominios crean los productos).

Y hay algo que cambia la satisfacción laboral de forma radical: es un trabajo mucho más interesante. En vez de pasarte la vida traduciendo requisitos ambiguos (que seamos sinceros, es como ser el intérprete de un juicio perpetuo donde ni la acusación ni la defensa hablan claro), ahora diseñas plataformas, resuelves problemas de escalabilidad, creas patrones reutilizables y construyes sistemas que multiplican la capacidad de toda una organización.

Para el CDO / CTO: el cambio que escala

Si tienes un equipo de 8 ingenieros de datos y hoy los 8 están picando SQL a mano para servir las 120 peticiones de la cola, tu capacidad es 8. Linealmente limitada por el tamaño del equipo.

Si esos mismos 8 ingenieros construyen y mantienen la plataforma, y los 15 dominios de negocio crean sus propios productos de datos usando esa plataforma… tu capacidad ya no depende del tamaño del equipo de datos.

Depende del número de dominios que se suben a la plataforma. Y eso escala de forma completamente diferente.

Como contaba la semana pasada: modelar manualmente una tabla fuente en Data Vault 2.0 cuesta entre 16 y 32 horas. Con una receta ejecutable, baja a 1-2 horas. Pero lo importante no es el ahorro de tiempo: es que esas 1-2 horas las puede hacer el propio usuario de negocio. Desaparece la dependencia.

El actuario no espera 3 meses en una cola. Define su receta, el sistema la ejecuta. Sin intermediarios. Sin teléfono roto. Y el equipo de datos se dedica a hacer la plataforma cada día mejor.

Hagamos los números.

Supongamos que tu empresa tiene 200 tablas fuente que necesitan modelarse. Con el modelo tradicional (Word → interpretación → SQL a mano → iteraciones → documentación): 200 tablas × 24 horas de media = 4.800 horas. Con un equipo de 8 ingenieros al 60% de capacidad (el otro 40% lo dedican a apagar fuegos, como decía Monte Carlo Data): 4.800 ÷ (8 × 0,6 × 1.700 horas/año) ≈ 7 meses. Solo para el Raw Vault (los ingredientes en crudo, organizados tal cual llegan de la fuente). Sin contar el Business Vault (la mise en place: donde se transforman en información de negocio), ni la calidad, ni las iteraciones.

Con recetas ejecutables: 200 tablas × 1,5 horas = 300 horas. Y esas horas las pueden hacer los propios analistas de los 15 dominios, en paralelo. El cuello de botella desaparece. El horizonte pasa de 7 meses a semanas.

Pero la clave no son los números de la primera carga. Es lo que pasa después. Cada nuevo patrón que el equipo de plataforma implementa, cada nueva capacidad que añaden, multiplica la autonomía de todos los dominios a la vez. Es crecimiento compuesto, no lineal.

Y hay algo más que los números no capturan: la velocidad de reacción. Cuando cae un requisito regulatorio urgente (y siempre cae), la pregunta ya no es “¿cuánto tarda IT en hacer esto?” sino “¿cuánto tarda Negocio en definir su receta?” Y esa respuesta se mide en horas, no en meses.

Un beneficio que no es obvio: el conocimiento sobrevive

Hay una consecuencia de este modelo que no se ve a primera vista pero que a largo plazo es la más valiosa de todas.

Como la receta está en lenguaje de negocio y es agnóstica de tecnología, el conocimiento de negocio sobrevive a las migraciones tecnológicas.

Pensad en cuántas veces habéis perdido conocimiento de negocio por una migración. Esas reglas que estaban hardcodeadas en un procedimiento almacenado de Oracle que nadie documentó. Esas transformaciones que solo existían en un job de Informatica que el proveedor montó hace 8 años. Ese cálculo de solvencia que estaba enterrado en la línea 847 de un script de Python que solo entendía una persona que ya no está en la empresa.

Cada migración tecnológica es empezar de cero.

No porque cambies de tecnología, sino porque el conocimiento de negocio estaba atrapado dentro de la tecnología. Mezclado con el código. Indistinguible de la implementación.

Os pongo un ejemplo concreto. En una migración de Oracle a la nube, alguien descubre un procedimiento almacenado de 2.000 líneas que calcula la provisión técnica de un producto. Nadie sabe exactamente qué hace porque la persona que lo escribió se fue hace 4 años. El código mezcla la lógica de negocio (cómo se calcula la provisión) con la lógica de infraestructura (cómo se optimiza en Oracle, cómo gestiona la memoria, cómo accede a las tablas). ¿Qué parte es negocio y qué parte es tecnología? Nadie lo sabe. Y migrar eso a Snowflake significa reescribirlo de cero, con el riesgo de perder reglas de negocio que estaban implícitas en el código.

Si la lógica hubiera estado en una receta agnóstica, la migración sería: cambiar el target de generación de Oracle a Snowflake. La receta (con la definición de la provisión, sus reglas, sus validaciones) seguiría intacta. El motor generaría el nuevo SQL para Snowflake. Sin reescribir. Sin adivinar qué hacía cada línea del procedimiento.

Cuando el conocimiento vive en la receta y la receta es agnóstica, migrar de BigQuery a Snowflake (o de dbt a otra cosa, o de un data warehouse a un lakehouse) es cambiar el horno. La receta — con todas las definiciones, reglas, mapeos e identidades que Negocio y el analista han construido a lo largo de los años — sigue ahí. Intacta. Versionada. Auditable.

Y esto conecta directamente con la Big Ball of Mud de la que hablamos en la Semana 1. ¿Por qué la deuda técnica se acumula sin que nadie la pueda limpiar? Porque el conocimiento está mezclado con el código, y tocar el código da miedo porque no sabes qué regla de negocio estás rompiendo. Cuando el conocimiento vive en la receta y el código se genera desde ella, limpiar la deuda técnica es cambiar el horno. El conocimiento queda intacto.

La receta de la abuela muere con ella. La receta ejecutable es inmortal.

Lo que viene: la despensa

Hoy hemos puesto sobre la mesa la primera pieza de la cocina: la Receta. Quién la escribe (Negocio), en qué idioma (el suyo), cómo implementa el idioma común entre dominios (el Shared Kernel), y qué cambia para IT (de artesanos a responsables de plataforma).

Pero una buena receta sin ingredientes no sirve de nada. Y los ingredientes — los datos crudos que llegan de los sistemas origen — necesitan un sitio donde almacenarse de forma ordenada, etiquetada y trazable. En una cocina profesional, ese sitio es la despensa.

La semana que viene vamos a ver cómo funciona la despensa de un data warehouse. Cómo se almacenan los datos tal cual llegan, sin tocarlos, pero organizados de forma que puedas saber exactamente de dónde vino cada ingrediente, cuándo llegó y quién lo trajo. Y por qué eso es la base de todo lo que viene después: la auditoría, el reproceso y la automatización.

Pero antes de abrir la despensa: