The enterprise as an inhabited territory

The digital environment of a medium or large enterprise can be read as an inhabited territory, with borders, zones, shared infrastructure, routes, a data subsurface and a population of people, systems and AI agents working under common rules. That is the proposal behind Digital-World Urbanization (DWU), a conceptual framework I developed, and it starts from a limit of enterprise architecture as it is usually practiced, where the application inventory lists the assets without explaining how they are governed together.

What an inventory knows

Northstar Consumer Group’s inventory shows that limit. Northstar is a fictional case I use throughout the series, a regional manufacturer and retailer with five legal entities in five countries, and its application inventory is up to date. It has rows for the ERP, for the customer and workforce platforms, for each country application and for the cloud data platform, more than forty rows of analytics products and twelve for experimental intelligent agents, each with an owner on record and its cost.

When Supply chain asks to take the purchasing agent (the one that prepares purchase orders) into production, the inventory has a row for that agent and no answers. It doesn’t say which entity’s rules the agent should follow, who answers for a wrong order, which identity it acts under (today it runs on credentials inherited from a developer), which route carries the order into the ERP, or which supplier master it reads.

An application inventory is a list of assets, and as a list it’s useful for renewing licenses, explaining costs and knowing whom to call when something breaks. What a list can’t hold is the relationship between its items, meaning which rules two applications share, which common service they both use, how data travels from one to the other and who has authority over that trip.

Enterprise architecture has richer tools. Zachman (1987) organized descriptions of the enterprise by stakeholder perspective, and TOGAF (The Open Group, 2022) formalized methods, governance and reusable content. Both are still needed. They tend to be practiced with static models, project gates and target-state documents, though, and that way of working struggles to keep up with development distributed across products, platforms that evolve continuously and, now, software actors that act on their own.

Northstar has three notification implementations, one in the e-commerce site, one in the workforce platform and one in a country application. Margin is calculated three ways, depending on whether Finance looks at it during close, in the commercial dashboard or in that same country application, which also reads ERP tables directly, just as the BI tool does. Several integrations share the service account svc-integracion. None of these problems belongs to a row in the inventory, so no application owner has them on their backlog.

For three years I applied these ideas in enterprise platform architecture work, and I kept running into that pattern, problems nobody disputed that stayed ownerless between two well-defined responsibilities. In cloud architecture on AWS and AI for enterprises (in Spanish) I explained why I start from diagnosis; DWU is my attempt to give that diagnosis a unit of analysis that covers the whole.

The digital world as a territory of seven systems

That unit is the enterprise digital world, the bounded but permeable sociotechnical environment through which an organization executes capabilities, coordinates actors, processes information and creates value. DWU stops looking at the application or the portfolio and looks at that whole environment.

That world accumulates without a single blueprint, through projects, acquisitions, regulatory demands, spreadsheets, cloud services and, increasingly, agents. Each piece can be useful where it sits while the whole still produces fragmentation, duplicated capabilities, inconsistent identities and opaque data flows.

The framework’s central claim is that such an environment shouldn’t be governed purely as a portfolio. It can be analyzed as an evolving sociotechnical territory, inhabited by people, applications, services, data products, models and agents. “Territory” because it has borders, jurisdictions and rules that apply in some zones and not in others. “Inhabited” because the enterprise can’t be evacuated to be redesigned; like a living city, it gets renewed while it’s in use, and among its users there are already agents that invoke tools and produce operational effects.

DWU organizes that territory into seven systems. Each urban name maps to something the enterprise already has, even if it rarely governs it as one thing.

The split between buildings and public infrastructure is what best explains Northstar’s three notification services. A building belongs to a district, has an owner and can be replaced. Public infrastructure groups the services whose duplication creates inefficiency or risk for everyone, and what it requires is standardized access to reliable capabilities, whether or not they’re centralized. Northstar has three buildings doing the work of one public service, and none of their owners is wrong from inside their own district.

The territory is the constitutional layer, the one that defines where each authority applies (entity, country, regulation, risk appetite); without it, platforms grant global access or reproduce each country’s logic in their own way.

The subsurface is where the framework places failures that show up far from their origin. A margin that differs between Finance’s close and the commercial dashboard shows up in two buildings, but it starts in a definition neither of them owns.

