Arbitraging on resilience concepts
Recently got AskTom on how you push new rule sets on a local level.
First thought: System Perturbations, or shocks to the system, are great catalyst. Right demonstrative one, like 9/11 or Katrina, pushes people to reset rule sets locally in a big way.
in this process of change, security always leads,as in fear. Resilience is just civilian for robustness (an old military term for the same thing).
So you get the System Perturbation, and the locals come together to protect themselves, gathering whatever constitutes the "pitchforks" of their age. If they reach for serious resilience, then what they end up building is so much more than a disaster response plan, it's a profound understanding of their environemnt in all its complexity and a networking of capabilities and mechanisms that creates a lasting good, easily translated into economic competitive advantage (e.g., I want a wireless communication network in my city, and what I create for that is a city-wide Wi-Fi that makes my city hugely competitive across a range of economic sectors). Point being, that's just a microcosmic version of what DoD did with the Internet (secure comms in nuclear war was original goal of DARPAnet).
This logic train triggered by the question referenced above and the following email from TM Lutas (Flit the blogger).
Me, I'm just arbitraging the concepts in the question-answer dynamic.
Here's Lutas' email:
A thought on resilience:
PARC (Palo Alto Research Center) has something called the Obje framework. This is something that is currently focused on resilient technology capability sharing. There is no reason that the same principles couldn't be extended to resilient capability sharing in disaster situations. All you're really doing is widening out the number of capabilities that are defined in the framework . . .
and what are the types of objects supported by the framework. An individual with a specific skill could be an Obje object, so can a disaster plans themselves as well as representations of all your physical infrastructure. To my observation, silo type behavior generally consists of magical things coming down the road into your jurisdiction or you shifting people or damaged items out of your jurisdiction. There isn't necessarily any thought given to what's going on the other side of the border and you end up with plan mismatch and armed sherrif's deputies blocking roads out of your submerged city. With tens of thousands of planning entities nationwide, there's an enormous scope for such misunderstandings and the larger the scope of disaster, the worse it's going to get.
If plans are written up as a nested series of objects with well defined interfaces, instead of mere text, the interrelations can be examined and the mismatches can be identified far in advance of any actual disaster. The criticism of this is that it's too burdensome for small municipalities to get that fancy with their planning when they may not have the skill sets. Those small municipalities generally submit their plans to larger groups such as towns and counties who continue to submit their plans upward eventually to the federal level. As text, it's an unmanageable, unreadable, unusable mess but as objects that understand how to talk to each other, a bit of computer crunching can come up with both unintuitive solutions to problems because there are untapped resources elsewhere and identify problems that lurk in the miscommunication that is inevitable across jurisdictional borders.