La tradición olvidada de urbanizar sistemas de información

La urbanización de sistemas de información es una tradición francófona de arquitectura que usa conceptos de la planificación urbana para dividir el sistema de información en zonas, barrios, bloques y vías de comunicación, y cuya idea central es separar las capacidades estables de las implementaciones que cambian. Esa intuición sigue siendo correcta. Lo que le falta es un lugar para las plataformas cloud internas, los productos de datos, los modelos de lenguaje y los agentes de IA, y ese hueco es el que la Urbanización del Mundo Digital (DWU) intenta cubrir.

En las conversaciones de arquitectura en español que he tenido, la palabra casi nunca aparece. Cuando la uso yo, la asociación inmediata es inmobiliaria (alguien imagina una lotificación con garita) y tengo que aclarar que hablo de otra cosa. Esa ausencia me incomoda, porque varias de las ideas que aplico en arquitectura de plataformas empresariales ya tenían nombre y autores en la literatura francesa.

Este texto, que sigue a la empresa como territorio habitado, reconoce esa deuda intelectual y explica dónde la tradición se queda corta.

Qué propuso la urbanización de sistemas de información

En francés se llama urbanisation du système d’information, y toma el vocabulario urbano tal cual, con zonas, barrios (quartiers), bloques (îlots) y vías de comunicación entre ellos. El objetivo declarado era reducir el acoplamiento entre las partes sin perder la coherencia del conjunto.

El gesto que más me interesa está en la división del trabajo. El urbanista deja el diseño de cada edificio (en la empresa, cada aplicación) a quien lo construye y se reserva lo que ningún constructor puede decidir solo, que es el uso del suelo, la infraestructura compartida, las fronteras, las interfaces y las reglas de evolución. Traducido a una organización, el área de arquitectura decide qué capacidad vive en qué barrio y por dónde se pasa de uno a otro, y cada equipo decide cómo construye lo suyo.

Detrás hay una distinción que para mí sigue siendo la más útil de todas. Las capacidades de negocio cambian despacio, porque una empresa sigue vendiendo y pagando salarios durante décadas, mientras las aplicaciones que las implementan se reemplazan cada pocos años. Un plano dibujado sobre capacidades sobrevive a esos reemplazos. Uno dibujado sobre aplicaciones envejece con la primera migración.

La otra idea que conservo es casi de sentido común. Una empresa no puede suspender operaciones mientras rediseña su arquitectura, así que el sistema de información, como una ciudad, se renueva habitado y por tramos, y la regla que evita que el tramo nuevo repita el error del viejo tiene que sobrevivir a la obra. En mi práctica esa regla suele terminar como fitness function, una prueba automatizada que falla cuando un cambio cruza una frontera prohibida. El término viene de otra tradición; la de urbanización hablaba de evolución controlada, y la conexión me parece directa.

El plano clásico aplicado a Northstar

Para ver dónde se queda corta la tradición uso el caso de toda la serie. Northstar Consumer Group es una empresa ficticia, un fabricante y minorista regional con cinco entidades legales en cinco países. Ha acumulado un ERP, plataformas de clientes y de fuerza laboral, aplicaciones por país, una plataforma de datos cloud, más de cuarenta productos analíticos y doce agentes inteligentes experimentales. Reúne en un solo territorio, es decir, un entorno con propósito, jurisdicciones, recursos y restricciones de riesgo propias, patrones que la literatura documenta por separado. Lo uso para razonar, sabiendo que un caso inventado no aporta evidencia de nada.

Si Northstar contratara a un urbanista de SI de escuela clásica, su plano, simplificado y en un formato inventado para el ejemplo, se parecería a esto.

# Ilustrativo. No es un formato estándar de la urbanización de SI.
zonas:
  operacion:
    barrios:
      comercial:
        bloques: [pedidos, precios, clientes]
        aplicaciones: [erp_ventas, ecommerce, app_pais_c]
      cadena_suministro:
        bloques: [compras, inventario, distribucion]
        aplicaciones: [erp_logistica]
  soporte:
    barrios:
      finanzas:
        bloques: [contabilidad, cierre, margen]
        aplicaciones: [erp_finanzas]
      personas:
        bloques: [nomina, talento]
        aplicaciones: [plataforma_fuerza_laboral]
vias:
  - {de: comercial, a: finanzas, interfaz: pedidos_facturados}
  - {de: cadena_suministro, a: finanzas, interfaz: recepciones}
capa_informacional:
  objetos: [cliente, producto, margen, colaborador]
capa_tecnica: [plataforma_datos_cloud, red, computo]