How the systems relate

The logic tying the seven together is relational. Territories contain districts, districts host buildings, buildings depend on public infrastructure and mobility, the subsurface supplies data and knowledge, and inhabitants act under rules that span the whole environment. The systems are distinct for analysis and interdependent in operation, and Northstar’s purchasing agent shows how.

From the inventory, taking that agent to production means flipping a row from “experimental” to “production”. From the territory, the same change forces decisions in six systems.

Under whose rules and in whose name

Start with territory and district. The five entities share platforms but have different regulatory boundaries and risk appetites, so the agent has to know under which entity’s purchasing rules it’s preparing each order, and someone had to write those rules first. The agent belongs to Supply chain, which seems obvious until you ask who answers for it today.

By default, the developer who built it does.

Identity is the most delicate point. With credentials inherited from that developer, every audit record attributes the agent’s actions to a person who didn’t perform them. The agent needs its own identity, and a shared identity service should issue it. At Northstar that service doesn’t exist yet as public infrastructure, because authentication is rebuilt in several applications, and solving the agent’s identity with yet another custom mechanism would repeat the three-notifications pattern with something far more sensitive.

The route and the supplier master

The order can reach the ERP through a contracted API, observable and versioned, or by writing directly to tables, which is technically possible and looks a lot like what BI and the country application already do for reads. The framework calls unregulated connections like these improvised roads that cut across private property, because they solve the immediate problem and leave hidden dependencies behind, and point-to-point integrations follows one of them until it breaks.

Under the route sits the supplier master. If it carries the same definition problems as customer and margin, the agent will spread them at a volume no person reviewing orders could keep up with.

The agent as an inhabitant

DWU asks every agent to carry a civic profile, a set of attributes that runs from a verifiable identity and an accountable sponsor to financial limits and emergency revocation. It also separates residents from visitors, and the purchasing agent, persistent and with recurring tasks, is a potential resident, which asks more of its lifecycle than the temporary analytics assistant Northstar uses in collections. The idea is that the profile should be machine-executable where possible. A fragment like this one, validated in the deployment pipeline, would be one way to try.

# Illustrative: change sheet for Northstar's purchasing agent.
# Not a schema defined by DWU, and not a standard.
agent: purchasing-agent
inhabitant_type: resident              # persistent, recurring tasks
territory:
  jurisdictions: [entity-a]            # starts in one entity, not all five
  purchasing_rules: purchasing-policy-entity-a
district:
  owner: supply-chain
  sponsor: head-of-purchasing          # the person who answers for the agent
public_infrastructure:
  identity: own                        # issued by the shared service, replaces the inherited credentials
  audit: central-log
mobility:
  create_order: purchase-orders-api    # versioned contract, no writes to ERP tables
subsurface:
  reads: data-products/supplier-master
inhabitant:
  autonomy: prepare-and-propose        # a person approves before issuing
  financial_limit: set-by-finance
  revocation: immediate-by-sponsor

Every block in that sheet has a different owner. The entity sets its purchasing rules, Supply chain sponsors, the platform team issues the identity, the integration team publishes the API, the data team answers for the supplier master and Finance sets the limit. In the inventory, all of that fit in a single column called “owner”.

The sheet also makes a cost visible, since a human approval on every order takes away part of the useful autonomy that justified the agent.

A disciplined analogy

DWU doesn’t claim that enterprises are cities. It uses the city as a disciplined analogy for building theory, and its usefulness depends on two things that can be examined, the explanatory power of its constructs and whether they can be operationalized. A visual resemblance between an architecture diagram and a city map counts for nothing.

That’s why the urban names went through a filter. An urban construct was kept only if it played a distinct analytical role and explained something no other construct captured. The level of analysis is deliberate as well. The enterprise digital world sits at a meso level, wider than the architecture of one application and narrower than the digitalization of society.

The idea has antecedents in the French-speaking tradition of urbanisation du système d’information, which already divided the information system into zones, quarters and blocks, and which I review in the forgotten tradition of information-system urbanization. That school generally predates cloud-native platforms, distributed data products and agents. DWU tries to extend it that far. The same post sets the framework beside its neighbors (TOGAF, data mesh, zero trust, AI risk frameworks), which it aims to place in one territory without replacing any of them.

