The public mapping site ran with a development instance alongside it, carrying the crime statistics map and a school finder, and feeding the intelligent transportation program with the state transportation department. ArcIMS on Windows Server 2003. It was fragile under load.
Three load events, twelve years, and a different answer each time
2010. A local television morning show featured the crime mapping site. Traffic doubled and the service fell over. The container log went from clean to unreadable across three weeks, and the fix was a firewall port-channel, worked jointly by the network and server leads.
2016. The Property Appraiser’s staff could not work through chronic slowness.
2022. Address lookups through the geospatial web service timed out at the start of hurricane season, with sustained high processor load on the database behind them, escalated here.
The answers were a firewall port-channel, then a version challenge to the vendor, then a replication-versus-capacity question. The same loop ran three times and what changed was the decision at the end of it.
A public map is a public service, and its peak load is set by whoever mentions it on the morning news — which is not a number anybody inside the organization can plan from. The service kept outgrowing the answer that had fixed it last time, which is the argument for sizing a public service against its worst day rather than its average one. That the third event landed at the start of hurricane season is the whole case in one date.
Answering a vendor who had framed a software problem as an infrastructure problem
In 2016 the platform vendor asked the City to produce server processor and memory figures during the slow windows, plus a network trace between the affected client and the database server.
It was produced — and producing it exposed a gap in the City’s own instrumentation. The automated capture was not working properly for that subnet, which was corrected, so the next slowness event would be measurable rather than argued about.
Then the question went back in the same message: what was the plan to upgrade to the current release, was there a date, and was the vendor still recommending it.
Supplying the telemetry is what earns the right to ask the version question. Buying hardware to carry a back-level install is how an organization pays twice for the same defect.
Two migrations, argued on cost
The geospatial estate moved off Oracle onto SQL Server, reported in 2012 among the enterprise architecture team’s contributions to the division’s accomplishments, with the case made on cost rather than on features. The record catches it mid-flight with both stacks live at once — desktop tools and the new server application connecting while the old platform was still trying to.
A second migration followed in 2019, tracked product by product off SQL Server 2008.
It became a life-safety dependency without anyone deciding it should
The 2018 computer-aided dispatch upgrade required priority-one geospatial street names and common-place aliases to be reconciled. That is the point at which map data stops being a convenience.
The platform was carried as a top-five candidate in the enterprise disaster recovery architecture, and the geospatial group held its own appendix in the continuity plan.
What it had actually become is visible in the 2019 migration inventory, roughly half of which is storm tooling: hurricane debris tracking, construction and demolition debris, vegetative debris. A map estate had turned into a recovery system, and the inventory says so more honestly than any architecture document did.
Outcome
A public map estate sized against its worst day rather than its average one, and recognized as a life-safety dependency before anything proved it the hard way.