“Una franquicia que escala distribuye salsas base. La que no escala distribuye recetas o ingredientes crudos. El equilibrio no es una opción — es la única posición operable.”
Lunes a las siete y cuarenta y dos
Es lunes por la mañana en una sede de Objectville Pizza Store que abre por primera vez. La operadora — Ana, contratada hace tres semanas, antes camarera del local de la esquina — llega a las siete con un café y una libreta. Mira la cocina vacía. Mira el horno apagado. Y enciende.
A las siete y cuarenta y dos, el horno está a temperatura. La salsa de tomate San Marzano está descongelada en su contenedor pre-medido. La cobertura de queso en gradiente espera en su recipiente etiquetado. La regla de frescura del producto, calculada esta misma madrugada con la fórmula validada por la cadena entera, está pegada al frontal del horno como un pequeño letrero de papel: “frescura óptima entre 5 y 7 minutos a 320°C — alertar si lote supera 48 horas desde elaboración”.
A las siete y cuarenta y cinco, Ana saca del horno la primera pizza del local: una napolitana clásica con la salsa San Marzano por encima, mozzarella di bufala, hojas de albahaca, un hilo de aceite. La misma pizza que sirven en Chicago, en Roma, en Cádiz. La misma pizza — porque la salsa es la misma, el queso es el mismo, la regla de frescura es la misma. La cadena reconocible.
Lo importante de esa primera pizza no es la pizza. Es lo que no ha tenido que hacer Ana para sacarla.
No ha calibrado el horno desde cero. No ha definido el contrato del proveedor de queso. No ha aprendido a cocinar la salsa San Marzano partiendo del tomate. No ha contratado a un especialista que entienda el modelo común de la cadena. No ha negociado con compras central qué versión de la mozzarella le toca. No ha escrito reglas de calidad propias. No ha integrado nada con el aparato central a mano. Las cosas estaban hechas cuando ella llegó. El horno se encendió, la salsa estaba pre-medida, la regla de frescura estaba pegada al frontal. Su trabajo el primer día fue servir pizza, no montar la fábrica.
A las ocho menos cuarto, entra el primer cliente. Un señor mayor, jubilado, conoce las pizzas de Objectville porque suele ir al local de la avenida grande cuando va a ver a su hija. Pide una napolitana. La come. Paga. Antes de salir, dice algo a Ana que lo dice todo:
— Esta tiene el mismo gusto que la del local de mi hija. Está bien que esté aquí también.
Eso es la cadena reconocible. La pizza que el cliente reconoce de inmediato — la masa, la temperatura, el corte, la firma del producto. Y a la vez, es esta sede. Está aquí, no en el otro local. Ana es Ana, no la operadora del otro sitio. La sede tiene su luz, su barrio, sus clientes que llegarán y formarán una historia propia. Inconfundible sin perder alma. Las dos cosas a la vez.
Lo que acaba de pasar es el corazón del tercer pilar de Data Mesh — la plataforma de autoservicio. Una sede ha abierto sin tener que reconstruir la fábrica. Ha consumido, desde el primer minuto, lo que la cadena entera ya había construido. Y ha podido empezar a servir desde el primer cliente, en lugar de pasar seis meses montando un proyecto.
¿Cómo es eso posible? Esa es la pregunta de hoy. Y va a llevarme por un principio de ingeniería que ya tiene casi cuarenta años, una calibración que ese principio necesita cuando lo aplicas a datos a gran volumen, y la respuesta operativa que el ecosistema lleva dos décadas usando para resolverlo. La parte de cómo cada sede compone su pizza local sobre estas salsas base — Strategy, Composition over Inheritance, los dos extremos peligrosos a evitar — la cuento el martes que viene. Hoy entendemos las salsas.
Eje 1 — Open/Closed Principle: la propiedad que hace que la cadena no se rompa cuando crece
Hay un principio de diseño de software que Bertrand Meyer formuló en Object-Oriented Software Construction (1988) y que cualquiera que haya pisado una arquitectura de software seria conoce de memoria. Se enuncia así:
Abierto a extensión, cerrado a modificación.
En cristiano: cuando llega una necesidad nueva — un nuevo tipo de cálculo, una nueva regla local, una nueva variante de producto, un nuevo dominio que se incorpora a la cadena —, el sistema debería poder absorberla añadiendo piezas nuevas, no tocando piezas que ya estaban funcionando. La pieza nueva se diseña, se prueba, se publica. La pieza vieja sigue donde estaba, igual que antes, sin un solo bit alterado. Lo que ya funcionaba sigue funcionando. Lo que es nuevo aporta.
Aplicado a una franquicia, el Open/Closed dice: el manual común — la receta de la salsa de tomate, el contrato de mozzarella di bufala, el código del cliente fidelizado — no se toca cada vez que abre una sede nueva. La sede de Ana abre, consume el manual, sirve. La cadena no se ha movido para acogerla. Las otras 39 sedes no se han enterado. Y aun así, la sede ha podido empezar a operar.
Trasladado al modelo de datos que hemos venido construyendo, el Open/Closed se materializa con una propiedad estructural muy concreta del aparato:
- El catálogo de Hubs canónicos está cerrado a modificación. Una vez la franquicia ha decidido que un cliente se identifica por NIF/CIF, ese Hub no se toca — porque lo tocan 40 dominios en paralelo, y romperlo rompería la cadena entera.
- Pero está abierto a extensión. Si un dominio nuevo entra a la cadena — Marketing añade datos de fidelización, Riesgos añade el scoring de crédito, Digital añade el comportamiento web del cliente —, se cuelga un Satellite nuevo del Hub Cliente que ya estaba. Sin tocar los Satellites del resto. Sin tocar el Hub. Sin reuniones de coordinación.
Esto es importante porque es la propiedad operativa más valiosa del modelo. Cuando un dominio nuevo necesita entrar al almacén, entra colgando un Satellite del Hub que ya estaba ahí. El Satellite nuevo es código nuevo. Tiene sus pruebas, sus reglas de calidad, su contrato de carga. Pero no rompe nada de lo que ya estaba. Las otras 39 cargas que ya estaban funcionando siguen funcionando exactamente igual: leen los Hubs igual, generan sus Satellites igual, pasan sus reglas de calidad igual. La cadena ha crecido sin enterarse.
Esa es la propiedad. 40 dominios pueden estar añadiendo cosas al modelo cada uno por su lado, sin reuniones, sin coordinación, sin pisarse entre ellos. Eso es Open/Closed aplicado al dato. Es lo que hace posible la franquicia operable: una cadena que crece sin que la pieza nueva tenga que pedir permiso a la pieza vieja.
Ahora viene la calibración. El principio funciona — y funciona mejor cuanto mejor disciplinada esté la extensión. Eso merece un eje aparte, porque es donde mucha gente que llega de software puro al mundo del dato pierde el equilibrio en los primeros seis meses de producción.
Eje 2 — El sweet spot: Open/Closed en software vs en data a gran volumen
El Open/Closed es un principio sólido. Pero la práctica de extender en software puro y la práctica de extender sobre tablas de datos a gran volumen no es exactamente la misma operación. Y entender por qué es la diferencia entre una franquicia de datos que escala con cabeza y una franquicia paralizada por su propia microsegmentación.
En software puro, cuando aplicas Open/Closed, el coste de añadir una clase nueva es básicamente cero en tiempo de ejecución. La clase nueva se compila, se carga en memoria, se invoca cuando toca. La clase vieja sigue donde estaba. El sistema crece sin pagar coste de lectura en cada operación.
En data, hay un matiz operativo. Cada vez que cuelgas un Satellite nuevo del Hub Cliente, ese Satellite es un JOIN potencial cuando alguien quiera reconstruir la vista del cliente. Cada vez que añades una regla de calidad nueva, es una operación más en cada carga. Cada vez que subdivides un dominio en granularidades más finas — un Satellite por equipo, un Satellite por proyecto, un Satellite por capricho —, estás añadiendo una capa más de read-time stitching cuando alguien quiera consultar la entidad entera.
Si extiendes sin disciplina — un Satellite nuevo cada vez que un dominio quiere añadir tres atributos, una subdivisión más cada vez que un equipo cambia de scope —, acabas con un modelo donde reconstruir la posición consolidada de un cliente requiere unir 47 tablas, cada una con su histórico bi-temporal, cada una con su versionado, cada una con su rango de validez. Open/Closed se conserva como principio, pero la lectura se vuelve incómoda: añadir es libre, pero leer cuesta. Y la microsegmentación que parecía respetar la autonomía local empieza a entorpecer las consultas que el negocio realmente hace.
Esto no es teoría. Es lo que pasa todas las semanas en proyectos reales de Data Vault que se montan sin disciplina. “Si Hub-Satellite es bueno, más Satellites debe ser mejor.” Y al cabo de dos años hay un modelo de tres mil tablas, donde cada consulta toca quince y los analistas vuelven a pedir que les exporten un CSV “porque consultar el modelo es lento”. El gobierno se ha mantenido. El rendimiento ha quedado tocado.
El sweet spot existe, y se disciplina. No se inventa. Y la disciplina son dos reglas operativas de modelado — las que viven en el mismo plano que el Open/Closed — que separan una franquicia viva de un modelo paralizado por su propia granularidad.
Regla de modelado A — Agrupar Satellites por cadencia de cambio, no por dominio que los aporta.
Atributos del cliente que cambian cada día — geolocalización, scoring crediticio, segmento comercial — viven juntos en un Satellite. Atributos que cambian una vez al año — fecha de nacimiento, identificador fiscal, régimen jurídico — viven en otro. Atributos que cambian una vez en la vida — fecha de alta inicial, primer producto contratado — viven en un tercero. Mezclar atributos con cadencias distintas en el mismo Satellite te obliga a leer toda la historia de los lentos cada vez que consultas datos del rápido. La factura del rendimiento la paga el sistema entero, en cada consulta, todos los días.
Esta regla no es nuestra — es vocabulario común en cualquier libro serio de Data Vault. Linstedt insiste mucho en ella. La razón por la que cuesta aplicarla es que choca de frente con la intuición “un Satellite por equipo que aporta datos”, que es la organización fácil pero la peor desde el punto de vista de coste de lectura.
Regla de modelado B — Limitar la profundidad del read-time stitching.
Si reconstruir la vista de una entidad — el cliente, la póliza, el contrato — requiere unir N Satellites en runtime cada vez que un analista consulta, hay un umbral en el que el modelo empieza a pedir una capa intermedia que cristalice el resultado del cálculo común que la cadena entera reusa. Esa capa intermedia tiene un nombre técnico que va a aparecer en el siguiente eje, y es la respuesta operativa exacta a este problema.
¿Cuánto es N? Depende del motor (BigQuery aguanta más que Snowflake, Snowflake más que un Postgres on-prem) y del volumen. Pero hay una regla de bolsillo razonable: si para la consulta más frecuente del negocio hay que tocar más de 5-7 Satellites del mismo Hub para reconstruir un cálculo que toda la cadena necesita igual, materializa. No esperes a que el problema reviente.
Hasta aquí, dos reglas de modelado. Y ahora viene una distinción importante, porque hay una tercera dimensión que cualquier ingeniero senior que haya tocado Data Vault en producción sabe de memoria — pero que no es modelado.
🔑 Lo que viene la semana que viene — y por qué no es modelado
Hay una familia entera de piezas en el catálogo Data Vault 2.0 que existe para acelerar el servir el dato cuando el coste de lectura empieza a apretar. PIT tables (Point-in-Time) que precomputan estados as-of para que las consultas históricas no recalculen rangos de validez en cada llamada. Bridge tables que precomputan caminos frecuentes entre Hubs vía múltiples Links para evitar JOINs profundos. Materializaciones selectivas de vistas que el negocio consume a diario. Todo esto existe desde hace décadas en el catálogo Linstedt y todo el ecosistema serio (Scalefree, AutomateDV, VaultSpeed, dbt vault) las industrializa.
Pero — y esto es lo importante — estas piezas no llevan lógica de negocio. Son aceleradores puros: precomputan caminos o estados para que la consulta sea barata. No deciden nada que el negocio tuviera que decidir. No son modelado, son emplatado físico: cómo se sirve al consumidor lo que ya está modelado.
Por eso esta familia entera no entra hoy ni la semana que viene. La doctrina del Open/Closed cierra hoy con dos reglas de modelado. La familia del rendimiento puro — PIT, Bridge, materializaciones — la cuento más adelante, cuando lleguemos al emplatado. Cuando entendéis que el plato sale al pase, no se ensambla en la cocina, esa familia entera deja de ser misteriosa.
Y eso conecta con la respuesta operativa de modelado que el ecosistema DV 2.0 lleva veinte años usando. Tiene nombre, tiene capa, y tiene una unidad operativa que vamos a ver ahora.
Eje 3 — Salsas base: Vault Components y Business Vault (la capa que lleva lógica)
Hasta ahora — durante S7, S8a, S8b y S9 — hemos hablado de una sola capa del almacén: el Raw Vault. La capa cruda. La que refleja lo que llegó del origen, sin transformación. Hubs canónicos, Satellites con sus atributos versionados, Links que conectan entidades. Insert-only, fidelidad total al dato bruto. Esa capa es la que hace posible la trazabilidad — “reproduce el cálculo del 14 de marzo con la regla vigente ese día” — porque mantiene el dato exactamente como llegó.
Pero si todo lo que tienes es Raw Vault, cada vez que el negocio quiere consultar “¿cuál es la antigüedad del cliente?” o “¿cuál es la frescura del producto?” o “¿cuál es el score consolidado?”, alguien tiene que recomputar la fórmula desde los datos brutos. Eso, en el mundo de software puro, sería trivial. En el mundo del dato a gran volumen, multiplicado por miles de consultas al día y por cientos de fórmulas distintas, es un coste operativo que el sistema acaba pagando en lentitud o en duplicación de cálculos divergentes entre dominios.
La respuesta operativa que Dan Linstedt introdujo en el catálogo de Data Vault 2.0 hace ya tiempo, y que todo el ecosistema serio aplica desde hace años, es una capa nueva que vive encima del Raw Vault: el Business Vault.
El Business Vault no es una invención reciente, ni nuestra. Es vocabulario canónico del ecosistema DV 2.0 — lo describen Linstedt y los Scalefree, lo industrializan AutomateDV y VaultSpeed y dbt vault, está en cualquier libro serio del marco. Lo que voy a contar es cómo encaja en la metáfora de la franquicia y por qué es la respuesta exacta al sweet spot del eje anterior — en el plano del modelado.
El Business Vault contiene cálculos comunes que la cadena entera necesita usar igual, y que llevan lógica de negocio dentro. “Antigüedad del cliente”: calculada como diferencia entre primera transacción y hoy, normalizada a años — la fórmula la valida la central, las 40 sedes la consumen igual. “Frescura del producto”: calculada con la fórmula que validó el equipo de calidad alimentaria — incluye temperatura del transporte, días desde la elaboración, lote de origen. “Score consolidado del cliente”: composición de tres métricas (fidelización, riesgo crediticio, scoring de comportamiento) con sus pesos validados por dirección.
Esos cálculos viven una sola vez en el Business Vault. Versionados — cada cambio queda con su sello temporal. Probados — pasan tests automatizados antes de publicarse. Certificados — alguien con responsabilidad pone su firma. Y cada sede los consume sin reescribirlos, inyectándolos en sus consultas locales como si fueran un ingrediente más de su despensa.
Eso son las salsas base. Listas para combinar.
La unidad operativa del Business Vault es lo que el ecosistema llama Vault Component — una pieza encapsulada con un contrato muy preciso. Lleva su contrato de entrada (qué Hubs y Satellites necesita), su contrato de salida (qué columnas y semántica produce), las garantías que cumple, su versión, y su trazabilidad. (En el capítulo del libro está el detalle pleno con los cinco elementos enumerados, los ejemplos concretos del contrato y la mecánica del despliegue versionado.)
Cuando la sede de Ana abre y empieza a servir su primera napolitana, declara qué Vault Components va a usar (frescura del producto, score del cliente, antigüedad del cliente) y los compone con la receta común de la cadena. La sede no recomputa la frescura — la consume. No recomputa el score — lo consume. No reescribe la regla de antigüedad — la inyecta tal cual.
La frontera nítida — Vault Component vs PIT/Bridge
Aquí toca decir algo que separa una doctrina seria de una doctrina confusa. Una salsa base — un Vault Component — y una pieza de rendimiento — una PIT table o una Bridge table — no son lo mismo, aunque ambas vivan físicamente como tablas materializadas y aunque ambas sean canónicas en Data Vault 2.0. La diferencia es operativa y es nítida:
La diferencia es operativa y es nítida. Un Vault Component (Business Vault) lleva lógica de negocio: decide la fórmula de frescura, los pesos del score, la regla de antigüedad — y por eso es modelado, y vive aquí, hoy. Una PIT table (Point-in-Time) no decide nada: precomputa estados as-of de un Hub para que las consultas históricas no recalculen rangos de validez. Una Bridge table tampoco decide nada: precomputa el camino entre Hubs vía Links múltiples. Y una materialización selectiva tampoco: cristaliza una vista frecuente para abaratar la consulta. Las tres son emplatado — rendimiento puro, sin lógica — y entran más adelante.
La línea es esta: si la pieza decide algo del negocio, vive en el Business Vault. Si solo acelera, vive en la capa de servir. Esta frontera no es de Linstedt — en la taxonomía estándar de DV 2.0 las PIT y las Bridge suelen agruparse dentro del Business Vault. La trazo a propósito más nítida: lo que lleva lógica es modelado; lo que solo acelera es emplatado. Esa línea es la que mantiene el gobierno limpio.
¿Por qué importa esta distinción? Porque cuando una organización confunde las dos capas — y muchas lo hacen — empieza a meter lógica de negocio dentro de PIT tables (“ya que estoy materializando, le añado este cálculo de paso”) y eso es exactamente la receta del modelo que se vuelve ingobernable. Una PIT table con lógica es un Vault Component disfrazado sin la certificación, sin la versión explícita, sin la trazabilidad. La auditoría no la encuentra. El cambio se cuela. La cadena empieza a divergir sin que nadie lo note.
La regla doctrinal: cualquier pieza que tome decisiones de negocio vive en el Business Vault con su contrato Vault Component completo. Cualquier pieza que solo acelere vive en la capa de servir, sin lógica, transparente, reconstruible desde el Raw Vault y el Business Vault sin pérdida de información. Esa frontera es lo que permite que el gobierno se mantenga aunque el aparato físico tenga decenas de aceleradores.
El Business Vault tiene su propio sweet spot
Las salsas base resuelven el problema concreto que dejó abierto el eje anterior: cuando reconstruir un cálculo común exige unir demasiados Satellites en runtime, el Vault Component lo cristaliza una sola vez con su lógica certificada, y la cadena entera lo consume en vez de recomputarlo. Esa es exactamente la capa intermedia que prometí en la Regla B del sweet spot.
Pero ojo, porque esta capa tiene su propia disciplina — y es la misma lógica del Open/Closed subida un piso. Si cedes a la tentación de convertir cada cálculo en su propio Vault Component, reintroduces el problema que querías resolver: los componentes comparten Satellites y cálculos subyacentes, y al fragmentarlo todo en funciones diminutas, esas lecturas compartidas se disparan — cada micro-componente vuelve a leer y a unir lo mismo. Has movido el stitching un nivel hacia arriba, no lo has eliminado.
Por eso la disciplina del Business Vault son dos preguntas:
- ¿Cuándo creo un Vault Component nuevo? Solo cuando el cálculo es algo que la cadena entera reusa igual — la antigüedad, la frescura, el score consolidado. Un cálculo de una sola sede, o una variante local, no es una salsa base. El billete de entrada al Business Vault es el reuso, no la elegancia: si lo va a consumir una sola cocina, no es salsa base, es un plato de esa cocina.
- ¿Tiene un solo propósito? Cada Vault Component hace una cosa. En el momento en que un componente empieza a tener más de un propósito — calcula la frescura y de paso ajusta el score —, es la señal de que has mezclado dos salsas en el mismo bote. Sepáralo. Un componente con dos propósitos no se puede versionar, ni certificar, ni reusar sin arrastrar lo que no querías.
El Business Vault no es el cálculo bonito que algún arquitecto consideró elegante. Es la materialización disciplinada — con lógica, con firma, con versión — de lo que la cadena necesita reusar igual. Eso convierte el Open/Closed del eje 1 en algo operable a escala: las extensiones de cálculo común, en lugar de dispersarse por 40 sedes que cada una recomputa lo suyo, se cristalizan una sola vez en una capa intermedia con su contrato — sin caer en la microsegmentación de componentes que reintroduce el coste de lectura por la puerta de atrás.
La capa de servir — PIT, Bridge, materializaciones — se monta encima de las dos (Raw + Business) cuando hace falta, pero no toma decisiones. Es transparente. Y eso lo veremos en su momento.
Lo que viene
Las salsas base ya están en la cocina. Falta cómo las combina una sede local sin romper el kernel — Denver con su altitud, Roma con la suya.
El martes que viene: Strategy, composición sobre herencia, y los cuatro elementos que separan una plataforma real del teatro.
Y una gerente en Chicago con una caja de honey gold que lleva tres semanas dándole vueltas.
Hasta entonces.