Ese plano detecta bastante, y conviene reconocerlo antes de criticarlo. En Northstar el margen se calcula de tres formas (la del cierre de Finanzas, la del dashboard comercial y la de la aplicación de un país), justo la incoherencia que la capa informacional existe para atrapar. La herramienta de BI y una aplicación de país leen tablas del ERP directamente y se saltan las interfaces que el plano declara en vias. Y las tres implementaciones de notificaciones son infraestructura compartida construida tres veces. Un urbanista clásico competente señalaría todo eso.

Los problemas empiezan con lo que actúa. El agente de compras prepara órdenes de compra con credenciales heredadas de un desarrollador, y el YAML no tiene dónde ponerlo. Podría listarse como una aplicación más de cadena_suministro, y esa línea callaría lo que importa, que es en nombre de quién actúa, qué puede hacer, con qué identidad y quién responde cuando se equivoca. Las cuatro capas clásicas (funcional, aplicativa, informacional y técnica) describen cosas que existen y se conectan, y carecen de un campo para actores que deciden y ejecutan. Menos aún distinguen al asistente analítico que entra para un análisis de cobranza y se va del agente que se queda con tareas recurrentes, diferencia que desarrollo en gobierno de agentes de IA.

Los más de cuarenta productos analíticos tampoco encuentran lugar propio. En el plano aparecen, con suerte, como objetos de la capa informacional o como reportes colgados de una aplicación, y pierden lo que los hace productos. Un producto tiene dueño, consumidores conocidos, reglas de calidad y un contrato de acceso.

Y la cuenta de servicio svc-integracion, que usan varias integraciones a la vez, queda como un detalle de la capa técnica. Para DWU es un habitante, es decir, un actor no humano que accede a recursos y los transforma, y uno sin identidad propia. Cuando alguna de esas integraciones hace algo indebido, atribuir la acción a la integración correcta se vuelve trabajo forense.

Una genealogía ordenada por problemas

DWU no pretende haber inventado la mirada territorial. Se reconoce heredera de cinco corrientes, y de cada una conviene anotar qué resolvió y qué dejó abierto. El orden del diagrama es conceptual. Star y Ruhleder (1996) escribieron sobre infraestructura ocho años antes que Bidan (2004), y en el diagrama van después porque cubren parte de lo que la urbanización clásica dejó fuera.

Arquitectura empresarial

Puso el primer marco. Zachman (1987) organizó las descripciones de una empresa por la perspectiva de cada interesado, y TOGAF (The Open Group, 2022) formalizó método, gobierno y contenido reutilizable. Nada de eso sobra. El problema aparece cuando la práctica se reduce a modelos estáticos y a un estado objetivo dibujado una vez, que representan mal la evolución continua de las plataformas y a los actores de software autónomos.

Urbanización de SI

Agregó el vocabulario territorial y la renovación sin desalojo, con un límite de época. Trabaja con las cuatro capas clásicas y en general es anterior a las plataformas internas cloud-native, los productos de datos distribuidos, los LLMs y los agentes autónomos. De su trabajo empírico y doctoral, DWU se apoya en particular en Bidan (2004), que estudió la federación e integración de aplicaciones, y en Trabelsi (2014), que estudió el desempeño de sistemas de información urbanizados.

Plataformas e infraestructuras

Esta literatura movió el foco hacia lo compartido. Una plataforma combina un núcleo estable con complementos que construyen otros, y Gawer (2014), entre otros, sostiene que gobernar esa apertura es parte de la capacidad misma de escalar. Star y Ruhleder (1996), Hanseth y Lyytinen (2010) y Tilson et al. (2010) describen infraestructuras que dependen de su trayectoria y son difíciles de rediseñar desde cero. Estas corrientes suelen mirar una plataforma focal, mientras Northstar tiene varias conviviendo, y no ofrecen constructos de empresa para la jurisdicción (qué reglas aplican en qué entidad o país) ni para la habitabilidad, el grado en que la gente puede descubrir servicios, entender los datos y saber quién responde.

Datos como producto

Dehghani (2020) llevó una lógica parecida a los datos con data mesh, cuyos cuatro principios son la propiedad orientada a dominio, los datos como producto, la infraestructura self-service y el gobierno computacional federado. Encaja bien con la urbanización porque combina responsabilidad local con infraestructura común y reglas exigibles. Por sí solo, sin embargo, deja fuera las aplicaciones, los flujos de trabajo, las identidades y los agentes.

Gobierno de IA y agentes

Es la corriente más reciente. El marco de riesgo del NIST (2023) pide gobernar todo el ciclo de vida, y el trabajo del NCCoE sobre agentes (Booth et al., 2026, todavía un borrador público inicial) se concentra en su identificación, autorización, auditoría y no repudio. Ninguno de los dos ofrece una teoría arquitectónica de dónde vive el agente de compras de Northstar, por qué rutas se mueve, qué servicios comunes usa y cómo convive con las personas que hacen un trabajo parecido.

