Canvas de urbanización digital: diagnóstico en 10 preguntas

El canvas de urbanización digital es una hoja de diez preguntas para hacer un diagnóstico de arquitectura empresarial de todo un territorio digital a la vez. Siete preguntas recorren los sistemas del marco (territorio, distritos, edificios, infraestructura pública, movilidad, subsuelo y habitantes) y tres miran lo que esos sistemas producen juntos: la habitabilidad, los asentamientos informales y la deuda urbana.

Lo uso para sentar en la misma mesa a quienes suelen evaluar por separado las aplicaciones, los datos, las plataformas y los agentes, y para que cada respuesta salga de algo que otra persona pueda revisar después.

Viene del Apéndice A de mi preprint sobre la Urbanización del Mundo Digital, DWU (Rodas López, 2026), que resumo en la página del paper. Es un artefacto de práctica que fui refinando al usarlo en mi trabajo de arquitectura de plataformas empresariales. Todavía no es un instrumento validado, y el paper deja su evaluación formal como trabajo futuro. Este es el penúltimo artículo de la serie sobre urbanización digital. Junta en una hoja lo que los anteriores desarrollan por separado, la llena con Northstar Consumer Group, la empresa ficticia que recorre la serie, y propone cómo averiguar si el canvas sirve para algo más que ordenar una conversación.

Diez celdas en una hoja

La disposición repite la lógica relacional del marco. El territorio (la estrategia, las jurisdicciones, la regulación y el apetito de riesgo) ocupa la franja superior porque acota todo lo demás. Debajo están los distritos, que son las capacidades de negocio con dueño, los edificios que las entregan (aplicaciones, productos, servicios y modelos) y los habitantes, sean personas, sistemas o agentes. Los edificios dependen de la fila siguiente. La infraestructura pública son los servicios compartidos de identidad, auditoría, observabilidad y notificaciones, y la movilidad son las APIs, eventos, colas y contratos por donde viajan datos y órdenes. Al fondo queda el subsuelo, los productos de datos, la semántica y el linaje que casi nadie ve y de los que depende casi todo.

Las tres celdas de abajo son de otra clase, y por eso van aparte y con borde discontinuo. Ninguna se construye de forma directa. La habitabilidad digital es el grado en que el entorno es usable, comprensible, confiable, accesible y seguro para quienes trabajan en él. Un asentamiento digital informal es una solución localmente útil creada fuera de la arquitectura, el gobierno, la propiedad o los controles de ciclo de vida compartidos. La deuda urbana es el costo estructural que dejan la infraestructura fragmentada, las capacidades duplicadas, los flujos opacos, los componentes abandonados y las excepciones de gobierno.

En la lógica causal del paper la habitabilidad es una condición intermedia entre los mecanismos de diseño y los resultados organizacionales, así que juntarla con las otras dos es decisión mía. La tomé porque en un taller las tres se diagnostican igual, por los síntomas que dejan los siete sistemas.

El diseño de cada edificio queda fuera de la hoja, como en la tradición francófona de urbanización de sistemas de información, donde el urbanista no diseñaba edificios y se ocupaba del uso del suelo, la infraestructura compartida, las fronteras, las interfaces y las reglas de evolución. Lo conté en la tradición olvidada de urbanizar sistemas de información.

Evidencia que otro pueda abrir

Un canvas llenado de memoria en una sala de reuniones da un retrato fiel de lo que creen los presentes. Ese retrato sirve para empezar y engaña si se presenta como diagnóstico. La regla que sigo es que cada anotación cite una fuente que otra persona pueda abrir (un registro, un log, un inventario, un ADR, una encuesta) y que lo afirmado sin fuente se anote aparte, como hipótesis del taller, hasta que alguien la confirme o la descarte. Es la misma disciplina de construir evidencia antes del consenso, aplicada a un diagnóstico.

Las fuentes salen del paper. Cada una de sus seis proposiciones trae un tipo de evidencia ilustrativa, y el diagnóstico hipotético de Northstar propone, sistema por sistema, una intervención que a menudo es un registro por crear (etiquetas de jurisdicción, un registro de edificios, otro de actores con patrocinador). La fila de deuda urbana la completé con la evidencia que el paper prevé para su primer estudio de caso, como ADRs, mediciones de cycle time y logs de incidentes. La tercera columna es la que más uso en los talleres, porque recoge frases que suenan a hallazgo y todavía no lo son.

Cualquiera de esas frases puede ser cierta. Lo que la sala no puede saber es cuál, y la versión que se escribe en la celda termina siendo la que se defiende en el comité de arquitectura.

En la práctica registro cada celda como un documento pequeño. El formato es mío y es ilustrativo, y lo que importa son los campos.

