Una empresa debería tratar como infraestructura pública, antes de multiplicar aplicaciones y agentes, los servicios cuya duplicación hace daño, empezando por la identidad, la auditoría, la observabilidad, los secretos y las notificaciones. Cada sistema que llega antes que ellos trae su propia versión. Ese orden es el tercer principio de la Urbanización del Mundo Digital (DWU), infraestructura antes que densidad, y en la serie Urbanización digital viene después de zonificar la empresa por capacidades de negocio. Aquel post trazó los distritos (los dominios de capacidades de negocio, cada uno con su dueño), y este trata lo que corre por debajo de todos ellos.
Northstar Consumer Group, el fabricante ficticio que me sirve de ejemplo en esta serie, tiene tres servicios que envían notificaciones, y ninguno sabe que existen los otros dos.
Tres servicios que hacen lo mismo
Northstar opera con cinco entidades legales en cinco países de una misma región. Sus equipos locales entregan rápido, y esa velocidad dejó tres implementaciones de notificaciones. Una vive en el e-commerce y avisa a los clientes del estado de sus pedidos. Otra está en la plataforma de fuerza laboral y escribe a los empleados. La tercera la construyó el equipo de la aplicación de uno de los países, al que llamaré país C, para los mensajes a sus clientes.
Cada una tiene sus plantillas, su lógica de reintentos, su forma de registrar las bajas y su propia auditoría.
Ninguna de esas decisiones fue mala en su momento. El equipo del e-commerce necesitaba confirmar pedidos y no podía esperar un servicio que no existía; el del país C tenía una fecha de lanzamiento comprometida. Cada edificio (una aplicación, producto digital, servicio o modelo con propietario y propósito) resolvió su necesidad con lo que tenía a mano.
El costo aparece cuando algo cambia fuera de los edificios. Supongamos que el regulador del país C modifica la regla de consentimiento para mensajes comerciales y exige demostrar, para cada envío, que el destinatario no había pedido la baja. En Northstar ese cambio tiene tres dueños con tres backlogs y tres calendarios. El equipo del e-commerce lo implementa según su lectura de la regla. El del país C lo implementa con otra lectura. El de fuerza laboral tiene que decidir primero si la regla le aplica, y no tiene a quién preguntar, porque ningún equipo es dueño de «cómo notifica Northstar».
Las bajas tampoco se cruzan. Un cliente que se da de baja en el e-commerce sigue recibiendo mensajes de la aplicación del país C, porque cada implementación guarda su propia lista. Y cuando un auditor pregunta algo tan simple como «¿qué mensajes recibió esta persona después de pedir que no le escribieran?», la respuesta sale de tres sistemas, con tres formatos de traza, conciliados a mano por alguien que no diseñó ninguno.
La ineficiencia de construir tres veces lo mismo se ve en el presupuesto. El riesgo sistémico se ve más tarde, el día en que la empresa necesita comportarse de forma consistente frente a una misma persona, a un mismo regulador o a un mismo incidente y descubre que no tiene cómo.
Qué cuenta como infraestructura pública
El marco llama infraestructura pública de un mundo digital empresarial al conjunto de servicios cuya duplicación crea ineficiencia o riesgo sistémico. Su lista incluye identidad y gestión de acceso, trazas de auditoría, observabilidad, gestión de secretos, notificaciones, sistemas de UI compartidos, plataformas de desarrollo, catálogos y motores de políticas. El diagrama compara a Northstar sin esa capa y con ella.
El criterio me resulta más útil que la lista. Un servicio pertenece a la infraestructura pública cuando tener varias versiones de él hace daño, porque se paga varias veces o porque las versiones divergen justo donde la empresa necesita un solo comportamiento. Con ese criterio algunas candidatas obvias quedan fuera. Un motor de precios lo consultan muchos edificios, y aun así, a mi juicio, pertenece al distrito Comercial; si hay dos, el daño es semántico y se resuelve con propiedad de dominio y definiciones compartidas, que son asunto del distrito y de sus datos.
Lo que el principio pide es acceso estandarizado a capacidades confiables, y eso no exige centralización absoluta. Para un ejecutivo se traduce en la obligación de decidir qué capacidades son comunes, cuáles federadas y cuáles localmente autónomas.
Por qué el orden importa
La formulación completa pide que la identidad, la observabilidad, la seguridad y las capacidades de entrega compartidas maduren antes de que proliferen sin control las aplicaciones y los agentes, y la palabra que pesa es «antes». Una infraestructura que llega tarde compite con lo que ya está incrustado. La literatura sobre infraestructuras digitales las describe como relacionales, embebidas en prácticas, dependientes de su trayectoria y difíciles de rediseñar desde cero (Star y Ruhleder, 1996; Hanseth y Lyytinen, 2010; Tilson et al., 2010). Las tres implementaciones de Northstar ya tienen integraciones y hábitos operativos alrededor. Retirarlas es renovación urbana (modernizar lo que está en uso sin detener la operación), con su propio costo y su propio riesgo, un trabajo que no existiría si el servicio común hubiera llegado antes que el primer equipo que lo necesitó.
La literatura sobre opciones y deuda digital apunta en la misma dirección. Los servicios estandarizados aceleran el desarrollo y crean posibilidades futuras, mientras que los componentes duplicados, las integraciones acopladas y las excepciones no gestionadas restringen el cambio (Ramasubbu y Kemerer, 2016; Rolland et al., 2018). En términos urbanos, la infraestructura crea opciones de desarrollo y la densidad no planificada desborda los servicios y estrecha los caminos futuros.
Los agentes vuelven urgente el orden. Northstar tiene doce agentes experimentales, entre ellos uno de compras que prepara órdenes de compra y un asistente analítico temporal para cobranza, y ambos operan hoy con credenciales heredadas de un desarrollador. Eso es lo que ocurre cuando la densidad de agentes llega antes que la infraestructura de identidad, y cada agente recibe la identidad que esté a mano. Como un agente actúa muchas más veces que cualquier persona, una identidad improvisada crece mucho más rápido que su supervisión. El detalle de cómo dar a cada agente una identidad propia con patrocinador y jurisdicción está en gobierno de agentes de IA.
Lo más caro que he visto en proyectos de plataforma fue retirar las versiones locales cuando el servicio común ya existía, y la factura cayó en equipos que nunca pidieron el servicio nuevo. Construir el servicio fue, en comparación, la parte sencilla.
Del inventario al catálogo
En Northstar, aplicar el principio empieza por ver qué se está reconstruyendo, sigue con el reparto de cada servicio entre lo común y lo local y termina en cómo se mide al equipo que lo opera.
Qué reconstruye cada edificio
La tabla recorre las capacidades que un diagnóstico de Northstar encuentra reconstruidas una y otra vez.
| Capacidad | Condición en Northstar | Qué deja de ser consistente |
|---|---|---|
| Identidad y acceso | cuentas compartidas como svc-integracion; agentes con credenciales heredadas de un desarrollador | quién actuó y con qué permiso |
| Notificaciones | tres implementaciones con plantillas, reintentos y bajas propias | el trato que recibe una misma persona |
| Auditoría | un formato de traza por edificio | la evidencia que se entrega a un auditor o regulador |
| Observabilidad | cada edificio mide a su manera | la capacidad de seguir un incidente que cruza edificios |
| Chequeo de políticas | reglas por país copiadas en cada aplicación | el cumplimiento de una misma regla en los cinco países |
La primera fila es la más delicada. En seguridad de una API sobre SAP describí cinco capas de control para una sola API. Si cada edificio que expone una API reconstruyera esas capas a su manera, las versiones divergirían justo donde una diferencia no se ve hasta que alguien la explota.
Común, federado y autónomo
Aplicado a las notificaciones de Northstar, un reparto posible entre esos tres niveles es el del siguiente diagrama.
Con ese reparto, el cambio regulatorio del país C deja de ser un proyecto en tres equipos. El país actualiza su regla de consentimiento, que vive como configuración federada con una etiqueta de jurisdicción, y el motor común la aplica a todo lo que se envía a personas de ese país, venga del e-commerce, de fuerza laboral o de la aplicación local. La traza queda en un solo formato. El país conserva la autoridad sobre su regla y pierde la carga de reimplementar el motor.
Medir al equipo de plataforma
Buena parte de lo que hoy se llama platform engineering encaja en este principio, y DWU no pretende reemplazarlo. Lo que agrega es una manera de ubicarlo junto a los distritos, los edificios y los datos que dependen de él. Los equipos de plataforma son proveedores de infraestructura pública, mientras los distritos siguen desarrollando sus propios edificios, y el éxito de un equipo de plataforma se mide por adopción, confiabilidad, reutilización, reducción de carga cognitiva, cumplimiento de políticas y habitabilidad.
Esa lista cambia lo que hace un equipo. Si se le mide por funcionalidades entregadas, construye funcionalidades. Si se le mide por adopción, tiene que conseguir que usar el servicio común sea más fácil que construir el propio, y eso lo obliga a ocuparse de la documentación, del tiempo que tarda un equipo nuevo en enviar su primer mensaje en producción y de lo que pasa cuando algo falla. La última métrica de la lista, la habitabilidad (qué tan fácil es descubrir, entender y usar el servicio, y recuperarse cuando falla), es la más difícil de medir. La proposición P6 del marco la vincula con más adopción de plataformas gobernadas y menos dependencia de herramientas paralelas no oficiales; la desarrollo en habitabilidad digital.
Esas métricas se vuelven visibles en un catálogo de la infraestructura cívica, es decir, de los servicios compartidos tratados como fundacionales. Una entrada para las notificaciones de Northstar podría verse así.
# Entrada ilustrativa de un catálogo de servicios cívicos
servicio: notificaciones
sistema: infraestructura-publica
propietario:
equipo: plataforma-comunicaciones
responsable_de_producto: rol nombrado, con reemplazo definido
jurisdicciones: [pais-a, pais-b, pais-c, pais-d, pais-e]
consumo:
rutas: [api-envio-v1, evento-mensaje-solicitado]
prohibido: escritura directa en la base de datos del servicio
nivel_de_servicio:
disponibilidad_objetivo: "<acordada y publicada con los consumidores>"
tiempo_de_alta_de_un_consumidor: "<publicado y medido>"
degradacion: cola del consumidor con reenvío diferido
metricas_de_adopcion:
- consumidores activos frente a consumidores objetivo
- implementaciones paralelas conocidas
- tickets de soporte por consumidor
excepcion:
solicita: propietario del edificio
requiere: [motivo, riesgo_aceptado, patrocinador, fecha_de_vencimiento]
al_vencer: migrar, renovar con nueva justificación o retirarDejé los niveles de servicio sin cifras a propósito. El número correcto depende de la empresa. Lo que no depende de ella es que exista, que esté publicado y que alguien lo mida. El bloque de consumo importa tanto como los demás, porque un servicio común al que cada edificio se conecta escribiendo directamente en su tabla recrea el problema de las integraciones punto a punto dentro de la infraestructura que debía resolverlo.
El caso de Grupo Diveco
El inicio de sesión único corporativo (SSO) de Portal Diveco, la plataforma con la que empieza esta serie, llegó el 12 de agosto de 2025, cinco días después del primer commit. El primer módulo de negocio llegó un mes más tarde, el 11 de septiembre, y los que siguieron se apoyan en esa identidad compartida y en servicios comunes de auditoría y notificaciones. En la maqueta 3D de la plataforma, la identidad es la Aduana.
Una pieza de conectividad tuvo otra clase de efecto. Se construyó para un caso de autoservicio de los colaboradores y terminó habilitando un módulo posterior que nadie había planeado. La narrativa interna del portal lo cuenta como piezas de LEGO. En los términos de la literatura citada arriba, una pieza hecha para una necesidad creó una opción para la siguiente.
El filtrado por fila, que decide qué registros ve cada usuario en un reporte, siguió la secuencia inversa. Los reportes proliferaron antes de que existiera un motor común, la deuda quedó documentada como dos motores de filtrado paralelos que divergieron, y la versión unificada llegó el 20 de julio de 2026, casi un año después del SSO. Fue densidad antes que infraestructura, corregida después.
Todavía falta un motor de políticas transversal, así que el orden fue el correcto para la identidad, tardío para el filtrado y sigue pendiente para las políticas. Es un solo caso y no tiene mediciones, por lo que ilustra el principio sin medir sus efectos.
Lo que P1 predice y lo que la debilitaría
La primera proposición del marco, P1, dice que a mayor adopción de infraestructura digital pública confiable, menor duplicación de capacidades fundacionales entre productos digitales. Es una hipótesis que el preprint plantea sin probarla.
El adjetivo «confiable» carga casi todo el peso. Una plataforma que se cae, que tarda semanas en dar acceso o que nadie entiende tiene adopción baja, y los equipos que la esquivan construyen su propia versión. Si P1 es cierta, lo que esperaría observar en Northstar es que el número de implementaciones de notificaciones baje a medida que crecen los consumidores del servicio común, y que los edificios nuevos dejen de traer autenticación y auditoría propias. La evidencia que la pondría a prueba está en los catálogos de servicios, en los componentes duplicados de identidad y notificación y en las métricas de adopción de la plataforma. En la entrada de catálogo de la sección anterior, la métrica de implementaciones paralelas conocidas es P1 a la escala de un solo servicio.
La duplicación también puede caer por razones ajenas a la confiabilidad. Si una empresa elimina las implementaciones locales por decreto, con una plataforma mediocre, la duplicación cae y P1 parece confirmarse sin que la confiabilidad haya tenido nada que ver. Solo un estudio que mida la confiabilidad por separado de la adopción podría distinguir los dos casos.
Cuello de botella y concentración
La tensión que acompaña a P1 es directa. La infraestructura compartida puede reducir la duplicación y al mismo tiempo crear cuellos de botella o riesgo sistémico de concentración. Las dos cosas le pasarían a Northstar.
El cuello de botella aparece primero. Cuando el país C necesita un canal de mensajería que el servicio común no soporta, su pedido entra al backlog del equipo de plataforma y compite con los de los otros cuatro países. Si la espera es más larga que construirlo localmente, el país lo construye, y aparece la cuarta implementación. Una solución útil creada fuera de la arquitectura compartida es una señal diagnóstica de demanda no satisfecha, y aquí la señal apunta al servicio común, que no responde a una velocidad aceptable.
La concentración es menos visible y más peligrosa. Las tres implementaciones independientes tenían una virtud que nadie diseñó. Una falla en la del e-commerce no tocaba a las otras dos. Con un servicio común, una caída de notificaciones afecta al e-commerce, a fuerza laboral y a los cinco países a la vez. En identidad el caso es extremo, porque si el servicio compartido de identidad falla, nadie entra a ningún lado. Por eso el principio habla de madurar la infraestructura. Una capa compartida necesita modos de degradación (la cola del consumidor con reenvío diferido del ejemplo), aislamiento de capacidad entre consumidores para que el pico de uno no deje sin servicio a los demás, y una operación a la altura de la dependencia que crea.
El tercer costo es político. Una plataforma obligatoria por decreto puede mostrar métricas de adopción excelentes y ser un mal servicio, y entonces la métrica que debía decir si el servicio merece usarse deja de decir algo.
El orden y la excepción
Espero que infraestructura primero y densidad después salga más barato que la secuencia inversa, que termina en renovación. La infraestructura que llega primero también concentra el riesgo, y lo que impide que el principio se vuelva dogma es el proceso de excepción. Una excepción con motivo, riesgo aceptado, patrocinador y fecha de vencimiento es información. Le dice al equipo de plataforma qué no está cubriendo el servicio, y le dice al arquitecto dónde crece, con conocimiento de causa, la deuda urbana, ese costo estructural acumulado que restringe el cambio. Un registro de excepciones que solo crece sugiere que el servicio cuesta habitarlo. Uno vacío durante mucho tiempo puede indicar lo contrario, o que los equipos dejaron de pedir permiso.
La decisión práctica es pequeña. Antes de aprobar el próximo edificio, preguntar cuáles de estos servicios traerá por su cuenta y quién firmará la excepción si los trae. La pregunta que el marco todavía no responde es cuántas excepciones vigentes debería tolerar un servicio común antes de concluir que el problema está en el servicio y no en los equipos.
Este artículo es parte de la serie Urbanización digital, basada en el preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), un marco conceptual cuyas ideas apliqué y refiné en la plataforma corporativa de Grupo Diveco, aunque sus seis proposiciones todavía no tienen validación empírica. Anterior: Zonificar la empresa por capacidades de negocio. Siguiente: Las integraciones punto a punto son carreteras improvisadas.