Rodas López (2026) is a conceptual preprint without peer review. Its six propositions are hypotheses, and neither they nor the choice of the seven systems have been empirically validated yet. The practice I described at the start shaped the constructs. It wasn’t a designed study, though, and it carries an obvious risk of confirmation bias. When this series says something reduces duplication or speeds up change, read it as what I would expect to observe if the framework is right.

Of the three years that practice spans, the part documented in repositories begins in August 2025 with Portal Diveco, Grupo Diveco’s internal corporate portal, which brings the tools for operations, finance, sales, reporting and human capital together in a single registry. The platform came first, and the framework was abstracted from building it. Internally the portal is called “Ciudad Diveco” (Diveco City). Since August 26, 2025, every user has been given the default role “Ciudadano DIVECO” (Diveco citizen), and REDI, the master source for employee records, is its civil registry. The modules share identity, audit, notifications and row-level filtering, read from a data lake with shared semantics, and coexist with AI agents and RPA bots.

That city vocabulary belongs to the brand. The words district, inhabitant and building don’t appear in the portal’s documentation, and the urban language lives in the names and in a 3D model we published in September 2026. The model draws the platform as a city, with one building per tool, blocks for the portal’s sections and districts for Human Capital, RPA, Data Engineering and AI. It’s a communication map, and its resemblance to a city is the kind that counts for nothing as an argument. Its territory, a bounded valley with guard posts, is purely visual. The real jurisdiction lives in row-level filtering, which derives the country whose data each employee can see from that employee’s record in REDI, and shuts out anyone the registry marks as inactive.

What’s missing is just as concrete. The country is a row filter today, and the legal entities, data residency and risk appetite per jurisdiction that the framework places in the territory aren’t modeled. The civic profile the framework proposes for agents doesn’t exist yet as a formal piece. The model is static configuration copied by hand from the registry, and its buildings don’t link to the tools they represent. Diveco shows that the constructs can be operationalized in a real organization. It doesn’t measure any of the effects the framework attributes to them.

Where the framework can fail

The most serious risk for DWU is overextension, an urban analogy stretched until it hides phenomena another image would explain better, or a set of seven systems with one too many or one missing. There are concrete ways to catch it. If independent analysts keep disagreeing about whether Northstar’s supplier master belongs to the subsurface or is a building in the Supply chain district, the vocabulary is too unstable for anyone to build on.

That’s the standard I’m asking readers to apply to what follows. The metaphor has to earn its place by explaining something that the inventory, the capability map or the AI risk checklist left scattered. That test, the other two the framework proposes and the observations that would force me to narrow, revise or abandon parts of it are in how I would know this theory is wrong.

There’s also a limit on authority. The framework assumes the organization can set common rules, an authority no single party holds over a marketplace or an infrastructure shared by several organizations. Those cases need institutional and economic constructs that DWU doesn’t offer.

The other limit is size. DWU is meant for medium and large organizations, multi-business enterprises, regulated institutions and platform-rich environments, where many digital products, shared services, legacy systems and automation coexist. In a small organization with an accounting package and an online store that don’t talk to each other, stable boundaries and almost nothing shared, the framework helps little. There the seven systems add vocabulary without adding decisions, and a well-kept inventory is enough.

To find out which side of that line an organization falls on, there’s an exercise I’d suggest to any architecture team, as long as nobody mistakes it for a measurement. Take the last significant change and count the systems, out of the seven, where someone had to make a decision. If the count is one or two, the framework is probably overkill there. If it’s five or six, as with Northstar’s purchasing agent, the next question is who made each of those decisions and whether any of them knew the others existed.

How to read the series

After a look at the tradition the framework builds on, the order roughly works down the cross-section above, starting with zoning the enterprise by business capability, because without clear districts there’s no one to assign routes or data to. The purchasing agent comes back in AI agent governance, where the civic profile is worked out in full, and the digital urbanization canvas pulls everything into ten diagnostic questions.

Readers who’d rather start with the objections can read the last post first.

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. Next: The forgotten tradition of information-system urbanization.