Zonificar la empresa por capacidades de negocio es repartir la autoridad sobre su mundo digital en tres capas, y en este orden. Primero el territorio, que fija dónde aplica cada regla legal y de riesgo; después los distritos, que agrupan capacidades con un mismo dueño y un mismo vocabulario; al final los edificios, es decir, las aplicaciones, servicios y modelos, cada uno con una ficha que dice para qué existe y en qué estado está. El mapa de capacidades de negocio es el instrumento para trazar los distritos. La zonificación le añade el suelo jurídico que va debajo y el inventario vivo que va encima.
Para aterrizarlo uso Northstar Consumer Group, un caso ficticio que retomo en toda la serie. Sus cinco entidades legales, en cinco países de una misma región, comparten un ERP, una plataforma de datos en la nube y las plataformas de clientes y de fuerza laboral, y cada una enfrenta fronteras regulatorias y de riesgo distintas. Sobre esa base común, Northstar calcula el margen de tres maneras y nadie ha decidido quién puede ver los clientes de cada entidad.
Lo que Northstar hereda por defecto
Un territorio puede contener varias jurisdicciones con reglas propias apoyadas sobre la misma infraestructura común, y la urbanización empieza por decir dónde aplica cada una. Cuando nadie lo dice, el marco anticipa tres consecuencias, y las tres las he visto en plataformas compartidas. Las plataformas conceden acceso global, porque es la opción por defecto. La lógica de cada país se reproduce de forma inconsistente en varios lugares. Aparecen servicios que nadie sabe a quién pertenecen.
En Northstar la herramienta de BI consulta tablas del ERP directamente, y la aplicación de uno de los países también. Si el territorio no está dibujado, esas consultas heredan un alcance global. Un analista de una entidad podría ver clientes de otra sin que nadie lo haya decidido, y el día que alguien pregunte si eso es aceptable no habrá a quién preguntarle.
La segunda consecuencia se ve en el margen, que Northstar calcula de tres maneras, la del cierre de Finanzas, la del dashboard comercial y la de la aplicación de un país. Cada cálculo es correcto dentro de la aplicación que lo produce. El problema aparece cuando la dirección compara dos informes y encuentra dos números.
La tercera se pierde en el inventario. Los inventarios de aplicaciones que conozco tratan todo lo que existe como permanentemente válido, y esa uniformidad esconde lo que de verdad cuesta dinero y riesgo, como el script que nadie mantiene, el dashboard duplicado o la aplicación que se compró para un proyecto ya cerrado.
Territorio, distritos y edificios
Territorio, distritos y edificios son tres de los siete sistemas en que la Urbanización del Mundo Digital (DWU, por sus siglas en inglés) organiza la empresa como un territorio habitado, y son los tres que dan forma a la ciudad. La partición tiene antecedentes. La tradición de urbanizar sistemas de información ya dividía el sistema en zonas, barrios y bloques, y DWU la retoma en sus distritos.
El territorio es el contexto estratégico e institucional del mundo digital empresarial. Abarca las entidades legales, los países, las unidades de negocio, las restricciones regulatorias, la residencia de los datos, el apetito de riesgo y la frontera con el exterior. DWU lo llama la capa constitucional, y su primer principio, la coherencia territorial, pide que todo componente opere dentro de fronteras organizacionales, regulatorias y de riesgo definidas. La intervención que se desprende parece modesta, con etiquetas de jurisdicción, restricciones de residencia de datos, apetito de riesgo y derechos de decisión definidos por territorio. Es trabajo de inventario y de acuerdos, con muy poca tecnología, y suele posponerse porque no deja nada que mostrar en una demo.
Cada distrito es una capacidad o un dominio de negocio coherente, con alguien que responde por su evolución. Northstar tiene cuatro: Comercial, Cadena de suministro, Finanzas y Personas. El segundo principio del marco, la zonificación por capacidades, pide organizar las estructuras alrededor de capacidades y dominios estables, por encima de productos de proveedor y proyectos transitorios. Es la misma intuición de la propiedad orientada a dominio y del gobierno federado que Dehghani (2020) propone para los datos, extendida a todo lo que el distrito posee.
Los edificios son las aplicaciones, productos internos, interfaces analíticas, APIs, modelos y componentes de servicio que entregan capacidades. Cada uno debería tener definidos siete atributos: propósito, propietario, habitantes (los actores humanos y no humanos que lo usan o lo alimentan), ciclo de vida, costo, dependencias y obligaciones de cumplimiento.
El atributo que cambia la conversación es el estado. El marco distingue cuatro y pide hacerlos explícitos; las definiciones de trabajo que siguen son mías. Un hito estratégico es un edificio en el que la empresa quiere seguir invirtiendo. Una estructura temporal resuelve algo hoy y tiene fecha de revisión desde el día en que se registra. Una instalación legada sigue sosteniendo procesos, pero ya nadie quiere que crezca y tarde o temprano habrá que renovarla o sustituirla. Una propiedad abandonada sigue corriendo sin un dueño que responda por ella. Registrar el estado obliga a elegir uno de los cuatro, cosa que el inventario uniforme nunca exigió.
El diagrama junta las tres capas para Northstar. El ERP aparece dos veces a propósito, porque su módulo de compras vive en Cadena de suministro y su módulo de cierre en Finanzas, cada uno con su propio dueño.
Del mapa a la ficha
Trazar la frontera de un distrito
La prueba que uso para saber si una frontera está bien trazada es semántica. Dentro de un distrito coherente, las palabras importantes significan una sola cosa y hay una persona que responde por ese significado. Con sus tres márgenes, Northstar falla la prueba de inmediato.
Trazar distritos a partir de la historia de las aplicaciones reproduce ese estado. Pongamos que el dashboard comercial nació con su propio cálculo de margen porque en su momento era más rápido que pedírselo a Finanzas. Un mapa que dibuje un distrito alrededor de cada aplicación existente convierte ese atajo en frontera oficial. El mapa de capacidades de negocio sirve para romper esa inercia, porque pregunta primero qué hace la empresa (vender, abastecer, cerrar el mes, pagar a su gente) y solo después qué aplicaciones lo hacen.
Donde dos distritos se tocan siempre hay una traducción. Comercial habla de clientes y Finanzas de deudores, y la misma empresa compradora es las dos cosas a la vez. Esa frontera necesita un contrato y alguien que lo mantenga, igual que la frontera entre un canal digital y un ERP legado que describí en SAP ECC como API. Con traducción explícita, la frontera aguanta. Los tres márgenes de Northstar vienen de lo contrario, de consultas directas a tablas del ERP que cada aplicación interpreta a su manera.
El organigrama de licencias
Una tentación recurrente en Northstar es comprar un producto de proveedor por distrito. Una suite comercial para ventas, otra para cadena de suministro, el ERP para finanzas y una plataforma de capital humano para personas. El diagrama resultante se parece a un mapa de capacidades, con cuatro cajas y cuatro nombres, y se presenta como arquitectura. Lo que dibuja es el organigrama de licencias.
Las fronteras de un producto responden a cómo el proveedor empaqueta su mercado. Una suite suele traer maestro de clientes, motor de notificaciones y modelo de permisos propios, porque tiene que funcionar sola en cualquier empresa que la compre. Northstar ya tiene tres implementaciones distintas de notificaciones. Un organigrama de licencias institucionaliza esa duplicación, porque cada caja del diagrama la trae de fábrica. Qué debería ser común entre distritos, y en qué orden madurarlo, es el tema del siguiente texto de la serie.
Comprar productos es legítimo, siempre que la compra ocurra después de trazar el distrito y el producto quede registrado como un edificio suyo, con un dueño interno que responda por él.
La ficha de cada edificio
La ficha ilustrativa que sigue corresponde a la aplicación low-code de visitas de campo que creó un gerente regional de Northstar, un asentamiento digital informal en el vocabulario del marco (una solución útil creada fuera de la arquitectura y de los controles compartidos). Registrarla es el primer paso. Por qué a esta app le bastaría el reconocimiento, una de las cuatro respuestas que DWU prevé para los asentamientos, lo explico en shadow IT como asentamiento informal.
# Ficha ilustrativa del registro de edificios de Northstar.
# Los nombres de campo son míos; no siguen ningún estándar.
edificio: app-visitas-campo
proposito: registrar visitas de vendedores a puntos de venta
distrito: comercial
jurisdiccion:
entidades: [entidad-c] # hoy solo la usa una de las cinco
residencia_datos: reglas-de-entidad-c
propietario:
responsable: gerencia-regional-comercial
patrocinador: direccion-comercial
habitantes:
- vendedores de campo
- supervisores regionales
origen: asentamiento-informal # low-code, creada fuera del plan
estado_ciclo_vida: estructura-temporal
dependencias:
- maestro-de-clientes # hoy, copia manual desde el ERP
costo: licencia low-code y horas del gerente, sin medir
obligaciones:
- datos personales de contactos en puntos de venta
decision_renovacion:
opcion: reconocimiento # ante un asentamiento: reconocimiento | integracion | reubicacion | retiro
motivo: ya corre en terreno formal y la adopción es real; le faltaban dueño y revisión
revisar_en: siguiente ciclo de portafolio del distritoDos campos generan casi toda la discusión cuando se llena una ficha así.
La jurisdicción ata el edificio al territorio. Si la aplicación solo opera en la entidad C, le aplican las reglas de residencia de datos de esa entidad. Si mañana otra entidad la quiere, esa ampliación es una decisión territorial y la ficha obliga a tomarla, en vez de resolverla copiando la aplicación y su base de datos a un segundo país.
La decisión de renovación le pone fecha al edificio. Sin ella, lo temporal se vuelve permanente por inercia, y la aplicación de visitas termina siendo, dentro de unos años, una instalación legada que nadie eligió. Esa deriva sin decisión es una de las formas en que se acumula deuda urbana, el costo estructural que después restringe el cambio. El campo de costo dice «sin medir», y así dirán muchas fichas al principio. Prefiero eso a un número inventado, porque deja a la vista dónde falta información.
La dependencia del maestro de clientes apunta hacia abajo, al subsuelo (los datos, metadatos, linaje y semántica de los que dependen los edificios), que trato en el subsuelo de datos que nadie ve. La definición de cliente o de margen tiene su dueño en el distrito y se implementa allí abajo.
Común, federada o local
El séptimo principio del marco, subsidiariedad con federación, dice que cada decisión se toma en el nivel de dominio competente más bajo, mientras las políticas de la ciudad preservan la interoperabilidad y la confianza. DWU no prescribe centralización; exige decidir de forma explícita qué capacidades son comunes, federadas o localmente autónomas. Conviene decidirlo antes de asignar edificios. Para distinguir las tres categorías uso un criterio propio, que es quién fija la regla y quién la implementa.
Una capacidad común la provee la ciudad como servicio compartido para todos los distritos, como la identidad o las notificaciones que hoy Northstar tiene triplicadas. Una capacidad federada tiene un distrito dueño que la implementa y una regla de ciudad que los demás respetan. La definición de margen sería de Finanzas, y cualquier informe que diga «margen» usaría esa definición o tendría que declarar otro nombre. Una capacidad local la decide el distrito por su cuenta, y la ciudad solo le pide que aparezca en el registro y que use los servicios comunes. La aplicación de visitas puede seguir siendo local aunque quede registrada con dueño, porque reconocer el edificio y centralizar la capacidad son decisiones distintas.
El caso de Grupo Diveco
En Portal Diveco, la plataforma de Grupo Diveco cuyo origen conté en el primer artículo, cada herramienta entra por un registro único, que es de donde el portal arma su navegación y aplica los permisos. En septiembre de 2026 ese registro tenía 51 herramientas repartidas en 16 categorías de negocio. La zonificación se ve mejor en la maqueta 3D de la plataforma, donde el Distrito 1, «Condominio Portal Diveco», se divide en ocho sectores por capacidad (Reportes, Administración, Ventas, Operaciones y SAP, Gestión y Mesa de Ayuda, IA, Finanzas y Personas) y el Distrito 2 es Capital Humano.
El mismo mapa, que ilustra el mecanismo sin medirlo, muestra también dónde se rompe el criterio. Otros distritos de la maqueta se trazan por plataforma (RPA, el puerto cloud, IA y SAP), con la frontera puesta por la tecnología que sostiene los edificios, un pariente cercano del organigrama de licencias. Las 16 categorías del registro sirven para navegar, pero ninguna tiene un dueño de distrito declarado, de modo que no pasan la segunda mitad de la prueba semántica, la que pide una persona que responda por el significado. El registro guarda de cada herramienta el nombre, la categoría, la descripción, los permisos de acceso y un indicador de oculto. Le faltan el propietario, el estado de ciclo de vida y la decisión de renovación, justo los campos que en la ficha de Northstar obligan a decidir.
Agregar esas columnas es poco trabajo técnico. Llenarlas exige nombrar dueños y derechos de decisión que hoy no están documentados.
Las señales que pondrían a prueba P2
La proposición que corresponde a este texto es P2. Plantea que los entornos organizados en distritos por capacidades mostrarán mayor alineación entre la propiedad estratégica y la evolución de las aplicaciones que los entornos organizados alrededor de sistemas individuales. Como todo lo que plantea el preprint, es una hipótesis sin validación empírica. Se contrastaría con mapas de capacidades, con la claridad de la propiedad y con el historial de cambios del portafolio.
Si P2 es correcta, en una empresa como Northstar esperaría observar tres señales. Los cambios a la definición de margen pasarían por Finanzas, y el dashboard comercial dejaría de mantener un cálculo propio. Las aplicaciones nuevas que pide Comercial aparecerían registradas en su distrito, con dueño, en lugar de nacer donde hubo presupuesto ese trimestre. Con el paso de los ciclos de portafolio habría menos edificios sin dueño. Si nada de eso cambia después de zonificar, o si cambia igual en una empresa comparable que no zonificó, P2 pierde fuerza.
Una mejora de alineación también puede venir de una presión regulatoria que obligó a ordenar, una de las explicaciones rivales que el propio DWU reconoce. Separar ese efecto del de la zonificación exige comparar organizaciones, y ese trabajo está pendiente.
Cuando la frontera se vuelve muro
La zonificación mejora la accountability porque cada capacidad tiene dueño, y ese dueño tiene ahora un territorio propio que defender. El asistente analítico de cobranza de Northstar necesita datos de clientes, que pertenecen a Comercial, y datos de deuda, que pertenecen a Finanzas. Con distritos bien trazados, esa consulta cruza una frontera, y cruzarla exige un contrato, una conversación y a veces una espera de semanas. Si los dueños de distrito se miden solo por sus propios indicadores, la frontera se convierte en muro y la zonificación refuerza los silos que pretendía ordenar.
DWU pide tratar esta tensión como un moderador y un trade-off explícito. En la práctica, para mí eso significa medir a cada dueño de distrito también por los contratos que ofrece a los demás.
Donde lo he aplicado, dibujar los distritos fue siempre la parte rápida, y acordar quién decide en cada frontera tomó bastante más tiempo. Para una organización pequeña, con uno o dos sistemas y fronteras estables, todo esto es burocracia, y el marco mismo se declara menos útil en ese caso.
Quién firma cada categoría
La clasificación en común, federada o local no sale del mapa de capacidades, que solo dice qué capacidades existen. Decidir cuáles son comunes, cuáles federadas y cuáles locales reparte poder y presupuesto, y alguien con autoridad sobre el territorio tiene que tomar esa decisión y firmarla. Una capacidad sin categoría queda como local por omisión en cada distrito a la vez, y esa es la situación de Northstar, con tres cálculos de margen y tres servicios de notificaciones.
Para la próxima revisión de portafolio propongo empezar por una lista corta, la de las capacidades que hoy tienen más de una implementación. Frente a cada una hay que escribir si es común, federada o local, y el nombre de quien firma esa respuesta.
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 tradición olvidada de urbanizar sistemas de información. Siguiente: Infraestructura antes que densidad: servicios compartidos.