The forgotten tradition of information-system urbanization

Information-system urbanization is a French-language architecture tradition that borrows concepts from urban planning to divide an organization’s information system into zones, quarters, blocks and communication routes, and its central idea is to keep stable capabilities apart from the implementations that change. That intuition still holds. What it lacks is a place for internal cloud platforms, data products, language models and AI agents, and that gap is what Digital-World Urbanization (DWU) tries to fill.

Most of my architecture conversations happen in Spanish, and in them the word almost never comes up. When I use it, people hear real estate (a gated housing subdivision with a guard booth) and I have to explain that I mean something else. The absence bothers me, because several ideas I apply in enterprise platform architecture already had a name and authors in the French literature.

This post, which follows the enterprise as an inhabited territory, acknowledges that intellectual debt and explains where the tradition falls short.

What information-system urbanization proposed

In French it’s called urbanisation du système d’information, which I’ll shorten to IS urbanization, and it borrows the urban vocabulary wholesale, with zones, quarters (quartiers), blocks (îlots) and communication routes between them. The stated goal was to reduce coupling between the parts without losing the coherence of the whole.

The move I find most interesting is the division of labor. The urban planner leaves the design of each building (in a company, each application) to whoever builds it, and keeps what no single builder can decide alone, which means land use, shared infrastructure, boundaries, interfaces and the rules of evolution. Inside an organization, the architecture function decides which capability lives in which quarter and how you get from one quarter to another, and each team decides how to build its own part.

Underneath sits the distinction I still find most useful. Business capabilities change slowly, since a company keeps selling and paying salaries for decades, while the applications that implement them get replaced every few years. A map drawn over capabilities survives those replacements. One drawn over applications ages with the first migration.

The other idea I keep is close to common sense. A company can’t suspend operations while it redesigns its architecture, so the information system, like a city, gets renewed while people live in it, one section at a time, and the rule that keeps the new section from repeating the old mistake has to survive the construction work. In my practice that rule usually ends up as a fitness function (in Spanish), an automated test that fails when a change crosses a forbidden boundary. The term comes from another tradition; urbanization spoke of controlled evolution, and the connection looks direct to me.

The classical plan applied to Northstar

To see where the tradition falls short I’ll use the case that runs through the series. Northstar Consumer Group is a fictional company, a regional manufacturer and retailer with five legal entities in five countries. It has accumulated an ERP, customer and workforce platforms, country-specific applications, a cloud data platform, more than forty analytics products and twelve experimental intelligent agents. It puts into one territory (an environment with its own purpose, jurisdictions, resources and risk constraints) patterns the literature documents separately. I use it to reason with, knowing that an invented case is evidence of nothing.

If Northstar hired an IS urbanist from the classical school, the plan, simplified and in a format I made up for the example, would look something like this.

# Illustrative. Not a standard format of information-system urbanization.
zones:
  operations:
    quarters:
      commercial:
        blocks: [orders, pricing, customers]
        applications: [erp_sales, ecommerce, country_app_c]
      supply_chain:
        blocks: [purchasing, inventory, distribution]
        applications: [erp_logistics]
  support:
    quarters:
      finance:
        blocks: [accounting, close, margin]
        applications: [erp_finance]
      people:
        blocks: [payroll, talent]
        applications: [workforce_platform]
routes:
  - {from: commercial, to: finance, interface: invoiced_orders}
  - {from: supply_chain, to: finance, interface: goods_receipts}
information_layer:
  objects: [customer, product, margin, employee]
technical_layer: [cloud_data_platform, network, compute]

That plan catches a lot, and it deserves credit before criticism. At Northstar, margin is calculated three ways (Finance’s month-end close, the commercial dashboard and one country’s application), which is exactly the kind of inconsistency the information layer exists to catch. The BI tool and one country application read ERP tables directly and skip the interfaces the plan declares under routes. And the three notification implementations are shared infrastructure built three times. A competent classical urbanist would flag all of it.

Trouble starts with the things that act. The purchasing agent prepares purchase orders with credentials inherited from a developer, and the YAML has nowhere to put it. It could be listed as one more application under supply_chain, and that line would stay silent about what matters, which is on whose behalf it acts, what it may do, under which identity and who answers when it gets something wrong. The four classical layers (functional, application, information and technical) describe things that exist and connect, and they have no field for actors that decide and execute. The temporary analytics assistant for collections adds a nuance the plan also misses, because the framework governs a visitor passing through for one analysis differently from a resident like the purchasing agent, as AI agent governance works out.

The forty-plus analytics products don’t find a place of their own either. At best they show up as objects in the information layer or as reports hanging off an application, and they lose what makes them products. A product has an owner, known consumers, quality rules and an access contract.

Then there’s the svc-integracion service account, which several integrations use at once. In the classical plan it’s a detail of the technical layer. For DWU it’s an inhabitant, meaning a non-human actor that accesses and transforms resources, and one without an identity of its own. When one of those integrations does something it shouldn’t, attributing the action to the right integration turns into forensic work.

A genealogy ordered by problems

DWU doesn’t claim to have invented the territorial view. It presents itself as heir to five streams, and for each one it helps to note what it solved and what it left open. The order in the diagram is conceptual. Star and Ruhleder (1996) wrote about infrastructure eight years before Bidan (2004), and they come later in the diagram because they cover part of what classical urbanization left out.

Enterprise architecture