# Ilustrativo. Una celda del canvas de Northstar (caso ficticio); el formato no es un estándar.
celda: 5-movilidad
pregunta: "¿Cómo se mueven datos, comandos, eventos y aprobaciones?"
evidencia:
  - fuente: inventario de integraciones
    observacion: varias integraciones se autentican con la cuenta compartida svc-integracion
  - fuente: conexiones registradas contra la base de datos del ERP
    observacion: la herramienta de BI y la aplicación de un país leen tablas del ERP directamente
hipotesis_del_taller:
  - afirmacion: "todo pasa por la capa de integración"
    estado: contradicha por la segunda observación
depende_de:
  - celda: 7-habitantes
    motivo: "la cuenta compartida es un habitante; ¿quién la patrocina?"
  - celda: 6-subsuelo
    motivo: "¿el margen de la aplicación de país sale de esa lectura directa?"
sin_evidencia:
  - tasas de falla por integración
  - lead time de cambio
decision_que_informa: promover o no el agente de compras

El campo que más trabajo da es depende_de. Obliga a anotar que un hallazgo de movilidad no se resuelve dentro de la movilidad, porque la cuenta compartida es también un problema de habitantes y la lectura directa puede estar alimentando uno de los tres márgenes. Un inventario de integraciones registraría las dos observaciones y ninguna de las dos preguntas.

Northstar, celda por celda

Las siete primeras filas resumen el diagnóstico hipotético que el paper hace de Northstar, con los detalles que añadí para esta serie, y las tres últimas las completé con el mismo material. Cada dimensión enlaza al artículo donde la desarrollo (las tres primeras comparten uno).

Dos filas dicen más que las otras. La octava está vacía porque en el caso no hay una sola fuente sobre si la gente puede trabajar con lo que tiene. La impresión de quien facilita el taller va a la lista de hipótesis. Lo único que apunta hacia la celda está en la novena. El marco lee la hoja de precios y la app de visitas como señales de una necesidad que la ciudad formal (lo que sí está gobernado) no atendió a tiempo, y eso cuenta como indicio de baja habitabilidad hasta que alguien la mida.

La décima se llenó casi entera con referencias a otras celdas. Puede significar que la deuda urbana, como dimensión del canvas, es un agregado de las demás y sobra como celda propia. También puede significar que tiene evidencia propia, como las excepciones de gobierno abiertas o los tiempos de cambio, que en Northstar nadie ha reunido. No sé cuál de las dos lecturas es la correcta. En un caso real empezaría por buscar esas excepciones antes de discutir si la celda sobra.

Lo que aparece entre las celdas

El agente de compras de Northstar, el que prepara órdenes de compra y hoy actúa con credenciales heredadas de un desarrollador, ya apareció en el primer artículo como ejemplo de un cambio que reparte decisiones entre los siete sistemas. Aquí interesa qué registran tres instrumentos distintos cuando alguien pide llevarlo a producción.

El inventario de aplicaciones tiene una fila para el agente, con dueño, proveedor y costo. Un mapa de capacidades lo ubicaría en el distrito de Cadena de suministro, bajo compras. Un checklist de riesgo de IA pregunta por la calidad del modelo, el sesgo, la alucinación, el prompt injection, la fuga de datos y las acciones inseguras. Son preguntas necesarias, y el paper las da por vigentes; lo que propone es situarlas dentro de la identidad, la jurisdicción, la infraestructura y la responsabilidad operativa.

En el canvas el agente ocupa la celda 7, y la pregunta «¿lo promovemos?» se reparte por otras cinco. El paper usa casi este mismo ejemplo para explicar por qué los siete sistemas son interdependientes. Introducir un agente autónomo de compras puede exigir cambios en la política territorial, la propiedad del distrito, los servicios públicos de identidad, el acceso a datos, los contratos de movilidad y la observabilidad. Cada uno de los otros instrumentos cubre una o dos de esas celdas, y ninguno tiene dónde anotar que una depende de otra.

Esas dependencias ordenan el trabajo. Darle al agente una identidad propia (celda 7) supone que el servicio de identidad sepa emitir y auditar identidades no humanas (celda 4), y acotar sus permisos por jurisdicción supone saber con las reglas de cuál entidad opera (celda 1) y quién lo patrocina (celda 2). La ruta por la que su orden llega al ERP (celda 5) y los datos de proveedores que lee (celda 6), las dos flechas discontinuas del diagrama, vienen después, porque su alcance depende de lo resuelto en las celdas 1 y 2. Ninguna de las tres listas de hallazgos, leída por separado, produce esa secuencia. El perfil del agente en sí lo desarrollo en gobierno de agentes de IA.

Todo esto es mi hipótesis sobre por qué el canvas ayudaría a decidir mejor. Nadie la ha puesto a prueba.

Cómo pondría a prueba el canvas

