Urban Networks

Networks and Complexity

While working as an engineer, I worked with some incredible teams. I worked with logistics and shipping teams, business teams that were trying to make a buck, and operations teams who were making the actual decisions on the ground.

The biggest disconnect between corporate and operations teams wasn’t the office location or job role. It was how well one could understand the complexity that comes with shipping a package. And there is a lot of complexity that comes with shipping a package.

The engineers of the business worked purely with numbers. We need data and metrics to make sense of operations, otherwise we’d be lost. Ops managers and their teams frequently knew their processes inside-out. They had a skill of take a complex system like a fulfillment center and making it simple enough to address the problem at hand.

They could estimate their daily delivery speeds based on the weather and the number of staff on hand. They planned for workforce numbers by reducing the problem to the target volume set by the business and the average speed at which they know their team can work. Most of the decisions made in this environment relied on getting rid of the unnecessary information to get the data you need to attack a problem.

Cities are Just as Complex

Cities are just as complex, if not more. They’re debatably humanity’s greatest invention, but that comes with a learning curve. Businesses and governments alike need to make sense of these complex environments to serve the people who live there.

Modeling the city as a network (a collection of nodes and edges) doesn’t do justice to the city’s real state, and that’s the goal. It strips away the complexity of road networks, traffic delays, and infrastructure information to solve the problem at hand. It’s easy to get pessimistic about the idea of intentionally throwing out information, but this is actually the key to big data.

A few years before I entered the field, there was this craze about big data. Cloud storage was cheap enough that storing data was relatively inexpensive, and so firms collected to their hearts’ content for later analysis. The issue is that it costs way more to analyze data than it does to store it.

When I actually started in tech as a Data Engineer, we were seeing the damage from that mindset. Forecasting models were bloated with features, poorly-designed data models inflated cloud costs, and I got to do the fun work of rebuilding my team’s infrastructure. This mostly meant getting rid of the data that we would never use.

Not only were they hiking our S3 and DynamoDB costs, but poorly-maintained data was making it into model training and impacting test performance. The only real way forward was to (1) find out the data my stakeholders actually used, and (2) dropping everything else. Cutting the noise lets us hear the signal. Trimming that bad data meant cutting out the noise from my RDBMS so the downstream decision systems would run as cleanly as possible.

Good decisions require the facts, and only the ones that matter.

A network model is a lens, not the whole city. When you abstract a street grid to nodes and edges, you aren’t denying reality—you’re choosing the right level of detail for a decision.

• For routing, you care about connectivity and costs (travel time), not every tree on the block.
• For resilience, you care about centrality—which intersections matter most if traffic or power fails.
• For planning, you care about flows—how people, goods, and information move.

If the model helps you decide faster and better, it’s working.

Fulfillment Networks as Complex Objects.

Think like an ops manager: define the network, instrument the few variables that make or break the day (weather, staffing, peak windows), and forecast feasible throughput. There will always be fire drills, but these are the factors that make for a good ops decision.

City Planning as a Game of Optimizing Connectivity.

Betweenness centrality is especially important for road and transit planning. Any city that relies on a single train line or road as a bridge between two areas is poised for a pretty serious breakdown when unlikely events happen. For cities, that’s just Tuesday.

Accounting for this in advance is key.

Making public service accessible with statistical precision.

Map clinics, schools, and transit stops to understand service deserts. Simple network reachability at rush hour can reveal inequities faster than complex microsimulations (and people spend a lot of money on microsimulations).

This is especially important in a city like Detroit. Most of the grocery stores I visit in the city lie on roads serviced by only one or two transit lines. Any public service delays, snow disasters, and acts-of-god would prevent me from transit access to groceries. And the situation is much harder for those living on the East Side.

The Bigger Picture

The networks that power our cities are rich with human variation, and that makes them inherently comples. Network thinking gives city leaders, researchers, and engineers a shared language for making sense without drowning in detail.

If you’re working on Detroit’s infrastructure—or any city’s—start with flows, it makes sense to (1) start from a question, (2) determine the evidence needed required to reach a conclusion, (3) fight like hell to get it.