What Enterprise Architecture Can Learn from Urban Planning

A few months ago, while walking through an old neighborhood in Lyon, one of our architects made an observation that stuck with us: "This neighborhood is exactly like a legacy IT landscape. Layers stacked over centuries, alleyways that no longer serve a purpose, buildings half-renovated, and yet it works. People live here, work here, move through it every day."

We found the parallel quite fitting. And the more we dug into it, the more we realized that urban planning and enterprise architecture share a lot more than you'd expect. Not just metaphors. Real problems, similar tensions, and above all, lessons that urban planners learned a long time ago and that our discipline is still catching up on.

Nobody Rebuilds a City from Scratch

This is probably the most fundamental lesson.

Urban planners have always known that you don't raze a city to build a new one. It almost never happens (and when it has, the results rarely lived up to the promises, Brasilia being an interesting example). You work with what's already there. You renovate, extend, repurpose, and sometimes work around.

In enterprise architecture, though, we've long been fascinated by the "big redesign." The perfect master plan, the five-year target, the ideal architecture drawn on a blank page. And then reality catches up: the budget isn't there, the teams are busy keeping things running, business priorities shift every six months.

Urban planners call this the palimpsest city: every era leaves its trace, and the new layer builds on top of previous ones without ever fully erasing them. A corporate IT landscape is exactly that. COBOL from the 80s still running, an ERP deployed in the 2000s, microservices from 2022, and an AI layer from 2025.

That's not a bug. That's the nature of the system. And the best urban planners don't complain about it: they learn to work with it.

The Plan, the Territory, and the Permanent Gap

Urban planners have a central tool: the master plan. It's the official map of the city, with its zones, its rules, its projections.

And every urban planner will tell you: the plan is never perfectly up to date. There's always a gap between the map and the ground. A building that was constructed but isn't on the plan yet. A usage that changed without the zoning catching up. A neighborhood that developed differently from what was expected.

Sound familiar?

In EA, we have the same challenge. The application map is rarely an exact reflection of the real IT landscape. There are applications that were decommissioned but still appear on the map. Flows that changed without anyone updating the diagram. Projects that evolved the architecture without going back through the review board.

What urban planners figured out is that the gap isn't a failure. It's structural. The point isn't to have a perfect plan. It's to have a plan that's current enough to support good decisions. And for that, the plan needs to be easy to update, not a monument you touch once a year.

Zoning Is Good. Connecting Is Better.

A city is divided into zones: residential, commercial, industrial, mixed-use. That's useful for organizing, regulating, and planning. But the most interesting urban planners will tell you that what actually makes a city work isn't the zones themselves. It's the connections between them.

A metro line linking a residential area to an employment hub changes the dynamics of both neighborhoods. A bike path running through a park creates a flow of life that didn't exist before. A market at the intersection of three districts becomes a mixing point that no zoning plan anticipated.

In enterprise architecture, we often have the same zoning instinct: we divide the IT landscape into domains (Sales, Finance, HR, IT), assign responsibilities, and draw boundaries. That's necessary. But if we stop there, we have a nice map with well-colored zones and no understanding of the flows running through them.

The real value of an architecture map, much like an urban plan, is making the connections visible: how data flows between domains, where the critical crossing points are, where the bottlenecks sit, which paths business processes take as they cross organizational boundaries.

Citizen Participation and Collaboration in EA

There's another parallel that resonates with us.

In the 1960s and 70s, urban planning was a top-down affair. Architects and technocrats designed the city from above, and residents discovered the results. That era gave us tower blocks, urban highways, and quite a bit of frustration.

Since then, urban planning has evolved toward much more participatory models. Public consultations, co-design workshops, participatory budgets. The idea being that the people who actually live in the city have ground-level knowledge that no expert can replace.

Enterprise architecture is at a similar crossroads. For a long time, mapping the IT landscape was the domain of a small group of certified architects. They produced exhaustive models, in a technical language (ArchiMate, TOGAF), that the rest of the organization rarely looked at.

We're seeing more and more EA teams trying to open up the process. Involving business stakeholders in the mapping. Making views readable for non-technical audiences. Allowing teams on the ground to contribute, correct, and fill in the gaps.

It's not easy. Just like in urban planning, participation requires the right tools, a shared language, and a genuine willingness to share decision-making power. But it's probably the direction things are heading.

Think in Flows, Not Monuments

The cities that work best aren't the ones with the most beautiful buildings. They're the ones where people move well. Where energy flows, where interactions happen naturally, where services are accessible where they're needed.

Jane Jacobs, one of the most influential thinkers in modern urban planning, argued that the vitality of a neighborhood comes from its diversity of uses and the density of its interactions, not from the grandeur of its plans. She was deeply skeptical of large top-down projects, and preferred observing how people actually used the city before proposing anything.

There's something very applicable to EA in that. The best information systems aren't necessarily the cleanest on paper. They're the ones where data flows well, where teams can access what they need without going through five intermediaries, where new services can plug in without breaking everything.

Thinking about architecture as a network of flows rather than a set of blocks is a shift in perspective that urban planners made decades ago. We're probably in the process of making it too.

This Is What We're Exploring at Boldo

This parallel with urban planning inspires a lot of how we think about Boldo.

We're trying to build a tool that fits this logic: not a monument you update once a year, but a living space that reflects ground-level reality on an ongoing basis.

Work with what's there. Boldo connects to your real data sources so the map starts from the IT landscape as it is, not as you'd like it to be.

Make flows visible. Beyond the components, understand how data moves, what the dependencies are, and where the critical points sit.

Open up participation. A readable, accessible space where business and IT can contribute together, without needing a degree in modeling.

Accept the gap. Rather than aiming for a perfect map, make updating so simple that the gap stays minimal.

The perfect city doesn't exist. The perfect IT landscape doesn't either. But we can build tools that help navigate complexity rather than pretend to eliminate it.