“La franquicia da salsas, no ingredientes crudos ni pizzas terminadas. La diferencia entre una plataforma de autoservicio real y el teatro institucional vive en cuatro decisiones operativas concretas.”
Las salsas en la mesa, falta la pizza
La entrega pasada dejé las salsas base sobre la mesa de la cocina central. Los Vault Components del Business Vault — frescura del producto v4.0, score del cliente v1.5, antigüedad del cliente v2.0 — versionados, certificados, consumibles desde cualquier sede. Y dejé el principio que sostiene que esa mesa pueda crecer sin romper lo que ya estaba ahí: Open/Closed, abierto a extensión, cerrado a modificación. Cualquiera de las 40 sedes puede colgar un Satellite nuevo del Hub Cliente sin tocar nada del resto. La cadena crece sin enterarse.
Hasta ahí el primer principio del tercer pilar.
Pero las salsas en la mesa no son una pizza. Y la pregunta que sigue es la que decide si la franquicia escala con cabeza o se enreda en sí misma a los dos años: ¿cómo combina la cocina de Ana — y la de Marlene en Chicago, y la de la sede nueva de Denver — esas salsas base con lo que es suyo de su sede?. Sin tocar las salsas. Sin esperar permiso. Sin reescribir el manual común.
Y la pregunta que decide si la plataforma es genuinamente de autoservicio o es teatro institucional vestido de transformación digital: ¿qué cuatro cosas hacen falta para que una sede pueda abrir, componer su pizza local y servir desde el primer cliente — sin caer en los dos extremos peligrosos que llevan veinte años hundiendo proyectos de datos?.
Hoy contesto las dos.
Vamos por orden.
Eje 1 — Strategy y Composition over Inheritance
¿Cómo combina la cocina de Ana las salsas base que la central distribuye con lo que es suyo de su sede? La pregunta parece tonta — “las une en una receta, pulsa el botón, sale la pizza” —, pero la mecánica subyacente es la diferencia entre una franquicia que aguanta y una que se enreda en su propio modelo de objetos dentro de un par de años.
Para verlo limpio, vámonos un momento a otro caso. Hay una sede en Denver — la ciudad de la milla, mil seiscientos nueve metros sobre el nivel del mar — y otra en Roma, a veintiún metros sobre el mar. Las dos hacen la misma napolitana clásica de la carta común. Misma masa, misma salsa San Marzano, misma mozzarella di bufala, mismo aceite de oliva. El producto que el cliente recibe es indistinguible.
Pero el horno de Denver y el horno de Roma no funcionan igual. La altitud cambia el comportamiento del calor — la cocción a mil seiscientos metros no es la cocción a veintiuno. El horno de Denver necesita treinta segundos más a la misma temperatura para lograr el mismo perfil de cocción que el de Roma. Si Denver cocina con los tiempos de Roma, la pizza sale cruda por dentro. Si Roma cocina con los tiempos de Denver, sale chamuscada por fuera. El parámetro técnico del horno es local. La receta no.
Aquí hay dos formas de gestionar esa diferencia. Y la que se elija decide si la cadena escala con cabeza o se enreda en sí misma.
En el catálogo del diseño de software, la primera forma se llama herencia: la sede Denver hereda de la receta base “napolitana clásica” y sobrescribe el método “calcular tiempo de horno” para meter el ajuste por altitud. Si una sede en Aspen quiere sus tiempos, hereda otra vez. Si una en Cuenca quiere los suyos, hereda otra vez. Cada variante es una clase nueva en una jerarquía que crece y se enreda con cada sede.
Esto, dicho así, parece razonable. Lo es durante seis meses. A los dos años, cuando hay 40 sedes con sus jerarquías propias, cada una con su árbol de herencia, y la central decide cambiar la salsa de tomate de v3 a v4 — porque el proveedor cambió o la regulación cambió —, los efectos en cascada por las jerarquías son imprevisibles. Una sede deja de funcionar porque dependía de un comportamiento accidental de la versión vieja del padre. Otra sede empieza a comportarse raro porque heredaba de un padre que heredaba de un abuelo que tenía una rama muerta. Es el infierno clásico de la herencia profunda.
El segundo enfoque, el que la Banda de los Cuatro (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) formalizó en Design Patterns (1994), es lo opuesto. Se llama composición sobre herencia y dice así, en la formulación canónica del libro:
Favorece la composición de objetos sobre la herencia de clases.
En cristiano: en vez de construir una jerarquía rígida con subclases que sobrescriben comportamiento, se inyecta el comportamiento desde fuera, como una pieza intercambiable que cumple un contrato. La pizza no hereda — compone. La sede declara qué Vault Components va a usar y declara qué pieza local añade encima. La pieza local es una estrategia — eso le da nombre al patrón Strategy del mismo libro de la Banda de los Cuatro — que cumple un contrato definido y se inyecta sin tocar nada del código común.
Aplicado al caso del horno: la sede de Denver declara qué Vault Components consume (los mismos que cualquier otra sede), y declara su Strategy local — una función propia, viva en su sede, que toma la altitud y devuelve los segundos de ajuste sobre el tiempo base de cocción. “A 1.609 metros, sumar 30 segundos al tiempo base con la temperatura nominal.” La sede de Roma hace lo equivalente con su altitud: “a 21 metros, sumar 0 segundos”. Distinta Strategy, mismo contrato. La composición es declarativa: cada sede dice qué hace, no cómo lo hace.
El sistema central no necesita saber nada del horno de Denver ni del de Roma. Cada sede declara su composición y el sistema la ejecuta. Si la próxima semana una sede en Aspen — tres mil metros sobre el mar — abre, declara su Strategy y opera. Las tres coexisten, las tres consumen las mismas salsas base, y ninguna toca el código de las otras.
El truco operativo del Strategy es que la pieza nueva no toca código existente. Se añade. Se prueba. Se publica. Y cuando una sede vecina quiera componer su variante — su altitud, su humedad, su corriente de aire —, mira la de Denver como ejemplo, pero no la hereda — compone la suya. Igual de simple. Igual de aislada.
Eso es Composition over Inheritance aplicado al producto local sobre kernel común. Y es el segundo de los dos principios de software que hacen que una plataforma de autoservicio sea operable. El del artículo anterior — Open/Closed — disciplinaba qué se modifica del manual común: nada. Este — Composition over Inheritance — disciplina cómo cada sede ajusta el manual a sus condiciones físicas: componiendo, no heredando.
🍕 Una nota antes de seguir: el ajuste del horno por altitud es un parámetro técnico — la altitud es física, la sede no la elige. Pero la sede también puede tomar decisiones de carta — qué pizzas locales añade a su menú, qué ingredientes del barrio incorpora, qué clientes cultiva. Esas decisiones son cualitativamente distintas y son lo que cierra el bloque en las próximas entregas. La diferencia entre “ajustar el horno por altitud” y “decidir qué pizza local sirve esta sede” es la diferencia entre el tercer pilar de Data Mesh (que cierra hoy) y el cuarto (que cierra el bloque). Self-serve da las salsas; Data as a Product decide qué se sirve. Hoy estamos en el plano de las salsas. En los próximos artículos entraremos en el del menú.
Eje 2 — Plataforma de autoservicio sin caer en los dos extremos peligrosos
Llegamos al cierre del tercer pilar de Data Mesh — Self-serve Platform — y aquí toca decir algo claro porque es el pilar donde casi todas las implementaciones reales que veo en organizaciones grandes viven en uno de los dos extremos peligrosos.
Extremo 1 — Distribuir solo ingredientes crudos
Una manera de formular el primer riesgo, en clave del catálogo Data Vault: self-service sin guardarraíles destruye la confianza. Es lo que ocurre cuando una plataforma de datos se reduce a “aquí tienes BigQuery, aquí tienes los datasets en bruto, apáñate.” La central pone la infraestructura, los accesos, los credenciales. Lo que cada dominio haga con eso es problema suyo.
Las sedes acaban reescribiendo el cálculo de frescura del producto cada una a su manera. Una en Boston usa una fórmula. Otra en Chicago usa otra ligeramente distinta. Una tercera en Roma se inventa una variante propia porque “aquí los productos son distintos”. La cadena se rompe en silos. El gobierno se diluye porque cada dominio es soberano de su cálculo. Y cuando alguien pregunta a nivel cadena “¿cuál es la frescura media del producto en toda la red?”, la respuesta no existe porque cada dominio mide cosas distintas con el mismo nombre. La autonomía local se ha convertido en anarquía.
Es exactamente lo que veinte años de proyectos Data Vault entrando en producción sin disciplina han producido en sectores reales. Y es la razón por la que Dan Linstedt dedica capítulos enteros del catálogo DV 2.0 a las salsas base, los Vault Components y el Business Vault — para que la palabra “self-service” no se convierta en sinónimo de “que cada dominio se invente lo común”.
Extremo 2 — Distribuir platos terminados
Y desde la arquitectura aplicada, otra formulación del mismo límite — esta vez por el otro lado: una plataforma de datos entrega capacidades, no infraestructura ni productos terminados. Lo importante no es el SaaS con cinco terabytes ni los reportes prefabricados que llegan a las nueve de la mañana al correo del director. Lo importante son las capacidades — operaciones primitivas, reutilizables, componibles — que el dominio compone para construir su producto local.
Quien se queda en el extremo opuesto al primero pasa a “la central decide qué cocináis. Os pasamos cuatro reportes prefabricados, no os hagáis los listos.” Aquí la cadena vuelve a ser cookie-cutter, todas las sedes con la misma carta, ningún margen para el barrio. La velocidad operativa muere. Las sedes esperan tickets. La pizza con un ingrediente local del barrio no existe — porque no estaba en el catálogo central, la central no la prioriza, y el equipo de plataforma tiene cola para seis meses. La autonomía no existe.
Esto cierra el otro lado del mismo límite. Y es donde acaban casi todos los Data Lake corporativos clásicos: con un equipo central que controla todo lo que se sirve, una cola de tickets de seis meses, y dominios que dejan de pedir nada porque ya saben que no llega.
La franquicia bien hecha como sweet spot entre los dos extremos
Las dos formulaciones dibujan los dos lados del mismo límite. La una desde el catálogo DV 2.0, la otra desde la arquitectura aplicada. Y lo que esta serie viene construyendo desde el inicio de este segundo bloque — la franquicia, las salsas base, los Vault Components, la composición declarativa — es la posición operativa que se sitúa en el medio.
Distribuir salsas base — Vault Components versionados con su contrato — y dejar que cada sede componga su carta. Eso es la plataforma de autoservicio que respeta a la vez los dos límites: gobierno fuerte sobre lo que toda la cadena reusa (las salsas), autonomía completa sobre lo que cada sede compone (la pizza local). Y por eso resuelve, sin tener que negociarlo entre las dos voces, lo que ambas formulaciones identifican como riesgo desde sus respectivos lados.
¿Qué hace falta para que esa plataforma funcione genuinamente? Cuatro elementos. Si falta uno, vuelves al primer extremo o al segundo — no hay punto medio.
Catálogo ejecutable de Vault Components con su contrato explícito. No vale “aquí hay cálculos en la wiki”. El catálogo es ejecutable — cada Vault Component publica su contrato (entrada, salida, garantías, versión) en un sitio donde el sistema lo puede leer. La sede que va a componer su receta puede ver, antes de elegir, qué Vault Components hay disponibles y qué garantizan. Sin reuniones, sin emails, sin un arquitecto en medio.
Mecanismo de composición declarativo. La sede no escribe SQL para combinar las salsas base con su Strategy local. Declara la composición — “esta receta usa estos tres Vault Components, y mi Strategy local hace esto”. El sistema interpreta la declaración y la ejecuta. La sede no toca código común; el código común es lo que interpreta su declaración.
Trazabilidad heredada. Cuando una sede compone su receta usando los Vault Components v3.2, v2.1 y v4.0, la consulta resultante hereda la trazabilidad de los tres. Si mañana el Vault Component “frescura del producto” sube a v4.1, la sede lo sabe — porque su composición dice “uso v4.0” y el sistema le avisa de que hay versión nueva. Si nunca migra, sigue usando v4.0 con su sello de validez de aquella época. Si decide migrar, lo hace explícitamente. Las versiones no se imponen — se ofrecen. Y cuando un auditor pregunta “¿qué versión de la frescura usaba esa pizza el 14 de marzo?”, la respuesta está pegada al modelo, no en logs.
Certificación asimétrica — del Vault Component nuevo, no de cada composición local. Aquí está el matiz que decide si la plataforma es real o teatro. La composición local de la sede no necesita aprobación caso por caso. Ana abre su sede y empieza a componer napolitanas; la sede de Denver ajusta su horno por altitud; la de Roma usa los tiempos del nivel del mar. Ninguna pide permiso. Pero el Vault Component nuevo sí pasa por certificación antes de entrar al catálogo común — porque ese sí es código que toda la cadena va a consumir, ese sí es kernel, ese sí merece firma.
La asimetría es deliberada y es el corazón del modelo: gobierno fuerte sobre las salsas base (cualquier cosa que toda la cadena va a usar igual), autonomía completa sobre la composición local (cualquier cosa que solo afecta a una sede). Esa asimetría es lo que evita que la autonomía local se convierta en anarquía y, simultáneamente, lo que evita que el gobierno común se convierta en cuello de botella. Es la respuesta concreta a las dos formulaciones del límite que abrieron este eje: a la del primer extremo (los guardarraíles existen — están en la certificación del kernel común) y a la del segundo (lo que se entrega son capacidades — no infra, no productos).
“Una plataforma de autoservicio operable no es una plataforma sin gobierno — es una plataforma con gobierno asimétrico: estricto sobre lo que toda la cadena consume, ausente sobre lo que cada sede compone.”
Cuando estos cuatro elementos están en su sitio, la plataforma es genuinamente de autoservicio. Ana abre la sede a las siete y a las ocho menos cuarto sirve. La sede de Denver compone con su altitud. La de Roma con la suya. El equipo central mantiene las salsas base. Y la cadena entera sigue hablando el mismo idioma porque el kernel común se respeta sin discutirlo.
Y eso cierra el tercer pilar de Data Mesh. La Self-serve Platform que Zhamak Dehghani definió como uno de los cuatro principios fundacionales del modelo no es una promesa de catálogo de servicios — es exactamente esto: una sede que se sirve sola de las salsas base y compone su pizza sin esperar a nadie.
“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.”
Lo que viene
El tercer pilar — Self-serve Platform — queda cerrado aquí. Las salsas están en la mesa y cada sede compone su pizza sin pedir permiso.
Pero queda uno: el plato. Lo que llega al comensal con su carta, su precio y su garantía — no la salsa, no el horno, no el contrato común.
Y hay una decisión que ni las salsas base ni la composición local cubren. En la sede de Chicago, Marlene lleva tres semanas con una caja de honey gold encima del mostrador, dándole vueltas a una pizza que no está en la carta de nadie. El catálogo central no tiene ese ingrediente. La plataforma de autoservicio no decide por ella. Ese sabor del barrio, esa carta que solo su sede firma — esa decisión es suya. Y es, al final, lo que el cliente se come.
Hasta la próxima entrega.