Sabría que la Urbanización del Mundo Digital (DWU) está equivocada si sus constructos no explicaran nada que un puntaje de madurez de arquitectura empresarial ya explica, si resultaran indistinguibles de instrumentos que ya existen o si dos analistas no lograran clasificar igual las piezas de una misma empresa. Esas son las tres pruebas discriminantes que dejé escritas en el preprint, y este post las desarrolla porque un marco que no puede fallar tampoco puede explicar nada.
Soy la peor persona para juzgar esta teoría, porque la escribí. DWU propone leer el mundo digital de una empresa como un territorio habitado, organizado en siete sistemas (la empresa como territorio habitado), y llevo once posts de la serie Urbanización digital usándolo. Este deja por escrito qué tendría que pasar para que dejara de usarlo, o usara bastante menos de él.
El estatus real del trabajo
DWU existe hoy como un preprint conceptual en Zenodo, sin revisión por pares. Sus contribuciones son afirmaciones de construcción teórica y ninguna es un hallazgo empírico. Sus seis proposiciones son hipótesis que nadie ha contrastado todavía.
La base es una revisión integrativa preliminar de 28 referencias, publicadas entre 1977 y julio de 2026, hecha para construir constructos y sin pretensión de exhaustividad. Las limitaciones de método están declaradas en el propio texto y no las suavizo. Un solo autor diseñó la búsqueda, codificó las fuentes y eligió los constructos. El protocolo no se pre-registró. La cobertura de bases de datos es selectiva, el corpus es mixto y la auditoría bibliográfica no evaluó de forma independiente la calidad de cada fuente. Puede haber sesgo interpretativo y tradiciones sub-representadas fuera del inglés y el francés.
Queda la parte que más me incomoda. Durante los tres años previos a escribir el marco apliqué y refiné estas ideas en arquitectura de plataformas empresariales. De esa práctica, solo la parte hecha en la plataforma corporativa de Grupo Diveco, que empieza en agosto de 2025, está documentada en repositorios. Toda ella tiene un rol abductivo, es decir, sugirió los constructos y dio forma a sus fronteras. Nadie la diseñó como estudio y no valida nada. Sí trae un riesgo de sesgo de confirmación, porque la práctica de donde salieron las ideas es también donde las veo confirmarse.
Si una integración punto a punto falla, la leo como camino improvisado. Si un equipo construye su propio servicio de notificaciones, veo infraestructura pública que no llegó a tiempo. Esas lecturas pueden ser correctas y valer poco como evidencia, porque las hago con la categoría ya puesta.
Portal Diveco, que internamente también se llama Ciudad Diveco, es el portal corporativo interno de Grupo Diveco y la parte documentada de esa práctica. A septiembre de 2026 reúne medio centenar de herramientas registradas, que se apoyan en servicios compartidos de identidad, auditoría y filtrado por fila y en un data lake con semántica común. Tiene también un agente de IA cuyo alcance se fuerza en el servidor a partir de la identidad del usuario. En septiembre también publicamos una maqueta 3D que dibuja la plataforma como una ciudad, con un edificio por herramienta y datos estáticos que se sincronizan a mano. El marco se abstrajo de esa práctica y el portal no usa su vocabulario. Lo urbano está en la marca, como el rol «Ciudadano DIVECO» que todo usuario recibe por defecto desde agosto de 2025.
Todo eso muestra que los constructos se pueden operacionalizar en una organización real. No valida ninguna de las seis proposiciones. Es un solo caso, soy su arquitecto y casi todo es anterior a que escribiera el marco, porque es justamente la práctica de la que salieron los constructos. Tampoco tengo mediciones comparativas de duplicación, fragilidad de integración, incidentes de autorización ni adopción. Lo que ofrece es material para el estudio de caso retrospectivo con el que empezaría la validación, si la organización lo autoriza.
La serie tiene el mismo sesgo en pequeño. A Northstar Consumer Group, el caso ficticio que la recorre, lo compuse con patrones de mi práctica que la literatura documenta para que cada sistema tuviera un problema visible, y elegí cada ejemplo porque ilustraba bien un sistema. Ninguno muestra un problema en el que el marco no tenga nada útil que decir. Un caso escrito para que el marco lo explique no puede probar que el marco explica, aunque sirve para ensayar un protocolo.
Explicaciones rivales
Supongamos que, un año después de adoptar el vocabulario de DWU, Northstar reemplaza sus tres implementaciones de notificaciones por un único servicio compartido. Yo lo leería como la reducción de duplicación que la proposición P1 atribuye a la infraestructura cívica. Pero pudo llegar un director de tecnología nuevo que empujó la consolidación, o aprobarse por fin el presupuesto del equipo de plataforma. La empresa pudo crecer hasta que tres servicios se volvieron insostenibles, o un regulador pudo exigir trazas de auditoría de cada mensaje a clientes. También pudo madurar la práctica de arquitectura, o llegar dos ingenieros de plataforma muy buenos.
Patrocinio ejecutivo, financiamiento de plataforma, escala, presión regulatoria, madurez de arquitectura y talento son las seis explicaciones rivales que el marco reconoce. Ninguna necesita distritos ni subsuelo, y si alguna explica el cambio igual de bien, DWU le puso nombre nuevo a algo que ya se entendía. El patrocinio y el talento me preocupan más que el resto, porque pueden estar detrás de casi cualquier mejora sin dejar rastro en un inventario.
La habitabilidad tiene una rival propia, que el marco también anota. Una plataforma puede ganar adopción porque es fácil de habitar, como sostengo en habitabilidad digital, o porque su uso es obligatorio, porque hay incentivos atados a ella o porque alguien con poder lo decidió. En un tablero de uso, esas adopciones se ven iguales.
En construir evidencia antes del consenso defendí prototipar lo que se argumenta, y aquí esa postura muestra su límite. Un prototipo que funciona prueba que algo es posible; para afirmar que DWU explica algo hace falta, encima, descartar las otras seis historias.
Tres pruebas que podrían tumbarlo
Las tres pruebas discriminantes comparten una forma. Cada una pone un constructo de DWU frente a algo que ya existe y fija de antemano qué resultado lo dejaría sin razón de ser.
El marco se juzga con cuatro criterios, que son utilidad explicativa, distintividad conceptual, operacionalizabilidad y validez empírica. Leo las tres pruebas como la forma operativa de los tres primeros. La validez empírica queda para el contraste de las seis proposiciones.
Poder explicativo incremental
La jurisdicción de distrito, el gobierno de la movilidad, la densidad de asentamientos informales y la habitabilidad tendrían que explicar diferencias entre organizaciones en duplicación, fragilidad de integración o uso de herramientas sombra, más allá de lo que ya explican la madurez de arquitectura empresarial y los otros controles que el marco enumera (capacidad de plataforma, centralización del gobierno de TI, madurez digital, tamaño organizacional). En empresas como Northstar, donde BI y una aplicación de país leen tablas del ERP directamente, la pregunta sería si la fragilidad de integración (lo que se rompe cuando cambia una de esas tablas) se predice mejor con una medida de gobierno de la movilidad que con un puntaje de madurez. Si los dos predicen lo mismo, DWU es una evaluación de madurez con etiquetas urbanas.
Distintividad de constructos
La habitabilidad digital tendría que correlacionar solo moderadamente con los instrumentos genéricos de satisfacción de usuario o de aceptación tecnológica, y la densidad de asentamientos informales tendría que separarse de los inventarios convencionales de deuda técnica. La hoja de precios ajustados que circula por correo en Northstar me hace esperar esa separación, porque no vive en ningún repositorio y un inventario de deuda técnica armado desde el código difícilmente la encontraría. Un ejemplo elegido por mí, claro, no prueba nada. Si en organizaciones reales las medidas convergen por encima de los umbrales aceptados, los constructos son redundantes.
Confiabilidad inter-evaluador
Analistas independientes que clasifiquen la misma empresa en los siete sistemas deberían alcanzar un acuerdo sustancial. Si el desacuerdo persiste, el vocabulario urbano carece de la estabilidad que exige la investigación acumulativa, porque cada estudio mediría cosas distintas con los mismos nombres.
De las tres, es la única que puedo empezar a correr sin datos de ninguna organización.
Un experimento con Northstar
Dos analistas que no participaron en escribir el marco reciben el inventario de componentes de Northstar y las definiciones de los siete sistemas tal como están publicadas, y cada uno clasifica por separado. Un borrador ilustrativo del protocolo sería este.
# Ilustrativo: ronda piloto de clasificación inter-evaluador sobre el caso
# ficticio Northstar. No es un instrumento validado ni un estándar.
ronda: northstar-piloto-1
evaluadores: 2 # no participaron en escribir el marco
comunicacion_durante_la_ronda: ninguna
definiciones: rodas-lopez-2026 # las del paper, sin glosas del autor
criterio: estado_actual # lo que el componente es hoy, no lo que
# sería después de una intervención
asignacion:
sistema_primario: obligatorio # el acuerdo se calcula sobre este campo
sistema_secundario: opcional
justificacion: una_linea
componentes:
- erp
- notificaciones-ecommerce
- svc-integracion
- chequeo-politicas-integracion
- agente-compras
- maestro-proveedores
- politica-compras-entidad-a
- hoja-precios-ajustados
- indice-vectorial # solo si algún agente recupera documentos
preregistro:
estadistico_de_acuerdo: se_fija_antes_de_la_ronda
umbral_de_acuerdo_sustancial: se_fija_antes_de_la_rondaEsperaría acuerdo rápido en piezas como el ERP (edificio), Finanzas (distrito) o las cinco entidades legales (territorio). El desacuerdo previsible está en las fronteras que marca el diagrama.
DWU pone los índices vectoriales en el subsuelo, pero si alguno de los doce agentes experimentales consulta un índice construido por su propio equipo, ese índice tiene dueño, propósito, usuarios y ciclo de vida, que es como el marco describe un edificio. Los motores de políticas figuran como infraestructura pública, y un chequeo de políticas de los que Northstar reconstruye una y otra vez, si vive dentro de una integración, se lee también como regla de tránsito, es decir, movilidad. La cuenta svc-integracion es un habitante no humano según la definición, aunque solo existe para mover datos. Las reglas de compra de una entidad son jurisdicción o decisión de Cadena de suministro según quién las mire, y el maestro de proveedores deja la misma duda entre subsuelo y edificio.
El agente de compras es el caso que más me interesa. Como actor que prepara órdenes de compra, es un habitante, aunque hoy opere con credenciales heredadas de un desarrollador. Como componente desplegado con un modelo y una interfaz, es un edificio, y la tabla de diagnóstico de DWU pone las interfaces de agentes entre los edificios.
El primer riesgo es que parte del desacuerdo venga del protocolo. Las notificaciones del e-commerce son edificio si se clasifica el estado actual e infraestructura pública si se clasifica la función, y por eso el borrador fija criterio: estado_actual. La granularidad también pesa. Las definiciones ponen los registros operativos en el subsuelo, y el acuerdo que predigo para el ERP supone que nadie separa la aplicación de sus tablas. Si hicieran falta muchas reglas así para que dos analistas coincidan, eso ya sería un resultado.
El segundo riesgo es de alcance. Una ronda sobre Northstar solo ensaya el protocolo. La prueba real requiere inventarios de organizaciones reales y analistas que no hayan leído esta serie, y en ella importará tanto cuánto desacuerdo hay como dónde se concentra. Si se acumula en una o dos fronteras, pide redefinirlas. Si se reparte entre casi todos los pares de sistemas, apunta al vocabulario completo.
Qué me haría abandonar partes del marco
Si el marco falla en cualquiera de los cuatro criterios, toca estrecharlo, revisarlo o abandonar partes de él, y conservar la metáfora por razones retóricas queda descartado de antemano. Dejo por escrito qué resultado me llevaría a qué recorte, para que se me pueda reclamar.
- Si en inventarios reales el desacuerdo entre analistas se concentra en la frontera entre subsuelo y edificios, fundiría esos dos sistemas o reduciría el subsuelo a los datos compartidos con dueño propio.
- Si la habitabilidad digital converge con los instrumentos de satisfacción o de aceptación tecnológica, retiraría el constructo y usaría esos instrumentos.
- Si la densidad de asentamientos informales no se separa de la deuda técnica inventariada, el constructo sale de la teoría, aunque las cuatro respuestas (reconocimiento, integración, reubicación y retiro) sigan sirviendo en la práctica.
- Si la jurisdicción de distrito y el gobierno de la movilidad no explican nada más allá de la madurez de arquitectura, presentaría DWU como vocabulario de comunicación para arquitectos y dejaría de llamarlo teoría.
- Si un estudio retrospectivo de mi práctica documentada no encuentra en los registros de decisiones y los inventarios las huellas que mi memoria atribuye a estas ideas, trataría esa práctica como anécdota.
Aun pasando las tres pruebas, el marco tiene límites conocidos. El más serio es la sobreextensión de la analogía, que puede tapar fenómenos que se explican mejor con ecosistemas, redes, mercados, instituciones o metáforas biológicas; una analogía a la que uno le tiene cariño tiende a absorberlos todos. Los siete sistemas también son provisionales. Pueden faltar constructos (el propio marco nombra la economía digital, la sostenibilidad ambiental, las relaciones de poder, la legitimidad institucional y los ritmos temporales) y pueden sobrar otros, si resultan redundantes o se funden.
En Northstar, la ausencia que más se nota es la del poder. La tentación recurrente de comprar un producto de proveedor por distrito y llamar arquitectura al organigrama de licencias es un fenómeno de presupuesto, porque quien controla la compra termina dibujando los distritos. DWU nombra el síntoma y no tiene un constructo que explique por qué ocurre. Con la legitimidad pasa lo mismo. Un servicio compartido de identidad puede ser habitable y quedarse sin uso porque el equipo que lo opera no tiene autoridad reconocida sobre los distritos.
Queda el alcance. DWU supone una empresa mediana o grande con autoridad para fijar reglas comunes, y sus supuestos sobre agentes tendrán que revisarse contra estándares emergentes (Booth et al., 2026), porque el concepto cambia rápido.
Por dónde empezaría la validación
DWU propone validar en cuatro etapas, cada una más cara que la anterior.
- Validación de constructos con paneles de expertos.
- Desarrollo y evaluación design-science de artefactos diagnósticos (diseñar el artefacto y evaluarlo en uso), por ejemplo comparando las decisiones del canvas de diez preguntas con las de un inventario de aplicaciones, un mapa de capacidades o un checklist de riesgo de IA.
- Estudios de caso comparativos entre organizaciones.
- Pruebas cuantitativas de las seis proposiciones.
Antes de esas etapas van dos pasos previos. Una revisión sistemática reproducible responde a la debilidad del protocolo de revisión actual. El otro paso no depende solo de mí. Es un estudio de caso retrospectivo de los tres años de práctica con evidencia documentada (registros de decisiones de arquitectura o ADRs, inventarios de integración, mediciones de cycle time, registros de incidentes). Grupo Diveco es el candidato, porque ya tiene parte de esa evidencia (historial de git, un ADR, documentos de hallazgos técnicos y un log de auditoría), aunque solo desde agosto de 2025. Está condicionado a autorización organizacional, y la condición es real. Si la autorización no llega, la ruta empieza en los paneles de expertos.
Aun con autorización, ese estudio arrastra el problema de la práctica que revisa, porque lo haría yo sobre decisiones que tomé yo. Agregaría un segundo revisor que codifique los mismos documentos sin conocer mis conclusiones.
Ese segundo revisor es un caso de la regla que aplico contra el sesgo del autor en todos los estudios que propongo, que es separar roles. Clasifican y codifican personas que no escribieron el marco, los umbrales se fijan antes de ver datos y las explicaciones rivales entran como controles desde el diseño. Eso cuesta. La validación es lenta, depende de permisos que no controlo, y mientras tanto sigo usando el marco en mi trabajo, lo que alimenta el sesgo que intento contener. Para eso no tengo una salida limpia, más allá de declararlo.
La prueba que más me inquieta es la tercera, porque es la más barata. Un equipo de arquitectura puede correrla con su propio inventario, dos personas que no hayan leído esta serie y las definiciones publicadas de los siete sistemas, sin pedirle permiso a nadie. Si alguien lo hace y el desacuerdo cae donde no lo predije, ese resultado me enseñará más que los once posts anteriores.
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: Canvas de urbanización digital: diagnóstico en 10 preguntas.