It set the first frame. Zachman (1987) organized descriptions of an enterprise by stakeholder perspective, and TOGAF (The Open Group, 2022) formalized the method and its governance, along with reusable content. None of that is redundant. The trouble starts when practice shrinks to static models and a target state drawn once, a format that represents continuous platform evolution and autonomous software actors poorly.

IS urbanization

It added the territorial vocabulary and renewal without eviction, with a limit that comes from its era. It works through the four classical layers, and it generally predates cloud-native internal platforms, distributed data products, LLMs and autonomous agents. Of its empirical and doctoral work, DWU draws in particular on Bidan (2004), who studied the federation and integration of applications, and Trabelsi (2014), who studied the performance of urbanized information systems.

Platforms and infrastructure

This literature moved attention to what’s shared. A platform combines a stable core with complements that others build, and Gawer (2014), among others, argues that governing that openness is part of the capacity to scale in the first place. Star and Ruhleder (1996), Hanseth and Lyytinen (2010) and Tilson et al. (2010) describe infrastructures that depend on their own history and are hard to redesign from scratch. These streams tend to look at one focal platform, while Northstar has several living side by side, and they don’t offer enterprise-level constructs for jurisdiction (which rules apply in which entity or country) or for habitability, the degree to which people can discover services, understand the data and know who’s accountable.

Data as a product

Dehghani (2020) brought a similar logic to data with data mesh, whose four principles are domain-oriented ownership, data as a product, self-service data infrastructure and federated computational governance. It fits urbanization well because it pairs local responsibility with shared infrastructure and enforceable rules. On its own, though, it leaves out applications, workflows, identities and agents.

AI and agent governance

It’s the most recent stream. The NIST (2023) risk management framework asks for governance across the whole lifecycle, and the NCCoE work on agents (Booth et al., 2026, still an initial public draft) concentrates on identification, authorization, auditing and non-repudiation. Neither offers an architectural theory of where Northstar’s purchasing agent lives, which routes it travels, which shared services it uses and how it coexists with the people doing similar work.

What DWU inherits and what it extends

The table is my reading, row by row, of where each classical piece reappears in DWU.

The first five rows are inheritance with changes of degree. The idea in the first one, capability-oriented zoning, carries over almost intact and is the subject of the next post in the series.

The sixth row is a change of kind. The system stops being populated by users and gets inhabitants that act, some of them non-human, each with an identity someone sponsors. In the seventh, renewal inherits an unpaid bill, urban debt, which is the accumulated cost of duplicated capabilities, opaque flows and abandoned components and extends technical debt to the whole territory.

The last row has no ancestor. Digital habitability and informal digital settlements (useful solutions built outside shared governance, like the adjusted-price spreadsheet that circulates by email at Northstar), together with the civic identity from the sixth row, are the three constructs the framework puts forward as candidate explanations. They’re also the ones that will have to work hardest to justify themselves.

Next to its neighbors

Cut down to four columns, the comparison with the closest approaches looks like this.

The table reads best by column. In the agents column, the other approaches leave agents implicit, partial or out of focus, and DWU is the only one in the table that declares them inhabitants with rules of their own. The data column shows a different move, since data mesh had already made data a central object of governance and DWU relocates it as shared subsurface infrastructure.

None of this makes DWU a replacement. The framework states plainly that TOGAF, capability mapping, platform engineering, data mesh, zero trust and AI risk frameworks keep doing their jobs, and it proposes DWU as a meso-level structure (between the single application and digital society) for locating each of them and the tensions between them. With data mesh, Northstar would know who owns the margin data product. DWU keeps asking past that point, about which district has authority over that definition and which route carries it to the commercial dashboard without touching ERP tables. The full comparison is in governing the data subsurface no one sees.

The risk of relabeling the old

The most serious objection to DWU comes out of this very post. If the French tradition already had zones, quarters, blocks and routes, swapping “quarter” for “district” and “communication route” for “governed mobility” spends vocabulary and buys nothing. For an organization already working with TOGAF and a capability map, that spending is real. People have to translate between two languages and maintain two sets of diagrams for as long as the transition lasts. If the diagnosis comes out the same in the end, that cost was paid for nothing.

That the urban metaphor existed before (and this post shows it did) counts neither for nor against. The framework judges its novelty by a test the metaphor alone can’t pass, which is whether its constructs explain phenomena that adjacent theories leave scattered across separate units of analysis.

Under that criterion the objection turns into a test. If district jurisdiction, mobility governance, the density of informal settlements and habitability don’t explain differences in duplication, integration fragility or shadow-tool adoption beyond what enterprise architecture maturity scores already explain, DWU is an old maturity assessment with new street names. For now that is a hypothesis with no empirical validation, like the rest of the framework.

The limit that hits closest to home has to do with language, since I work mostly in Spanish. The preprint’s literature review may under-represent traditions in languages other than English and French. If Spanish-language architecture has a stream equivalent to IS urbanization, the search didn’t pick it up, and I’d like someone to point me to it.

Two questions before changing vocabulary

If you already have a classical urbanization plan, or a capability map that does the same job, ask it two things before adopting new vocabulary, where your agents live and who owns your data products. If it can answer without changing shape, the new vocabulary buys your organization nothing.

The relabeled-maturity test and the other two the framework sets for itself, with the criteria under which I’d drop parts of it myself, are in how I would know this theory is wrong.

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: The enterprise as an inhabited territory. Next: Zoning the enterprise by business capability.