Una integración punto a punto conecta dos sistemas por un camino que solo conocen quienes lo abrieron. Cuando nadie la regula, se comporta como una carretera improvisada que atraviesa propiedad privada. Resuelve el viaje de hoy y, a medida que otros equipos abren los suyos, produce congestión, dependencias ocultas y cruces inseguros. La Urbanización del Mundo Digital (DWU) propone moverla, cuando importa, a rutas que se pueden descubrir, observar y cambiar mediante contratos explícitos, sin prohibir que los equipos locales sigan construyendo.
En Northstar Consumer Group, la empresa ficticia con la que ilustro esta serie, el equipo que mantiene el ERP separó en dos la columna de estado de la tabla de pedidos para distinguir los pedidos confirmados de los confirmados en parte. El cambio pasó sus pruebas. A la mañana siguiente, el dashboard comercial, que se alimenta de la herramienta de BI, mostraba menos pedidos confirmados que el día anterior, sin ningún error a la vista. La aplicación de uno de los países (el país C, como en el artículo anterior) dejó de mostrar el estado de los pedidos. Y el script nocturno que concilia pedidos, que no figuraba en ningún inventario, amaneció con diferencias. Nadie en el equipo del ERP sabía que la aplicación del país C leía esa tabla. En los registros de la base de datos, todas las lecturas de esa tabla tenían un solo nombre, svc-integracion, la cuenta de servicio que comparten varias integraciones.
En términos urbanos, lo que falló esa mañana fue la movilidad.
El atajo por la propiedad privada
Una tabla del ERP es el interior de un edificio. DWU llama edificios a las aplicaciones, productos y servicios que entregan capacidades, y cada uno debería tener propósito, propietario, dependencias y ciclo de vida definidos. Sus tablas internas se diseñaron para el uso del propio edificio. Cuando la herramienta de BI de Northstar lee la tabla de pedidos directamente, entra por la puerta trasera de una propiedad cuyo dueño nunca aceptó visitas y ni siquiera sabe que las recibe.
El atajo gana siempre la primera comparación. No hay que pedir permiso, no hay cola en el equipo de plataforma y la consulta SQL funciona esa misma tarde. En los últimos años, trabajando en arquitectura de plataformas empresariales, construí algunos de esos atajos y aprobé otros, casi siempre con la misma justificación («es solo lectura»). Para quien lo abre, el camino directo es barato. El costo aparece después, y lo pagan el dueño del edificio y los consumidores que se rompen cuando él cambia su interior.
El marco atribuye a los caminos improvisados tres consecuencias, y Northstar tiene un ejemplo de cada una.
La congestión aparece cuando varios caminos no planificados cargan la misma estructura. El dashboard comercial, la aplicación del país C y el script de conciliación consultan las tablas que usa la operación diaria del ERP, y ninguna de esas cargas figura en la planificación de capacidad de nadie. Si la base se pone lenta un fin de mes, el equipo del ERP ve consultas pesadas firmadas por svc-integracion y no tiene a quién llamar.
El episodio de la columna es el caso típico de las dependencias ocultas. Un dueño cambia el interior de su propio edificio y rompe a consumidores que no sabía que existían. El caso más caro de los tres fue el del dashboard, que siguió mostrando números sin avisar que estaban mal. Una integración que falla con un error se repara ese mismo día; una que devuelve datos plausibles e incorrectos puede alimentar decisiones durante semanas.
La cuenta compartida produce los cruces inseguros. Para que todas las integraciones funcionen, svc-integracion tiene que acumular la unión de los permisos que necesita cada una, así que el mínimo privilegio queda descartado desde el diseño. Revocarla detiene todas a la vez. La atribución, que es lo primero que se necesita en un incidente, se vuelve imposible por construcción. En infraestructura antes que densidad trato la identidad como infraestructura pública. Cuando no existe como servicio compartido, cada equipo reutiliza la credencial que tiene a mano.
La literatura sobre deuda técnica y digital asocia las integraciones fuertemente acopladas y las excepciones no gestionadas con restricciones al cambio futuro (Ramasubbu y Kemerer, 2016; Rolland et al., 2018). El vocabulario urbano añade la ubicación. La deuda de Northstar vive en el camino entre el ERP y sus lectores, un lugar que ningún inventario de aplicaciones registra porque el camino no pertenece a ninguna aplicación.
Qué hace gobernada a una ruta
Los medios de transporte de una empresa
La movilidad es la forma en que se mueven la información, los comandos, los eventos y el trabajo entre las partes de la empresa. El marco asigna a cada mecanismo de integración un equivalente urbano, y la analogía sirve en la medida en que cada equivalente dice algo sobre quién mantiene la ruta y quién puede usarla.
| Medio urbano | Equivalente en la empresa | Qué aporta la analogía |
|---|---|---|
| Carreteras | APIs | Tienen un dueño que las mantiene, señalización y reglas de acceso; cada viajero decide cuándo sale |
| Transporte público | Streams de eventos y colas | Quien publica no conoce a cada pasajero; la capacidad y el horario se diseñan para muchos |
| Rutas coordinadas | Motores de workflow | Viajes de varios tramos, con transbordos y paradas de aprobación |
| Reglas de tránsito | Contratos y esquemas | Aplican a todos por igual, y sin ellas nadie puede exigir nada |
La tabla sería un juego de correspondencias si no obligara a hacer preguntas que un diagrama de integraciones suele omitir. Una carretera tiene un responsable de mantenimiento, y en Northstar nadie habría podido nombrar al de la ruta por la que salen los pedidos del ERP. El operador de transporte público no conoce a cada pasajero, pero sabe cuántos viajan; el equipo del ERP no sabía cuántos consumidores tenía su tabla de pedidos. Y las reglas de tránsito existen antes del accidente. El día que cambió la columna, ningún contrato regía esa tabla. Tenía una forma, y tres consumidores dependían de ella sin que nadie la hubiera prometido.
En cómo extender un SAP ECC con una capa de integración miraba desde el ERP hacia afuera. La movilidad mira el territorio completo y pregunta qué rutas existen y quién responde por cada una.
Cuatro propiedades de una ruta gobernada
El cuarto de los diez principios de DWU, movilidad gobernada, pide que la información y las acciones viajen por rutas descubribles, observables y basadas en contratos. La calidad de la movilidad se define con cuatro propiedades, que conviene leer con el caso de la columna en la mano.
Una ruta es descubrible cuando un equipo que necesita los pedidos confirmados puede encontrarla, con su contrato, sin preguntar en el pasillo. Es confiable cuando tiene un nivel de servicio publicado y un comportamiento conocido ante fallas. Es observable cuando su dueño puede ver quién viaja por ella, con qué volumen y con qué errores. En Northstar, esa última propiedad habría bastado para que el equipo del ERP supiera que la aplicación del país C existía antes de tocar la columna.
La cuarta propiedad es la más fácil de leer mal. Se llama acoplamiento apropiado, y el adjetivo importa, porque admite que cada flujo necesita un grado distinto de acoplamiento. La aplicación del país C necesita el estado actual de un pedido cuando un vendedor lo consulta, y para eso una API síncrona, con el acoplamiento temporal que implica, es la ruta correcta. Es el patrón que describí en SAP ECC como API, una capa anti-corrupción que traduce el modelo interno del ERP a un contrato estable y que, en el vocabulario de esta serie, es una carretera con dueño.
El dashboard comercial necesita otra cosa. Busca un conjunto de pedidos con definición estable, historia y fecha de corte, y eso se parece más a un producto de datos que a una integración. Es terreno del subsuelo (los datos, metadatos, linaje y semántica de los que dependen las aplicaciones), que trato en el subsuelo de datos que nadie ve. El script de conciliación, por su parte, quiere enterarse de cada pedido confirmado cuando ocurre, y un evento le sirve mejor que leer la tabla cada noche.
Son tres consumidores en tres rutas distintas, cada una con contrato.
La ruta de los pedidos en Northstar
El contrato del evento de pedido confirmado
Así podría verse el contrato del evento de pedido confirmado. Sigue la forma general de AsyncAPI con extensiones propias (los campos que empiezan con x-) y es solo ilustrativo.
# Ilustrativo. Northstar Consumer Group es un caso ficticio.
asyncapi: 3.0.0
info:
title: Pedidos confirmados
version: 2.1.0
x-propietario:
distrito: comercial
equipo: pedidos
canal-de-cambios: contratos-pedidos
channels:
pedidoConfirmado:
address: comercial.pedidos.confirmado.v2
messages:
pedidoConfirmado:
$ref: '#/components/messages/PedidoConfirmado'
operations:
publicarPedidoConfirmado:
action: send
channel:
$ref: '#/channels/pedidoConfirmado'
components:
messages:
PedidoConfirmado:
payload:
type: object
required: [pedidoId, entidadLegal, pais, confirmadoEn]
properties:
pedidoId: { type: string }
entidadLegal: { type: string }
pais: { type: string, description: ISO 3166-1 alfa-2 }
confirmadoEn: { type: string, format: date-time }
confirmacionParcial:
type: boolean
description: añadido en 2.1.0; los eventos anteriores no lo traen
x-consumidores:
- nombre: conciliacion-pedidos
identidad: svc-conciliacion
responsable: operaciones-de-pedidos
desde: 2.0.0
- nombre: producto-datos-pedidos
identidad: svc-producto-pedidos
responsable: datos-comercial
desde: 2.1.0
x-politica-de-cambios:
compatible: campo opcional nuevo; se anuncia en el canal, sin migración
incompatible: versión mayor nueva; ambas conviven hasta que migra cada consumidor registradoLa sintaxis es lo de menos. Importan tres decisiones que el archivo deja escritas.
El propietario es un distrito, con un equipo y un canal donde anuncia sus cambios, así que un consumidor sabe a quién reclamar y dónde enterarse antes de que algo se rompa. La confirmación parcial, justo el cambio que rompió a Northstar, entró en la versión 2.1.0 como un campo opcional nuevo, que la política de cambios clasifica como compatible; los consumidores que no lo necesitan no tienen que tocar nada. Y cada consumidor figura con su propia identidad, de modo que una lectura anómala de svc-conciliacion tiene autor y responsable.
El script de conciliación era un asentamiento digital informal (una solución útil creada fuera de la arquitectura y del gobierno compartidos). DWU prevé cuatro respuestas para esos asentamientos (reconocimiento, integración, reubicación o retiro), y aquí se aplicaron dos. El script quedó reconocido, al figurar en la lista con un responsable, e integrado a una ruta gobernada al pasar de leer la tabla a consumir el evento.
El registro donde vive el contrato es un catálogo, y el marco cuenta los catálogos como infraestructura pública. Si cada distrito guarda sus contratos a su manera, la descubribilidad vuelve a depender del pasillo.
Por dónde empezaría
El diagnóstico que DWU hace de Northstar propone mover los flujos prioritarios a APIs, eventos, colas y contratos de acceso a datos gobernados y observables. La palabra que pesa es «prioritarios». Migrar todas las integraciones a la vez convierte la movilidad gobernada en un proyecto de años cuyo único resultado visible, durante mucho tiempo, es el costo. El orden que seguiría es este.
- Separar
svc-integracionen una identidad por integración. Es barata comparada con lo que sigue y habilita todo lo demás, porque sin atribución no hay forma de saber qué flujos existen ni cuáles importan. Los registros de conexión suelen revelar a casi todos sus usuarios; los que falten aparecerán cuando la rotación de la credencial los rompa. - Con los registros ya atribuidos, listar quién lee las tablas del ERP y con qué frecuencia.
- Elegir los flujos donde una falla cuesta más y el origen cambia más a menudo. En Northstar, los de pedidos cumplen las dos condiciones.
- Publicar el contrato de esos flujos, registrar a sus consumidores y dejar que convivan la ruta nueva y la vieja hasta que cada consumidor migre.
- Dejar el resto como está, registrado y con dueño, hasta que su origen tenga que cambiar.
El quinto paso es el que más le cuesta aceptar a un arquitecto, porque deja caminos improvisados en pie a sabiendas. Aun así lo prefiero. Un camino registrado y con responsable deja su deuda anotada donde alguien puede priorizarla, y rehacerlo antes de que su origen cambie sería pagar coordinación sin recibir nada.
El caso de Grupo Diveco
En mayo de 2026, un QA de negocio comparó el correo de la Brújula Comercial con las cifras de Portal Diveco, el portal corporativo de Grupo Diveco que describí en el post que abre la serie. La venta total cuadraba. Las unidades, el precio por unidad, el margen y las desviaciones no cuadraban. Había dos rutas de cálculo para los mismos conceptos, el pipeline legado que alimentaba el correo y el data lake. Una contaba unidades físicas y la otra unidades reducidas; bajo el mismo título, una comparaba contra la meta y la otra contra el año anterior. Es la dependencia oculta en su forma más cara, porque el total coincidía y nada avisaba del resto. El correo pasó a calcularse sobre el lake ese mismo día, el 23 de mayo.
El portal consume el lake con un patrón de tres saltos. El frontend llama a la función del módulo, esa función llama a una función genérica de consulta y el portal nunca lee el almacenamiento directamente. Entre repositorios, los contratos viajan como parámetros compartidos y guardas de esquema, sin imports cruzados. Hacia SAP hay dos vías, una en lote a través de las capas medallón del lake (con el dato del día anterior) y otra directa por RFC. Un ADR de septiembre de 2026 declara la vía directa como complemento de la medallón, así que la segunda vía tiene su función por escrito.
A esas rutas les falta ser descubribles. Los contratos existen caso por caso y ningún catálogo de APIs, eventos y contratos permite encontrarlos. La unificación también dejó abierta la decisión de cuál es el «número oficial». Y el paso del correo al lake, una comparación de antes y después en una sola organización y sin datos de incidentes ni de tiempo de entrega, ilustra la hipótesis siguiente sin ponerla a prueba.
Qué esperaría observar si P3 es cierta
DWU es un marco conceptual publicado como preprint, sin revisión por pares ni validación empírica, y lo que dice sobre movilidad está formulado como hipótesis. La proposición P3 plantea que un mayor uso de mecanismos de movilidad observables y basados en contratos se asociará con menor fragilidad de integración y con cambio controlado más rápido. Para ponerla a prueba, el marco sugiere mirar inventarios de APIs y eventos, tasas de falla de integración y el tiempo de entrega de los cambios.
En una empresa como Northstar, al comparar el antes y el después de mover sus flujos de pedidos, esperaría ver dos cosas. La primera es que los cambios en el ERP dejen de romper consumidores desconocidos. La segunda, más exigente, es que el tiempo entre proponer un cambio y tenerlo en producción baje, aun contando la coordinación. Si solo ocurriera la primera, el contrato estaría comprando estabilidad a costa de velocidad, y P3 se sostendría solo a medias.
La organización que decide gobernar sus rutas puede estar contratando mejores ingenieros al mismo tiempo, y eso bastaría para explicar la mejora sin ayuda del vocabulario urbano. El talento figura entre las explicaciones rivales que el propio marco enumera, y es la que aquí me costaría más descartar, porque un buen ingeniero también escribe mejores contratos.
El precio de gobernar las rutas
P3 trae su propio trade-off, porque la movilidad gobernada aumenta la capacidad de cambio e impone costos de coordinación. El segundo diagrama muestra el caso caro en los dos mundos, un cambio que el contrato no puede absorber con una versión menor.
Ese costo cae en lugares concretos. Mantener dos versiones de un evento mientras los consumidores migran duplica, durante ese periodo, parte del trabajo del equipo de pedidos. El registro exige disciplina, porque uno con consumidores desactualizados da una seguridad falsa y es peor que no tenerlo. Y si publicar un contrato requiere la aprobación de un equipo central, ese equipo se convierte en una caseta de peaje, con la misma tensión entre servicio compartido y cuello de botella que describí en el artículo anterior.
Hay flujos donde nada de esto compensa, como el análisis que un equipo necesita durante dos semanas. DWU pide gobernar las rutas sin eliminar la innovación local, y yo lo traduzco en un mínimo para cualquier camino local, que es una identidad propia en lugar de la cuenta compartida, una entrada en el registro con un responsable y una fecha de revisión. Con eso el camino sigue siendo local y rápido, y deja de ser invisible.
Quién paga la coordinación
Antes de separar la cuenta compartida, Northstar tendría que decidir quién carga con la coordinación. El dueño de la ruta (en el ejemplo, el equipo de pedidos del distrito Comercial) pagaría el versionado, los avisos y las dos versiones en paralelo, mientras que el beneficio lo recibirían sobre todo los consumidores que dejan de romperse. Si ese trabajo no aparece en sus objetivos, el próximo cambio incompatible volverá a llegar en silencio, esta vez con un contrato publicado que nadie cumple.
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: Infraestructura antes que densidad: servicios compartidos. Siguiente: Gobernar el subsuelo de datos que nadie ve.