Si el canvas sirve, debería notarse en las decisiones que produce, más que en lo completo que queda. El paper propone para el marco una ruta de validación en cuatro etapas, y la segunda es el desarrollo y la evaluación design science de artefactos diagnósticos como este. Para el canvas sugiere comparar las decisiones producidas con él contra las producidas con un inventario de aplicaciones, un mapa de capacidades o un checklist de riesgo de IA.

Yo armaría esa comparación con un caso documentado, el mismo paquete de evidencia para todos y cuatro grupos de analistas, uno por instrumento. Cada grupo respondería las mismas preguntas de decisión, por ejemplo si se promueve un agente y con qué condiciones, o qué servicio compartido se financia primero. Después se compararían las condiciones previas que cada grupo nombra fuera del área de la decisión y el orden de trabajo que propone.

Si el canvas aporta algo, esperaría que sus grupos nombren más condiciones previas en otras dimensiones y propongan una secuencia distinta. Contarían en contra tres resultados, empezando por que las decisiones con el canvas no se distingan de las del inventario. El segundo sería que la diferencia desaparezca cuando los otros grupos reciben el mismo tiempo y la misma mezcla de personas, porque entonces la mejora vendría del taller. El tercero, que dos grupos con canvas y la misma evidencia lleguen a decisiones incompatibles.

En una organización real, un estudio así depende además de obtener autorización para usar su evidencia.

Dónde falla y dónde sale caro

Dos evaluadores, dos canvas

El tercer resultado adverso es el que más me preocupa, porque se apoya en la prueba de confiabilidad inter-evaluador que el paper le pone a todo el marco, y que desarrollo en el último artículo de la serie. Si dos evaluadores no ubican lo mismo en las mismas celdas, el canvas hereda esa inestabilidad.

En Northstar hay candidatos claros al desacuerdo. El script nocturno que concilia pedidos es una ruta de movilidad y también un asentamiento informal. La cuenta svc-integracion puede anotarse como habitante, como falla de la infraestructura pública de identidad o como síntoma de una movilidad sin contratos. La app low-code de visitas de campo es un edificio para un evaluador y un asentamiento para otro.

En los talleres lo resuelvo dándole a cada elemento una celda principal y referencias en las demás. Para conducir la conversación me alcanza.

Para medir, empeora las cosas, porque dos evaluadores pueden coincidir en las referencias y discrepar en la celda principal sin que la hoja lo muestre. A quien use el canvas para investigar le pediría que registre esos desacuerdos como dato antes de resolverlos.

Cuando el canvas se vuelve trámite

El noveno principio del marco pone la habitabilidad por encima de la completitud de artefactos. Un canvas es un artefacto, y puede violar ese principio con la misma facilidad que un diagrama de estado objetivo. Basta con que una organización lo exija como requisito de una puerta de proyecto. A partir de ahí alguien lo completa la noche anterior y el comité lo aprueba porque está completo.

Ese canvas se reconoce porque tiene las diez celdas llenas, ninguna marcada «sin evidencia», y no termina en una decisión ni lleva fecha. Para no producirlo me impongo cuatro reglas. Cada canvas responde a una sola decisión concreta. Termina con decisiones que tienen dueño y fecha. Una celda sin evidencia se deja vacía y marcada. Y el canvas vence, porque el territorio sigue cambiando; en Northstar bastaría con que un país adopte un servicio compartido de notificaciones para que la celda 4 quede desactualizada.

Hay un costo que esas reglas no quitan. Reunir evidencia lleva más tiempo que llenar la hoja de memoria, y en muchas organizaciones la evidencia todavía no existe, porque nadie lleva un registro de agentes, un inventario de integraciones o un linaje. El riesgo es que el canvas se convierta en la excusa para construir todos esos registros antes de decidir nada. Cuando el canvas tarda más que la decisión que debía informar, prefiero decidir con celdas vacías y dejar anotado qué registro faltó.

Anotar lo que no encaja

Las diez preguntas están en el apéndice del paper y en la tabla de Northstar, y se pueden usar tal cual. Lo que más me sirve de quien las usa es lo que no encajó, sea un elemento que pedía dos celdas, una celda que quedó vacía en todos los talleres o algo que necesitó una undécima celda escrita a mano. El propio paper admite que a la estructura de siete sistemas podrían faltarle constructos, entre ellos uno para las relaciones de poder, y que algunos sistemas podrían fusionarse. Esas anotaciones al margen son la clase de evidencia que necesita el último artículo de la serie, cómo sabría que esta teoría está equivocada.

En un taller, la falta de ese constructo se nota enseguida. Cuando alguien con más autoridad en la sala corrige las respuestas de los demás, el canvas registra su versión como si fuera la de todos. Por eso anoto junto a cada celda quién la llenó, además de la evidencia, para que al menos se vea de quién es cada respuesta.