Qué hereda DWU y qué extiende

La tabla es mi lectura, fila por fila, de dónde reaparece cada pieza clásica en DWU.

Las cinco primeras filas son herencia con cambios de grado. La idea de la primera, zonificar por capacidades, pasa casi intacta, y es el tema del siguiente texto de la serie.

La sexta cambia de categoría. El sistema deja de estar poblado por usuarios y pasa a tener habitantes que actúan, algunos no humanos, cada uno con una identidad que alguien patrocina. En la séptima, la renovación hereda una cuenta pendiente, la deuda urbana, que es el costo acumulado de capacidades duplicadas, flujos opacos y componentes abandonados y que extiende la deuda técnica al territorio entero.

La última fila no tiene antecesor. La habitabilidad digital y los asentamientos digitales informales (soluciones útiles creadas fuera del gobierno compartido, como la hoja de cálculo de precios ajustados que circula por correo en Northstar), junto con la identidad cívica de la sexta fila, son los tres constructos que el marco propone como explicativos candidatos. Son también los que más trabajo tendrán que hacer para justificarse.

Al lado de los enfoques vecinos

Reducida a cuatro columnas, la comparación con los enfoques más cercanos queda así.

La tabla se lee mejor por columnas. En la de agentes, los demás enfoques los dejan implícitos, parciales o fuera de foco, y DWU es el único de la tabla que los declara habitantes con reglas propias. En la de datos el movimiento es otro, porque data mesh ya los había convertido en objeto central de gobierno y DWU los reubica como infraestructura compartida del subsuelo.

Nada de esto convierte a DWU en reemplazo. El marco deja claro que TOGAF, el mapeo de capacidades, platform engineering, data mesh, zero trust y los marcos de riesgo de IA siguen haciendo su trabajo, y propone DWU como estructura de nivel meso (entre la aplicación individual y la sociedad digital) para ubicar a cada uno y sus tensiones. Con data mesh, Northstar sabría quién es dueño del producto de margen; DWU le agrega qué distrito tiene autoridad sobre esa definición y por qué ruta llega al dashboard comercial sin tocar las tablas del ERP. La comparación completa está en el subsuelo de datos que nadie ve.

El riesgo de re-etiquetar lo viejo

La objeción más seria contra DWU sale de este mismo post. Si la tradición francesa ya tenía zonas, barrios, bloques y vías, cambiar «barrio» por «distrito» y «vía de comunicación» por «movilidad gobernada» gasta vocabulario sin comprar nada. Para una organización que ya trabaja con TOGAF y un mapa de capacidades, ese gasto es real. Hay que traducir entre dos lenguajes y sostener dos juegos de diagramas mientras dura la transición. Si al final el diagnóstico sale igual, ese costo se pagó para nada.

Que la metáfora urbana ya existiera antes, y este post muestra que existía, no cuenta a favor ni en contra. El marco mide su novedad con un criterio que la metáfora sola no satisface, el de si sus constructos explican fenómenos que las teorías adyacentes dejan repartidos en unidades de análisis separadas.

Con ese criterio la objeción se convierte en prueba. Si la jurisdicción de distrito, el gobierno de la movilidad, la densidad de asentamientos informales y la habitabilidad no explican diferencias en duplicación, fragilidad de integración o adopción de herramientas sombra más allá de lo que ya explican los puntajes de madurez de arquitectura empresarial, DWU se reduce a una evaluación de madurez re-etiquetada. Por ahora es una hipótesis sin validación empírica, igual que el resto del marco.

Hay un límite más que me toca de cerca por escribir en español. La revisión de literatura del preprint puede sub-representar tradiciones en idiomas distintos del inglés y el francés. Si en la arquitectura de habla hispana existe una corriente equivalente a la urbanización de SI, la búsqueda no la recogió, y me interesa que alguien me la señale.

Dos preguntas antes de cambiar de vocabulario

Quien ya tenga un plano de urbanización clásico, o un mapa de capacidades que haga lo mismo, puede hacerle dos preguntas antes de adoptar vocabulario nuevo, dónde viven sus agentes y quién es dueño de sus productos de datos. Si el plano responde sin cambiar de forma, el vocabulario nuevo no le compra nada a esa organización.

La prueba de madurez re-etiquetada y las otras dos que el marco se impone, con las condiciones en que yo mismo abandonaría partes de él, están en cómo sabría que esta teoría está equivocada.

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: La empresa como territorio habitado. Siguiente: Zonificar la empresa por capacidades de negocio.