Ninguna empresa puede cerrar por remodelación. La deuda urbana es el conjunto de restricciones al cambio que se acumulan cuando la infraestructura se fragmenta, las capacidades se duplican, los flujos se vuelven opacos, los componentes quedan abandonados y las excepciones de gobierno dejan de vencer. Se paga como se renueva una ciudad habitada, por bloques y con la operación en marcha, decidiendo cada bloque según el estado de sus edificios y poniéndole fecha de vencimiento a cada excepción.
Northstar Consumer Group, un fabricante y minorista regional ficticio, tiene cinco entidades legales, un ERP, aplicaciones por país, más de cuarenta productos analíticos y doce agentes experimentales. Nada de eso se puede apagar un fin de semana para ordenarlo.
De dónde sale la deuda en Northstar
Las cinco fuentes están en Northstar, y ninguna fue una mala decisión el día en que se tomó.
Las dos primeras se confunden con facilidad. La infraestructura fragmentada es un servicio que debería ser común y se construyó varias veces. Con tres implementaciones de notificaciones, cuando cambie la regla de consentimiento de un país Northstar tendrá que cambiarla en tres lugares y probarla tres veces. La capacidad duplicada se esconde mejor, porque cada copia parece legítima vista desde su propio edificio (la aplicación, el servicio o el modelo que la entrega). El margen se calcula de tres formas. Cada fórmula tiene dueño en su distrito, la capacidad de negocio a la que pertenece, y ninguno de esos dueños manda sobre las otras dos.
Los flujos opacos y los componentes abandonados comparten un síntoma, lectores que nadie tiene anotados. La herramienta de BI consulta tablas del ERP directamente, la aplicación de un país también, y varias integraciones entran con la misma cuenta de servicio, svc-integracion, de modo que en los registros de acceso no se distingue cuál leyó qué. Entre los más de cuarenta productos analíticos hay además dashboards que nadie abre y que nadie se anima a apagar, porque tampoco hay quien sepa si alguien los necesita. Cada uno conserva sus permisos y sus consultas contra el subsuelo (los datos, metadatos, linaje y semántica de los que dependen las aplicaciones). El día que el dueño del ERP quiera cambiar una tabla no tendrá forma de saber cuántos de esos lectores se van a romper, ni cuáles importan.
La quinta fuente, las excepciones de gobierno, es la que menos se registra. Una excepción es un permiso para saltarse una regla de la ciudad durante un tiempo y por un motivo, concedido por alguien con autoridad para hacerlo. Se vuelve deuda cuando el tiempo no tiene fin. El caso de Northstar no dice si alguien autorizó formalmente que el agente de compras y el asistente de cobranza operaran con credenciales heredadas de un desarrollador, o que el BI leyera tablas del ERP. Dice que así operan hoy, y nada en el caso indica cuándo dejarán de hacerlo.
La deuda que vive entre edificios
El marco define la deuda urbana como un costo estructural acumulado que restringe el cambio y aumenta el riesgo operativo. La presenta como una extensión de la deuda técnica al territorio, el perímetro estratégico, legal y de riesgo dentro del cual la empresa fija sus reglas.
El bucle de abajo no forma parte del marco, y conviene decirlo. Lo dibujo porque es lo que más he visto repetirse. Cuando cambiar algo por la ruta formal cuesta demasiado, alguien pide una excepción o construye un asentamiento informal (una solución útil hecha fuera de la arquitectura y de los controles compartidos), y ese atajo se convierte en la siguiente fuente de deuda. DWU tiene dos piezas cercanas, la proposición P5 y la relación recíproca entre baja habitabilidad y asentamientos, y en habitabilidad digital las uní en un solo bucle.
La literatura sobre opciones y deuda digital ya había sacado la deuda del código. Los servicios estandarizados crean opciones de desarrollo futuro, y las excepciones no gestionadas, los componentes duplicados y las integraciones fuertemente acopladas restringen el cambio y afectan la confiabilidad o el desempeño de la firma (Ramasubbu y Kemerer, 2016; Rolland et al., 2018; Banker et al., 2021). Leavell (2026) añade la deuda interpretativa, los compromisos de interpretación que se apilan en capas. Los tres márgenes de Northstar encajan bien ahí. El ERP registra una venta, el BI la interpreta con un criterio y el dashboard comercial la vuelve a interpretar con otro.
Lo que agrega el adjetivo urbano, a mi juicio, es la ubicación. Los inventarios de deuda técnica que he visto se llevan por edificio. Cada equipo anota en su backlog librerías viejas y pruebas que faltan. De las cinco fuentes, tres viven entre edificios (la fragmentación, la duplicación y los flujos opacos), los componentes abandonados no tienen backlog porque no tienen dueño, y las excepciones viven en decisiones de gobierno que ningún repositorio registra. El equipo del dashboard comercial podría cerrar todos sus tickets de deuda y el dashboard seguiría leyendo tablas del ERP sin contrato y calculando su propio margen.
Para pagarla, el octavo principio de DWU, renovación continua, plantea la modernización del legado como renovación urbana gestionada. La idea es anterior al marco y viene de la tradición de urbanizar sistemas de información, que ya daba por hecho que el sistema se renueva habitado.
Renovar con la gente adentro
El reemplazo total tienta porque promete pagar toda la deuda de una vez. Rara vez es posible. Las infraestructuras digitales son relacionales, están embebidas en otras estructuras, dependen de su trayectoria y son difíciles de rediseñar desde cero (Star y Ruhleder, 1996; Hanseth y Lyytinen, 2010; Tilson et al., 2010). Mientras el reemplazo se construye, la ciudad vieja sigue recibiendo pedidos y acumulando dependencias nuevas. Una migración de SAP ECC a S/4HANA es un caso conocido, y en el negocio no espera a S/4HANA expliqué por qué el doble mantenimiento suele llevar a congelar los cambios funcionales del sistema viejo justo cuando el negocio más le pide.
La alternativa es renovar por bloques.
El orden de los bloques
Uso «bloque» como unidad de obra, un grupo pequeño de edificios con dependencias compartidas que se puede intervenir en un ciclo de portafolio sin detener lo demás. Se parece al îlot de la tradición francófona, aunque aquel partía el sistema y este organiza la obra. Para elegir el orden me apoyo en el registro de edificios que describí al zonificar por capacidades, donde cada edificio lleva uno de cuatro estados. El estado no decide por nadie, pero indica qué pregunta hacer primero. La tabla es una heurística mía.
| Estado en el registro | Primera pregunta de renovación | Ejemplo en Northstar |
|---|---|---|
| Propiedad abandonada | ¿Alguien lo reclama con nombre y propósito? Si nadie lo hace, se retira | Dashboard duplicado del distrito Personas |
| Estructura temporal | ¿Venció su fecha de revisión? | Agente de compras en piloto |
| Instalación legada | ¿Qué rutas hay que gobernar antes de tocarla? | App de país, script nocturno de conciliación |
| Hito estratégico | ¿Qué excepciones y duplicados carga? | Dashboard comercial |
Empiezo por las propiedades abandonadas porque retirar cuesta poco y cada retiro quita un lector del subsuelo. Las instalaciones legadas van después, y rara vez se reemplazan de entrada. Primero se ponen detrás de una ruta gobernada (una API, un evento o una cola con contrato y monitoreo), y solo entonces se decide si se reubican o se retiran. Es la lógica de la capa de integración que describí en extender un SAP ECC de 20 años sin exponerlo, donde la migración cambia adaptadores y los canales siguen sin enterarse. El diagrama pone en el tiempo cuatro edificios de Northstar, con la operación diaria corriendo debajo.
Excepciones con fecha de vencimiento
La fila del dashboard comercial es la que más me interesa, porque un hito estratégico también carga deuda. Nadie propondría retirarlo. Aun así, lee tablas del ERP por fuera de cualquier ruta con contrato, y en el caso nadie registró esa lectura como excepción, así que tampoco tiene fecha de fin. En infraestructura antes que densidad propuse que cada excepción a un servicio común llevara motivo, riesgo aceptado, patrocinador y fecha de vencimiento. Así quedaría esa lectura si Northstar la registrara hoy con la misma lógica.
# Registro ilustrativo de una excepción de gobierno. Caso ficticio Northstar.
# Formato propio; ningún estándar lo define.
id: exc-dashboard-comercial-lectura-erp
estado: vigente # vigente | vencida | renovada | cerrada
regla_exceptuada: leer datos del ERP solo por rutas con contrato
edificio: dashboard-comercial
distrito: comercial
alcance:
lee: tablas de pedidos y posiciones del ERP
identidad: cuenta propia del dashboard # nunca svc-integracion
origen: la lectura directa es anterior al registro; fecha de inicio desconocida
motivo: el producto de datos de pedidos todavía no publica su contrato
riesgo_aceptado: >
un cambio en las tablas del ERP puede romper el dashboard sin aviso;
el margen se sigue calculando fuera de Finanzas
patrocinador: direccion-comercial
responsable: equipo del dashboard comercial
registrada: 2026-10-01 # fechas ilustrativas
vence: 2027-03-15 # lejos de la semana de cierre
plan_de_salida:
- consumir el producto de datos de pedidos cuando publique su contrato
- tomar el margen de la definición de Finanzas
- cerrar el permiso de lectura directa en la base del ERP
aviso_previo: al patrocinador, antes del vencimiento
al_vencer: revocación del acceso, salvo renovación firmada
renovaciones: 0 # cada renovación queda contada y visibleLa fecha de vencimiento convierte un permiso en un compromiso con fin. Sin ella, una excepción es una regla nueva que nadie aprobó. El patrocinador es alguien con autoridad que responde por el riesgo aceptado, y es quien tiene que firmar si la fecha llega antes que el plan de salida. El contador de renovaciones hace visible lo que en Northstar hoy es invisible. Una excepción renovada una vez puede ser prudente, y una renovada cada ciclo es deuda urbana con papeles en regla.
Un registro que depende de que alguien se acuerde de revisarlo sirve poco. La regla de vencimiento se puede volver ejecutable, como las fitness functions convierten una regla de arquitectura en una prueba. Un chequeo programado compara el registro con los permisos reales y falla cuando una excepción vencida todavía tiene acceso a la base del ERP. De las cinco fuentes, las excepciones fueron siempre la que más tardé en ver en mi práctica, porque no aparecían en ningún diagrama ni backlog.
Una excepción olvidada y un asentamiento del mapa de asentamientos informales terminan pareciéndose mucho; la diferencia es que la excepción tuvo alguna vez una firma. Por eso, al llegar la fecha, uso para las excepciones las mismas cuatro respuestas que el marco propone para los asentamientos (reconocimiento, integración, reubicación o retiro). Renovar equivale a reconocerla por otro periodo, y cerrarla con el plan de salida cumplido equivale a integrarla a la ruta formal. Esa aplicación a las excepciones es mía.
El caso de Grupo Diveco
Portal Diveco, la plataforma de Grupo Diveco que retraté en el primer artículo, documenta su deuda caso por caso. En abril de 2026 el esquema GraphQL del portal llegó a su límite de recursos, y desde entonces toda ruta nueva tiene que usar un patrón alterno. Dos motores de filtrado por fila corrían en paralelo y divergieron hasta unificarse en julio de 2026. Un etiquetado manual anterior se degradó. Visto con las cinco fuentes de arriba, el límite del esquema es infraestructura compartida saturada y los dos motores son una capacidad duplicada, dos deudas que viven entre edificios. El chequeo de tipos sigue desactivado «temporalmente», una palabra que el registro de excepciones convertiría en fecha.
La renovación también fue por partes. En mayo de 2026 el correo de la Brújula Comercial dejó el pipeline legado y pasó a calcularse sobre el data lake, cuando una revisión encontró cifras que no cuadraban con el portal. El módulo Explosión de Materiales se reconstruyó desde cero tras la migración fallida de un proveedor, un reemplazo total a escala de un edificio. En agosto de 2026 llegó una taxonomía de etiquetas para los recursos cloud con una auditoría de recursos sin dueño, el equivalente de empezar por las propiedades abandonadas.
Lo que no existe es una métrica agregada. Cada caso vive en su documento, la deuda no se suma ni se sigue en el tiempo, y no sé si la deuda urbana de la plataforma crece o baja. La maqueta 3D de la plataforma tampoco lo dice. En ella, SAP es un solo edificio monolítico del tamaño de un distrito, con robots de RPA cargando cajas hacia él, una buena imagen de lo que la tabla de arriba llama instalación legada. Pero la maqueta se sincroniza a mano y dibuja el monolito sin medirlo.
Cómo se distinguiría de la deuda técnica
La diferencia entre deuda urbana y deuda técnica tiene que poder medirse, o el término sobra. El marco pide que cada constructo explique algo que ningún otro capture, y su segunda prueba discriminante lo aplica de forma explícita a la densidad de asentamientos informales, que debe separarse empíricamente de los inventarios convencionales de deuda técnica. Extiendo la misma exigencia a la deuda urbana, y esa extensión es mía. Lo que esperaría observar es que dos organizaciones con inventarios de deuda técnica parecidos difieran en costo de cambio o en incidentes según cuánta deuda urbana carguen, medida con cosas contables como excepciones vencidas, edificios sin dueño o capacidades con más de una implementación. Si esas medidas se mueven junto con el inventario de deuda técnica por encima de los umbrales aceptados, la deuda urbana es la misma deuda con otro nombre.
Todo esto es una hipótesis. Yo no lo he medido, y el preprint donde propuse el marco tampoco lo hace.
La atribución es otro problema. Si Northstar renovara por bloques y su cambio se volviera más rápido, el mérito podría ser igual de bien de un presupuesto de plataforma más grande, una de las explicaciones rivales que reviso en cómo sabría que esta teoría está equivocada.
Lo que cuesta renovar por partes
La renovación por bloques tiene un precio que el diagrama deja a la vista. En los tramos donde lo viejo y lo nuevo conviven, Northstar mantiene dos rutas hacia los mismos pedidos, dos conjuntos de permisos y dos márgenes que alguien tiene que conciliar mientras dura el cambio. El dueño del ERP, el equipo del dashboard, Finanzas y el equipo de datos tienen que coordinarse en cada bloque. El marco reconoce esa tensión en la movilidad gobernada (datos, comandos y eventos que viajan por rutas con contrato), que aumenta la capacidad de cambio e impone costos de coordinación, y la renovación por bloques la multiplica, porque cada bloque es una coordinación nueva.
Ese costo es la razón por la que el reemplazo total vuelve a aparecer en cada comité. Un solo proyecto se explica mejor que una secuencia de bloques, y tiene una fecha de fin que se puede anunciar. Mi objeción es de trayectoria más que de principio. Si la ciudad vieja sigue acumulando dependencias mientras se construye la nueva, el día del corte hay más que migrar que el día de la aprobación.
El registro de excepciones también tiene su costo. Si pedir una excepción exige varias firmas y semanas de espera, los equipos dejan de pedirlas y construyen por fuera. Formalizar asentamientos informales tiene la misma tensión, porque mejora el gobierno y puede suprimir la experimentación local. La revocación automática trae su propio riesgo. Cortar el acceso del dashboard comercial el día del vencimiento, en plena semana de cierre, deja a la dirección sin su dashboard en el peor momento, y por eso el ejemplo avisa antes y pone el vencimiento lejos del cierre.
El registro mínimo
Si solo hay capacidad para una práctica, elijo el registro de excepciones con vencimiento, porque convierte la fuente más invisible de las cinco en una lista con nombres y fechas. Para abrirlo basta con listar las desviaciones que ya existen, incluidas las que nadie llamó excepción (en Northstar, las credenciales heredadas de los dos agentes y la lectura directa del BI), y ponerle patrocinador y vencimiento a cada una aunque nadie sepa cuándo empezó.
Es probable que la primera revisión traiga un caso que la plantilla no contempla, la excepción cuyo patrocinador ya no está en la empresa. Propongo tratarla con la misma regla que a un dashboard sin dueño. Es una propiedad abandonada, esta vez del gobierno, y se retira salvo que alguien con nombre la reclame antes de la fecha.
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: Gobierno de agentes de IA: identidad cívica y jurisdicción. Siguiente: Canvas de urbanización digital: diagnóstico en 10 preguntas.