Zoning the enterprise by business capability means dividing authority over its digital world into three layers, in a fixed order. Territory comes first and settles where each legal and risk rule applies. Districts come next and group capabilities that share one owner and one vocabulary. Buildings come last, meaning the applications, services and models, each with a record that says why it exists and what state it’s in. A business capability map is the tool for drawing the districts. Zoning adds the legal ground underneath and the living inventory on top.
To ground this I use Northstar Consumer Group, a fictional case that runs through the whole series. Its five legal entities, in five countries of the same region, share an ERP, a cloud data platform and the customer and workforce platforms, and each one faces different regulatory and risk boundaries. On top of that shared base, Northstar computes margin three different ways, and nobody has decided who can see each entity’s customers.
What Northstar inherits by default
A territory can hold several jurisdictions whose rules differ while they sit on the same common infrastructure, and urbanization begins by stating where each one applies. When nobody states it, the framework anticipates three consequences, and I’ve seen all three on shared platforms. Platforms grant global access, because that’s the default. Each country’s logic gets reproduced inconsistently in several places. Services appear that nobody can tie to an owner.
At Northstar the BI tool queries ERP tables directly, and so does one country’s application. If the territory hasn’t been drawn, those queries inherit global scope. An analyst at one entity could see another entity’s customers without anyone having decided that, and when someone eventually asks whether it’s acceptable there will be nobody to ask.
The second consequence shows up in margin. Finance computes one at month-end close, the commercial dashboard another and a country application a third. Each calculation is correct inside the application that produces it. The trouble starts when leadership compares two reports and finds two numbers.
The third gets lost in the inventory. The application inventories I’ve seen treat everything that exists as permanently valid, and that uniformity hides what actually costs money and carries risk, such as the script nobody maintains, the duplicated dashboard or the application bought for a project that closed long ago.
Territory, districts and buildings
Territory, districts and buildings are three of the seven systems into which Digital-World Urbanization (DWU) divides the enterprise as an inhabited territory, and they’re the three that give the city its shape. The partition itself is older. The information-system urbanization tradition already split the information system into zones, quarters and blocks, and DWU picks it up in its districts.
Territory is the strategic and institutional context of the enterprise digital world. It covers legal entities, countries, business units, regulatory constraints, data residency, risk appetite and the boundary with the outside. DWU calls it the constitutional layer, and its first principle, territorial coherence, asks that every component operate within defined organizational, regulatory and risk boundaries. The intervention that follows looks modest, with jurisdiction tags, data residency constraints, risk appetite and decision rights defined per territory. It’s inventory and agreement work, with very little technology in it, and it tends to get postponed because it leaves nothing to show in a demo.
Each district is a coherent business capability or domain, with someone accountable for how it evolves. Northstar has four: Commercial, Supply chain, Finance and People. The framework’s second principle, capability-oriented zoning, asks that structures be organized around stable capabilities and domains in preference to vendor products and short-lived projects. It’s the same instinct behind the domain-oriented ownership and federated governance that Dehghani (2020) proposes for data, extended to everything a district owns.
Buildings are the applications, internal products, analytical interfaces, APIs, models and service components that deliver capabilities. Each one should have seven attributes defined: purpose, owner, inhabitants (the human and non-human actors that use it or feed it), lifecycle, cost, dependencies and compliance obligations.
The attribute that changes the conversation is status. DWU distinguishes four and asks that they be made explicit; the working definitions below are mine. A strategic landmark is a building the enterprise wants to keep investing in. A temporary structure solves something today and carries a review date from the day it’s registered. A legacy installation still supports processes, but nobody wants it to grow, and sooner or later it will have to be renewed or replaced. An abandoned property keeps running with no owner who answers for it. Recording a status forces a choice among the four, which the uniform inventory never required.
The diagram puts the three layers together for Northstar. The ERP shows up twice on purpose, because its purchasing module lives in Supply chain and its close module in Finance, each with its own owner.
From the map to the record
Drawing a district boundary
The test I use to tell whether a boundary is well drawn is semantic. Inside a coherent district the important words mean one thing, and one person answers for that meaning. With its three margins, Northstar fails the test right away.
Drawing districts from application history reproduces that state. Suppose the commercial dashboard was built with its own margin calculation because, at the time, that was faster than asking Finance. A map that draws a district around each existing application turns that shortcut into an official boundary. A business capability map is there to break that inertia. It asks first what the business does (sell, source, close the month, pay its people) and only then which applications do it.
Wherever two districts meet there’s a translation. Commercial talks about customers and Finance talks about debtors, and the same buying company is both at once. That boundary needs a contract and someone to maintain it, much like the boundary between a digital channel and a legacy ERP that I described in SAP ECC as an API (in Spanish). With explicit translation, the boundary holds. Northstar’s three margins come from the opposite arrangement, direct queries against ERP tables that each application interprets its own way.
The license org chart
A recurring temptation at Northstar is to buy one vendor product per district. A commercial suite for sales, another for supply chain, the ERP for finance and a human capital platform for people. The resulting diagram looks like a capability map, with four boxes and four names, and it gets presented as architecture. What it actually draws is the license org chart.
A product’s boundaries follow how the vendor packages its market. A suite usually ships with its own customer master, notification engine and permission model, because it has to work on its own at any company that buys it. Northstar already runs three separate notification implementations, and a license org chart would institutionalize that kind of duplication, since every box on the diagram brings its own copy. What should be common across districts, and in what order to mature it, is the subject of the next piece in the series.
Buying products is fine, as long as the purchase comes after the district is drawn and the product is registered as one of the district’s buildings, with an internal owner who answers for it.
A record for every building
The illustrative record below is for the low-code field-visit app that a regional manager at Northstar built. In the framework’s vocabulary it’s an informal digital settlement (a useful solution created outside the shared architecture and controls). Registering it is the first step. For this app I’d stop at recognition, one of the four responses DWU allows for settlements, and I explain why in Shadow IT as informal settlement.
# Illustrative building registry record for Northstar.
# Field names are mine; they follow no standard.
building: field-visit-app
purpose: record sales rep visits to points of sale
district: commercial
jurisdiction:
entities: [entity-c] # only one of the five uses it today
data_residency: entity-c-rules
owner:
accountable: regional-commercial-management
sponsor: commercial-leadership
inhabitants:
- field sales reps
- regional supervisors
origin: informal-settlement # low-code, built outside the plan
lifecycle_status: temporary-structure
dependencies:
- customer-master # today, a manual copy from the ERP
cost: low-code license plus the manager's hours, not measured
obligations:
- personal data of point-of-sale contacts
renewal_decision:
option: recognition # for a settlement: recognition | integration | relocation | retirement
reason: already runs on formal ground and adoption is real; what it lacked was an owner and a review date
review_at: the district's next portfolio cycleTwo fields generate almost all the discussion when you fill in a record like this.
Jurisdiction ties the building to the territory. If the app only operates in entity C, entity C’s data residency rules apply to it. If another entity wants it tomorrow, that expansion is a territorial decision, and the record forces someone to make it instead of settling the matter by copying the app and its database into a second country.
The renewal decision puts a date on the building. Without it, temporary turns permanent through inertia, and within a few years the field-visit app ends up as a legacy installation nobody chose. That undecided drift is one of the ways urban debt builds up, the structural cost that later constrains change. The cost field says “not measured”, and many records will say that at first. I prefer that to an invented number, because it makes the missing information visible.
The customer master dependency points down to the subsurface (the data, metadata, lineage and semantics that buildings rely on), which I cover in the data subsurface no one sees. The definition of customer or margin has its owner in the district and is implemented down there.
Common, federated or local
The framework’s seventh principle, subsidiarity with federation, says each decision is made at the lowest competent domain level, while city policies preserve interoperability and trust. DWU doesn’t prescribe centralization; what it asks for is an explicit decision about which capabilities are common, federated or locally autonomous. That decision is best made before assigning buildings. To tell the three categories apart I use a criterion of my own, which is who sets the rule and who implements it.
A common capability is provided by the city as a shared service for every district, like identity, or the notifications Northstar currently runs three times over. A federated capability has an owning district that implements it and a city rule the others follow. The margin definition would belong to Finance, and any report labeled “margin” would use that definition or have to declare a different name. A local capability is decided by the district on its own, and the city only asks that it appear in the registry and use the common services. The field-visit app can stay local after it’s recognized and registered, because formalizing a building and centralizing a capability are separate decisions.
The Grupo Diveco case
In Portal Diveco, Grupo Diveco’s platform whose background I covered in the first article, every tool enters through a single registry, which is what the portal reads to build its navigation and apply permissions. As of September 2026 that registry held 51 tools spread across 16 business categories. The zoning is easier to see in the platform’s 3D model, where District 1, “Condominio Portal Diveco”, is divided into eight capability sectors (Reports, Administration, Sales, Operations and SAP, Management and Help Desk, AI, Finance and People) and District 2 is Human Capital.
The same map, which illustrates the mechanism without measuring it, also shows where the criterion breaks down. Other districts in the model are drawn by platform (RPA, the cloud port, AI and SAP), so the boundary is set by the technology the buildings run on, a close relative of the license org chart. The registry’s 16 categories are useful for navigation, but none of them has a declared district owner, so they fail the second half of the semantic test, the part that asks for one person who answers for the meaning. For each tool the registry stores its name, category, description, access permissions and a hidden flag. It has no field for owner, lifecycle status or renewal decision, which are exactly the fields in Northstar’s record that force a decision.
Adding those columns takes little technical work. Filling them in means naming owners and decision rights that aren’t documented today.
Signals that would test P2
The proposition that goes with this piece is P2. It holds that environments organized into capability districts will show greater alignment between strategic ownership and application evolution than environments organized around individual systems. Like everything in the preprint, it’s a hypothesis without empirical validation. It would be tested against capability maps, clarity of ownership and portfolio change history.
If P2 is right, I’d expect to see three signals at a company like Northstar. Changes to the margin definition would go through Finance, and the commercial dashboard would stop maintaining its own calculation. New applications requested by Commercial would show up registered in its district, with an owner, instead of being built wherever there was budget that quarter. Over successive portfolio cycles there would be fewer buildings without owners. If none of that changes after zoning, or if it changes just as much in a comparable company that didn’t zone, P2 weakens.
Better alignment could also come from regulatory pressure that forced some order, one of the rival explanations DWU itself acknowledges. Only a comparison across organizations could separate that effect from the effect of zoning, and that comparison is still pending.
When a boundary becomes a wall
Zoning improves accountability because every capability has an owner, and that owner now has territory to defend. Northstar’s analytical collections assistant needs customer data, which belongs to Commercial, and receivables data, which belongs to Finance. With well-drawn districts that query crosses a boundary, and crossing it takes a contract, a conversation and sometimes weeks of waiting. If district owners are measured only by their own indicators, the boundary becomes a wall and zoning reinforces the silos it was meant to organize.
DWU asks that this tension be treated as a moderator and an explicit trade-off. In practice, for me that means judging each district owner partly by the contracts they offer the other districts.
Where I’ve applied this in platform work, nobody argued much about the boxes. The arguments were about who decides at each boundary, and they outlasted the map. In a small organization with one or two systems and stable boundaries, all of this is bureaucracy, and the framework itself says it’s less useful there.
Who signs each category
The capability map can’t produce the common, federated or local classification. It only tells you which capabilities exist. Deciding which are common, which are federated and which are local redistributes power and budget, and someone with authority over the territory has to make that call and sign it. A capability with no category ends up local by default in every district at once, and that is where Northstar stands today, with three margin calculations and three notification services.
For the next portfolio review, I’d start with a short list, the capabilities that currently have more than one implementation. Next to each one, write down whether it’s common, federated or local, and the name of the person who signs that answer.
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 forgotten tradition of information-system urbanization. Next: Infrastructure before density: shared services.