Public Emergency Information Platforms

Most of emergency management architecture faces inward: the operations centre, the dispatch platform, the radio system, the continuity plan. This is the part that faces the other way.

A public preparedness service is unusual in two respects, and both of them are architectural rather than editorial. The first is that its peak load and its worst day are the same day. Every other public service degrades under load that arrives on an ordinary afternoon; this one is quietest when nothing is wrong and gets hit hardest at the exact moment it has to work. That is an argument for testing it on a schedule rather than discovering its ceiling during a storm.

The second is that the moment an organization’s own emergency communications name a platform as a path information will travel — in a storm release, in a mass notification, in a press conference — that platform stops being a website. It becomes part of the public information chain, which means its availability belongs in the disaster recovery architecture alongside dispatch and the operations centre, and its external reachability becomes somebody’s named responsibility rather than an assumption.

The failure mode worth watching for is not the obvious one. A preparedness application that is down is visibly down and gets fixed. A preparedness application that is reachable from inside the organization and not from outside it looks healthy to everyone testing it, and is useless to the only people it exists for. The same asymmetry runs the other way: a release that fails only on the organization’s own network leaves staff — the people residents ask during an activation — believing the service is broken.

Shared-tenancy hosting makes both questions sharper. When the preparedness site runs on the same content platform as the main municipal site and a row of independently governed agencies, the continuity tiering of that platform is the continuity tiering of the life-safety service on it, and capacity planning stops being per-site.