A point-to-point integration connects two systems through a path only the people who opened it know about. Left unregulated, it behaves like an improvised road cut across private property. It solves today’s trip, and as other teams cut their own, it produces congestion, hidden dependencies and unsafe crossings. Digital-World Urbanization (DWU) proposes moving it, where it matters, onto routes that can be discovered, observed and changed through explicit contracts, without stopping local teams from building.
At Northstar Consumer Group, the fictional company I use to illustrate this series, the team that maintains the ERP split the status column of the orders table in two, to tell confirmed orders apart from partially confirmed ones. The change passed its tests. The next morning, the commercial dashboard, fed by the BI tool, showed fewer confirmed orders than the day before, with no error in sight. The app run by one of the countries (country C, as in the previous article) stopped showing order status. And the nightly script that reconciles orders, which appeared in no inventory, came back with mismatches. No one on the ERP team knew country C’s app read that table. In the database logs, every read of it carried a single name, svc-integracion, the service account several integrations share.
In urban terms, what failed that morning was mobility.
The shortcut across private property
An ERP table is the inside of a building. DWU uses the term buildings for the applications, products and services that deliver capabilities, and each should have a defined purpose, owner, dependencies and lifecycle. Its internal tables were designed for the building’s own use. When Northstar’s BI tool reads the orders table directly, it walks in through the back door of a property whose owner never agreed to visitors and doesn’t even know it has them.
The shortcut always wins the first comparison. There’s nobody to ask, no queue at the platform team, and the SQL query works that same afternoon. Over the last few years, working on enterprise platform architecture, I’ve built some of these shortcuts and approved others, almost always with the same justification (“it’s read-only”). For whoever opens it, the direct path is cheap. The cost shows up later, and it falls on the building’s owner and on the consumers that break when the owner changes its interior.
The framework attributes three consequences to improvised roads, and Northstar has an example of each.
Congestion appears when several unplanned paths load the same structure. The commercial dashboard, country C’s app and the reconciliation script all query the tables the ERP uses for daily operations, and none of that load shows up in anyone’s capacity planning. If the database slows down at month-end, the ERP team sees heavy queries signed by svc-integracion and has nobody to call.
The column episode is the textbook case of hidden dependencies. An owner changes the inside of their own building and breaks consumers they didn’t know existed. The most expensive of the three failures was the dashboard, which kept showing numbers with no sign they were wrong. An integration that fails with an error gets fixed the same day; one that returns plausible, incorrect data can feed decisions for weeks.
The shared account produces the unsafe crossings. For every integration to work, svc-integracion has to hold the union of the permissions each one needs, so least privilege is ruled out by design. Revoking it stops all of them at once. Attribution, the first thing you need in an incident, becomes impossible by construction. In infrastructure before density I treat identity as public infrastructure. When it doesn’t exist as a shared service, every team reuses whatever credential is at hand.
The literature on technical and digital debt associates tightly coupled integrations and unmanaged exceptions with constraints on future change (Ramasubbu & Kemerer, 2016; Rolland et al., 2018). What the urban vocabulary adds is location. Northstar’s debt lives on the path between the ERP and its readers, a place no application inventory records, because the path belongs to no application.
What makes a route governed
An enterprise’s means of transport
Mobility is how information, commands, events and work move between the parts of an enterprise. The framework gives each integration mechanism an urban counterpart, and the analogy earns its place only insofar as each counterpart says something about who maintains a route and who may use it.
| Urban element | Enterprise counterpart | What the analogy adds |
|---|---|---|
| Roads | APIs | An owner maintains them, with signage and access rules; each traveler decides when to leave |
| Public transit | Event streams and queues | The publisher doesn’t know each passenger; capacity and schedule are designed for many |
| Coordinated routes | Workflow engines | Multi-leg trips with transfers and approval stops |
| Traffic rules | Contracts and schemas | They apply to everyone equally, and without them nobody can enforce anything |
The table would be a matching game if it didn’t force questions an integration diagram usually leaves out. A road has someone responsible for its upkeep, and at Northstar nobody could have named the one responsible for the route orders take out of the ERP. A transit operator doesn’t know each passenger but knows how many ride; the ERP team didn’t know how many consumers its orders table had. And traffic rules exist before the accident. On the day the column changed, no contract governed that table. It had a shape, and three consumers depended on that shape without anyone having promised it.
In my piece on extending SAP ECC with an integration layer (in Spanish), I was looking outward from the ERP. Mobility looks at the whole territory and asks which routes exist and who answers for each one.
Four properties of a governed route
The fourth of DWU’s ten principles, governed mobility, asks that information and actions travel on routes that are discoverable, observable and contract-based. The quality of mobility is defined through four properties, and they’re best read with the column case in hand.
A route is discoverable when a team that needs confirmed orders can find it, contract included, without asking around the office. It’s reliable when it has a published service level and known behavior under failure. It’s observable when its owner can see who travels on it, at what volume and with what errors. At Northstar, that last property alone would have told the ERP team that country C’s app existed before anyone touched the column.
The fourth property is the easiest to misread. It’s called appropriate coupling, and the adjective matters, because it allows each flow a different degree of coupling. Country C’s app needs an order’s current status when a sales rep looks it up, and for that a synchronous API, with the temporal coupling it implies, is the right route. It’s the pattern I described in SAP ECC as an API (in Spanish), an anti-corruption layer that translates the ERP’s internal model into a stable contract and that, in this series’ vocabulary, is a road with an owner.
The commercial dashboard needs something else. It wants a set of orders with a stable definition, history and a cutoff date, which looks more like a data product than an integration. That belongs to the subsurface (the data, metadata, lineage and semantics applications depend on), which I cover in governing the data subsurface. The reconciliation script wants to hear about each confirmed order when it happens, and an event serves it better than reading the table every night.
That makes three consumers on three different routes, each with a contract.
The orders route at Northstar
The order-confirmed event contract
Here’s how the contract for the order-confirmed event might look. It follows the general shape of AsyncAPI with custom extensions (the fields starting with x-), and it’s only illustrative.
# Illustrative. Northstar Consumer Group is a fictional case.
asyncapi: 3.0.0
info:
title: Confirmed orders
version: 2.1.0
x-owner:
district: commercial
team: orders
change-channel: orders-contracts
channels:
orderConfirmed:
address: commercial.orders.confirmed.v2
messages:
orderConfirmed:
$ref: '#/components/messages/OrderConfirmed'
operations:
publishOrderConfirmed:
action: send
channel:
$ref: '#/channels/orderConfirmed'
components:
messages:
OrderConfirmed:
payload:
type: object
required: [orderId, legalEntity, country, confirmedAt]
properties:
orderId: { type: string }
legalEntity: { type: string }
country: { type: string, description: ISO 3166-1 alpha-2 }
confirmedAt: { type: string, format: date-time }
partialConfirmation:
type: boolean
description: added in 2.1.0; earlier events don't carry it
x-consumers:
- name: order-reconciliation
identity: svc-reconciliation
accountable: order-operations
since: 2.0.0
- name: orders-data-product
identity: svc-orders-product
accountable: commercial-data
since: 2.1.0
x-change-policy:
compatible: new optional field; announced on the channel, no migration
breaking: new major version; both run side by side until every registered consumer migratesThe syntax is the least of it. What matters are three decisions the file puts in writing.
The owner is a district, with a team and a channel where it announces changes, so a consumer knows whom to call and where to hear about a change before something breaks. Partial confirmation, the very change that broke Northstar, arrived in version 2.1.0 as a new optional field, which the change policy classes as compatible; consumers that don’t need it have nothing to change. And each consumer is listed with its own identity, so an anomalous read by svc-reconciliation has an author and someone accountable for it.
The reconciliation script was an informal digital settlement (a locally useful solution built outside shared architecture and governance). DWU allows for four responses to such settlements (recognition, integration, relocation or retirement), and two of them applied here. The script was recognized, by appearing on the list with an accountable team, and integrated into a governed route when it moved from reading the table to consuming the event.
The registry where the contract lives is a catalog, and the framework counts catalogs as public infrastructure. If each district keeps its contracts its own way, discoverability goes back to depending on who you know.
Where I would start
DWU’s diagnosis of Northstar proposes moving priority flows to governed, observable APIs, events, queues and data-access contracts. The word that carries the weight is “priority.” Migrating every integration at once turns governed mobility into a multi-year project whose only visible output, for a long time, is cost. This is the order I would follow.
- Split
svc-integracioninto one identity per integration. It’s cheap next to what follows and it enables everything else, because without attribution there’s no way to know which flows exist or which ones matter. Connection logs usually reveal almost everyone using the account; the rest will surface when rotating the credential breaks them. - With the logs now attributed, list who reads the ERP tables and how often.
- Pick the flows where a failure costs the most and the source changes most often. At Northstar, the order flows meet both conditions.
- Publish the contract for those flows, register their consumers, and let the new route and the old one coexist until every consumer has migrated.
- Leave the rest as it is, registered and with an owner, until its source has to change.
The fifth step is the one architects find hardest to accept, because it knowingly leaves improvised roads standing. I still prefer it. A registered path with someone accountable has its debt written down where someone can prioritize it, and rebuilding it before its source changes would mean paying for coordination and getting nothing back.
The Grupo Diveco case
In May 2026, a business QA review compared the Brújula Comercial (in Spanish) email against the figures in Portal Diveco, Grupo Diveco’s corporate portal from the post that opens the series. Total sales matched. Units, price per unit, margin and variances didn’t. There were two calculation routes for the same concepts, the legacy pipeline that fed the email and the data lake. One counted physical units and the other reduced units; under the same heading, one compared against target and the other against the prior year. That’s a hidden dependency in its most expensive form, because the total matched and nothing flagged the rest. The email was moved onto the lake that same day, May 23.
The portal consumes the lake through a three-hop pattern. The frontend calls the module’s function, that function calls a generic query function, and the portal never reads storage directly. Between repositories, contracts travel as shared parameters and schema guards, with no cross-imports. Toward SAP there are two paths, a batch one through the lake’s medallion layers (with the previous day’s data) and a direct one over RFC. An ADR from September 2026 declares the direct path a complement to the medallion, so the second path has its role in writing.
What these routes lack is discoverability. Contracts exist case by case, and no catalog of APIs, events and contracts lets anyone find them. The unification also left open the decision about which figure is the “official number.” And moving the email onto the lake, a before-and-after comparison within one organization with no incident or lead-time data, illustrates the next hypothesis without testing it.
What I would expect to see if P3 holds
DWU is a conceptual framework published as a preprint, without peer review or empirical validation, and what it says about mobility is stated as a hypothesis. Proposition P3 holds that greater use of observable, contract-based mobility mechanisms will be associated with lower integration fragility and faster controlled change. To test it, the framework suggests looking at API and event inventories, integration failure rates and change lead time.
Comparing a company like Northstar before and after it moves its order flows, I’d expect to see two things. The first is that changes in the ERP stop breaking unknown consumers. The second, and harder, is that the time between proposing a change and having it in production goes down, coordination included. If only the first happened, the contract would be buying stability at the expense of speed, and P3 would hold only halfway.
An organization that decides to govern its routes may be hiring better engineers at the same time, and that alone could explain the improvement with no help from the urban vocabulary. Talent is one of the rival explanations the framework itself lists, and the one I’d find hardest to rule out here, because good engineers also write better contracts.
The price of governing routes
P3 comes with its own trade-off, because governed mobility increases the capacity for change while imposing coordination costs. The second diagram shows the expensive case in both worlds, a change the contract can’t absorb with a minor version.
That cost lands in specific places. Keeping two versions of an event alive while consumers migrate duplicates part of the orders team’s work for that period. The registry demands discipline, because one with stale consumers gives a false sense of safety and is worse than having none. And if publishing a contract requires sign-off from a central team, that team becomes a toll booth, with the same tension between shared service and bottleneck I described in the previous article.
Some flows don’t justify any of this, such as the analysis a team needs for two weeks. DWU asks for governed routes without eliminating local innovation, and I translate that into a small minimum for any local path, which is its own identity in place of the shared account, a registry entry with someone accountable, and a review date. With that, the path stays local and fast, and it stops being invisible.
Who pays for the coordination
Before splitting the shared account, Northstar would have to decide who carries the coordination. The route owner (in the example, the orders team in the Commercial district) would pay for versioning, notices and two versions running in parallel, while the benefit would go mostly to the consumers that stop breaking. If that work doesn’t show up in the owner’s objectives, the next breaking change will arrive silently again, this time with a published contract nobody honors.
This article is part of the Digital urbanization series, based on the preprint Toward a Theory of Digital-World Urbanization (Rodas López, 2026), a conceptual framework whose ideas I applied and refined on Grupo Diveco’s corporate platform, though its six propositions have not yet been empirically validated. Previous: Infrastructure before density: shared services. Next: Governing the data subsurface no one sees.