An enterprise should treat the services whose duplication does harm as public infrastructure before it multiplies applications and agents, starting with identity, audit, observability, secrets and notifications. Every system that arrives ahead of them brings its own version. That order is the third principle of Digital-World Urbanization (DWU), infrastructure before density, and in the Digital urbanization series it follows zoning the enterprise by business capability. That post drew the districts (the business capability domains, each with an owner), and this one covers what runs underneath all of them.
Northstar Consumer Group, the fictional company I use as a running case in this series, has three services that send notifications, and none of them knows the other two exist.
Three services doing the same job
Northstar operates five legal entities in five countries within one region. Its local teams ship fast, and that speed left behind three notification implementations. One lives in the e-commerce platform and tells customers where their orders are. Another sits in the workforce platform and writes to employees. The third was built by the team behind one country’s application, which I’ll call country C, for messages to its customers.
Each has its own templates, its own retry logic, its own way of recording unsubscribes and its own audit trail.
None of those decisions was wrong at the time. The e-commerce team needed order confirmations and couldn’t wait for a service that didn’t exist; country C had a launch date it had committed to. Each building (an application, digital product, service or model with an owner and a purpose) solved its problem with whatever it had at hand.
The cost shows up when something changes outside the buildings. Suppose country C’s regulator changes the consent rule for commercial messages and requires proof, for every send, that the recipient hadn’t opted out. At Northstar that change has three owners with three backlogs and three calendars. The e-commerce team implements it according to its reading of the rule. Country C’s team implements it with a different reading. The workforce team first has to decide whether the rule even applies to them, and has nobody to ask, because no team owns “how Northstar sends notifications.”
Unsubscribes don’t cross over either. A customer who opts out on the e-commerce site keeps receiving messages from the country C app, because each implementation keeps its own list. And when an auditor asks something as simple as “which messages did this person receive after asking us to stop?”, the answer comes from three systems, in three trace formats, reconciled by hand by someone who designed none of them.
The inefficiency of building the same thing three times shows up in the budget. The systemic risk shows up later, on the day the company needs to behave consistently toward one person, one regulator or one incident and finds it has no way to.
What counts as public infrastructure
The framework calls the set of services whose duplication creates inefficiency or systemic risk the public infrastructure of an enterprise digital world. Its list covers identity and access management, audit trails, observability, secrets management, notifications, shared UI systems, developer platforms, catalogs and policy engines. The diagram compares Northstar without that layer and with it.
I find the criterion more useful than the list. A service belongs in public infrastructure when having several versions of it does harm, either because you pay for it several times or because the versions diverge exactly where the company needs one behavior. By that test some obvious candidates stay out. Many buildings query a pricing engine, and I would still place it in the Commercial district; if there are two, the damage is semantic, and it gets fixed through domain ownership and shared definitions, which is the business of the district and its data.
What the principle asks for is standardized access to reliable capabilities, and that does not require absolute centralization. For an executive it becomes an obligation to decide which capabilities are common, which are federated and which are locally autonomous.
Why the order matters
The full wording asks that identity, observability, security and shared delivery capabilities mature before applications and agents proliferate unchecked, and the word doing the work is “before.” Infrastructure that arrives late competes with whatever is already embedded. The literature on digital infrastructures describes them as relational, embedded in practice, path dependent and hard to redesign from scratch (Star & Ruhleder, 1996; Hanseth & Lyytinen, 2010; Tilson et al., 2010). Northstar’s three implementations already have integrations and operating habits built around them. Retiring them is urban renewal (modernizing what is in use without stopping operations), with its own cost and its own risk, work that would not exist if the common service had arrived before the first team that needed it.
The literature on digital options and debt points the same way. Standardized services speed up development and create future possibilities, while duplicated components, tightly coupled integrations and unmanaged exceptions constrain change (Ramasubbu & Kemerer, 2016; Rolland et al., 2018). In urban terms, infrastructure creates development options, and unplanned density overwhelms services and narrows future paths.
Agents make the order urgent. Northstar has twelve experimental agents, among them a purchasing agent that prepares purchase orders and a temporary analytics assistant for collections, and both currently run on credentials inherited from a developer. That is what happens when agent density arrives before identity infrastructure, and each agent gets whatever identity is lying around. Because an agent acts far more often than any person, an improvised identity scales much faster than anyone’s oversight of it. How to give each agent its own identity, with a sponsor and a jurisdiction, is the subject of AI agent governance.
Of everything I’ve seen in platform architecture work, retiring the local versions after the common service exists costs the most, and the bill lands on teams that never asked for the new service. Building the service is, by comparison, the easy part.
From inventory to catalog
At Northstar, applying the principle starts with seeing what is being rebuilt, moves on to splitting each service between what is common and what stays local, and ends with how the team that runs it gets measured.
What each building rebuilds
The table walks through the capabilities that a diagnosis of Northstar finds rebuilt again and again.
| Capability | Condition at Northstar | What stops being consistent |
|---|---|---|
| Identity and access | shared accounts such as svc-integracion; agents running on credentials inherited from a developer | who acted, and with what permission |
| Notifications | three implementations with their own templates, retries and unsubscribes | how the same person is treated |
| Audit | one trace format per building | the evidence handed to an auditor or regulator |
| Observability | each building measures in its own way | the ability to follow an incident across buildings |
| Policy checks | country rules copied into each application | compliance with the same rule across five countries |
The first row is the most delicate. In a post on securing an API on top of SAP (in Spanish) I described five layers of control for a single API. If every building that exposes an API rebuilt those layers its own way, the versions would diverge exactly where a difference stays invisible until someone exploits it.
Common, federated and autonomous
Applied to Northstar’s notifications, one possible split across those three levels looks like the diagram below.
With that split, country C’s regulatory change is no longer a project spread across three teams. The country updates its consent rule, which lives as federated configuration with a jurisdiction tag, and the common engine applies it to everything sent to people in that country, whether it comes from e-commerce, the workforce platform or the local app. The trail ends up in one format. The country keeps authority over its rule and sheds the burden of reimplementing the engine.
Measuring the platform team
Much of what’s now called platform engineering fits this principle, and DWU makes no claim to replace it. What it adds is a way to place it alongside the districts, buildings and data that depend on it. Platform teams are providers of public infrastructure while the districts keep developing their own buildings, and a platform team’s success is measured by adoption, reliability, reuse, reduced cognitive load, policy compliance and habitability.
That list changes what a team does. Measure it by features shipped and it ships features. Measure it by adoption and it has to make using the common service easier than building your own, which forces it to care about documentation, about how long a new team takes to send its first message in production, and about what happens when something breaks. The last metric on the list, habitability (how easy it is to discover, understand and use the service, and to recover when it fails), is the hardest to measure. The framework’s proposition P6 links it to higher adoption of governed platforms and less reliance on unofficial parallel tools; I go into it in digital habitability.
Those metrics become visible in a catalog of civic infrastructure, meaning the shared services treated as foundational. An entry for Northstar’s notifications could look like this.
# Illustrative entry in a civic service catalog
service: notifications
system: public-infrastructure
owner:
team: platform-communications
product_owner: named role, with a defined backup
jurisdictions: [country-a, country-b, country-c, country-d, country-e]
consumption:
routes: [send-api-v1, message-requested-event]
forbidden: direct writes to the service database
service_level:
availability_target: "<agreed and published with consumers>"
consumer_onboarding_time: "<published and measured>"
degradation: consumer-side queue with deferred resend
adoption_metrics:
- active consumers vs. target consumers
- known parallel implementations
- support tickets per consumer
exception:
requested_by: building owner
requires: [reason, accepted_risk, sponsor, expiry_date]
on_expiry: migrate, renew with fresh justification, or retireI left the service levels without numbers on purpose. The right number depends on the company. What doesn’t depend on it is that the number exists, is published and that someone measures it. The consumption block matters as much as the rest, because a common service that each building reaches by writing straight into its tables recreates the problem of point-to-point integrations inside the very infrastructure that was supposed to solve it.
The Grupo Diveco case
Corporate single sign-on (SSO) came to Portal Diveco, the platform this series opens with, on August 12, 2025, five days after the first commit. The first business module followed a month later, on September 11, and the ones after it rely on that shared identity and on common audit and notification services. In the platform’s 3D model, identity is the customs house.
A piece of connectivity had a different kind of effect. It was built for an employee self-service case and ended up enabling a later module nobody had planned. The portal’s internal story describes it as LEGO pieces. In the terms of the literature cited above, a piece built for one need created an option for the next.
Row-level filtering, which decides which records each user sees in a report, went the other way. Reports multiplied before there was a common engine, the debt was documented as two parallel filtering engines that had drifted apart, and the unified version arrived on July 20, 2026, almost a year after SSO. That was density before infrastructure, corrected afterwards.
There’s still no cross-cutting policy engine, so the order was right for identity, late for filtering and still pending for policies. It’s one case with no measurements, which means it illustrates the principle without measuring its effects.
What P1 predicts and what would weaken it
The framework’s first proposition, P1, says that greater adoption of reliable public digital infrastructure goes with less duplication of foundational capabilities across digital products. It’s a hypothesis the preprint puts forward without testing it.
The adjective “reliable” carries almost all the weight. A platform that goes down, takes weeks to grant access or that nobody understands gets low adoption, and the teams that route around it build their own version. If P1 holds, what I’d expect to see at Northstar is the number of notification implementations falling as consumers of the common service grow, and new buildings no longer arriving with their own authentication and audit. The evidence that would test it lies in service catalogs, duplicated identity and notification components, and platform adoption metrics. In the catalog entry from the previous section, the known-parallel-implementations metric is P1 at the scale of a single service.
Duplication can also fall for reasons that have nothing to do with reliability. If a company eliminates local implementations by mandate, with a mediocre platform, duplication drops and P1 looks confirmed without reliability having had anything to do with it. Only a study that measures reliability separately from adoption could tell the two apart.
Bottleneck and concentration
The tension that comes with P1 is plain. Shared infrastructure can reduce duplication and at the same time create bottlenecks or systemic concentration risk. Northstar would get both.
The bottleneck comes first. When country C needs a messaging channel the common service doesn’t support, its request lands in the platform team’s backlog and competes with those of the other four countries. If the wait is longer than building locally, the country builds locally, and the fourth implementation appears. A useful solution built outside the shared architecture is a diagnostic signal of unmet demand, and here the signal points at the common service, which isn’t responding at an acceptable speed.
Concentration is less visible and more dangerous. The three independent implementations had a virtue nobody designed. A failure in the e-commerce one never touched the other two. With a common service, a notifications outage hits e-commerce, the workforce platform and all five countries at once. Identity is the extreme case, because if the shared identity service fails, nobody gets in anywhere. That is why the principle talks about infrastructure maturing. A shared layer needs degradation modes (the consumer-side queue with deferred resend from the example), capacity isolation between consumers so one consumer’s spike doesn’t starve the rest, and operations that match the dependency it creates.
The third cost is political. A platform made mandatory by decree can show excellent adoption numbers and still be a poor service, and then the metric that was supposed to tell you whether the service deserves to be used stops telling you anything.
Order and the exception
I expect infrastructure first and density after to come out cheaper than the reverse sequence, which ends in renewal. Infrastructure that arrives first also concentrates risk, and what keeps the principle from hardening into dogma is the exception process. An exception with a reason, an accepted risk, a sponsor and an expiry date is information. It tells the platform team what the service isn’t covering, and it tells the architect where urban debt, the accumulated structural cost that constrains change, is growing with everyone’s eyes open. An exception register that only grows suggests the service is hard to live with. One that stays empty for a long time may say the opposite, or that teams stopped asking.
The practical decision is small. Before approving the next building, ask which of these services it will bring on its own and who will sign the exception if it does. The question the framework doesn’t answer yet is how many active exceptions a common service should tolerate before concluding that the problem lies with the service and not with the teams.
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: Zoning the enterprise by business capability. Next: Point-to-point integrations are improvised roads.