3 Tenets on the Integration of Information Technology with Emergency Management
Information Technology integration in Emergency Managmeent isn’t about learning to write code or compile, it’s about data, how to mine information from data, and how best to minimize gathering poor data. It’s also about being able to identify new kinds of risks, new kinds of add-on hazards to natural ones, and how to protect yourself from the growing problem of Psyops in the midst of recovery.
One of the most pernicious issues aspects of the concept of, “Technology in Emergency Management” is that most of the products created aren’t well-conceived for the use context emergency management needs. Smashing a shiny new piece of software into every Emergency Operations Center in the country is a lot like giving a starving child a computer instead of food. The child will still starve if you’re simply expecting them to be able to boot the machine up and go to doordash or grubhub.
And that is basically what technologists have been trying to do for some 20+ years. We need to begin to think about tech in emergency management in a radically different way than we think about tech normally.
For example, EM is a domain wherein the various aspects of humanity that we’ve created to maintain, augment, or alter society (non-human entities like social media, electricity, and everything considered infrastructure):
- Does not exist because of poverty.
- Does not exist because all infrastructure is destroyed.
- Or / And, no longer exist because they have created a problem that needs to be dealt with as a hazard.
In essence, EM is a domain, a discipline, a trade, and a field that has to deal with our (often lack of) incapacity to think about design fully. What this ultimately means is that EM is the only domain that protects us from ourselves. Its continual lack of funding, lack of solid identity, and an incomplete individuation reifies the basic lack of hindsight, foresight, or insight we possess.
Oversights like those discussed by
in his excellent book Ruined by Design: How Designers Destroyed the World, and What We Can Do to Fix It provide numerous examples of just how destructive we can be to ourselves (especially when money is on the line). For every lack of forethought, a tiny group of people will inevitably have to work together, often harming their mental, fiscal, or physical health, to clean up that mess. Even those natural hazards provide us with a innumerable, often highly volatile hazards that are inevitable…but still ignored or incorporated into design.
As example, i’ll offer my own paper on the application of design to location-based games for disasters:
LaLone, N., Toups, Z., & Papangelis, K. (2022). Practical Considerations on Applications of the Popularity of Games: The Case of Location-Based Games and Disaster. In International Conference on Human-Computer Interaction (pp. 213–233). Springer, Cham.
Location-based games or any app devoted to mapping / location could be used in the midst of disaster without cellular service provided a mesh network be spread across a city that activates upon loss of electricity. Things like this could be used to actually “be responsible” with the products folks design.
From set up to action
And so, what i’ll offer for my own book is that EM practitioners do not need to know how to write software, how to design software, but to understand design, understand technology enough to know what, how, why, and where a failure or loss of control could begin or could be taken advantage of.
Because that’s where we’re at at the moment. Disasters could be because someone doesn’t know how to do authorization, password maintenance, or even have the capability to do any of that stuff (because again, the designers didn’t make it easy enough for them to learn).
And so we reach that point. If i’m reaching the point where I need to answer, “What Outcome Does Emergency Management Need in Data Science?”
The outcomes they need are essentially the themes and objectives of this project. I’ll outline them now.
Main Themes and Objectives
These were a required aspect of the proposal that I sent my publisher. While at first I was a little worried that I was being insulting to EM practitioners, I realized that I was being as plain as possible because I should not be trying to hide or otherwise walk back how dire this situation is. In fact, i’ve recently written about the, “Tech Crisis in Emergency Management” and will be presenting it next week in Hawaii (and have already given a talk about it at the International Association of Emergency Management AND in my Emergency Management Institute’s Advanced Academy). As I was approached by a publisher due to these activities, I am somewhat excited that I seem to have tapped into a spot where there is interest, but not a lot of options because it is such a mis-understood space.
Central Theme:
The central theme of the text is that:
There is a technology crisis in emergency management and to fix it, computation must be inserted into the National Incident Management System (NIMS) or Incident Command System (ICS). Both technology and emergency management need to change in order for this to occur.
The purpose of this theme and its importance is based on a report from the Office of the Inspector General that notes that FEMA’s long-standing tech deficiencies can be:
…attribute[d]…to the FEMA Chief Information Officer’s limited authority to manage IT agency-wide, as well as to a decentralized resource allocation approach that hinders funding for the centralized IT environment. These deficiencies are not new, and were reported in prior Office of Inspector General audits throughout the last 13 years. Continuation of this approach impedes budgeting for long-term IT enhancements, leads to overspending, and causes unnecessary IT support efforts.
Amid this management environment, FEMA has not provided its personnel with the IT systems necessary to support response and recovery operations effectively. FEMA’s legacy IT systems are not integrated and lack the functionality needed to keep pace with high-volume processing. Additionally, the systems FEMA personnel rely on for situational awareness and emergency response coordination do not always contain real-time data nor do they support information sharing with external partners.
So in essence, there is no spot for technology in the guiding framework of EM, that of the National Incident Management System (NIMS) or a part of NIMS, the Incident Command System (ICS). As such, any text that begins with technology integration in EM needs to begin with where IT can fit within it. As outlined above, I am not of a belief that technology needs to be an essential part of EM but what technology can do in terms of hazard-events or communication should be. Therefore, we can simply augment small portions of ICS and/or NIMS with where Tech can go.
NIMS came into being in 2004 (a factor of 9–11–2001) but failed to incorporate the growing threat and power of technology. While silly, given the tech boom that was about to happen, it’s important to contextualize this. In 2004, the after-effects of the WTC attack was still being felt. However, it is also true that the tech bust in conjunction with the attack fostered a sort of lull up until 2004–2006. So, it’s not a surprise but it does tend to reflect the chronic lack foresight that humans tend to exhibit, especially when politics is involved. Correcting this aspect of technology is of absolute importance but cannot be directly fought (in much the same way as any -ism), so fighting this will be a long-game. So what is next?
Objective 1:
Next, we have objectives needed to meet that theme. These are small steps but vital, and delicate. The first falls in to the most important task any textbook about tech can do, providing adequate scaffolding to help make tech easier to adopt. Here, we can see the objective plainly:
Provide useful readings for emergency managers who are afraid of technology in order to contextualize the nature of the crisis as seen through technology, consumer communication technologies, and the future.
Objective 2:
The second objective of the book builds on the initial introduction. If the first step doesn’t take, this step doesn’t matter, but it can provide some useful content for the future. For example, the tenuousness of this step is I can show that tech ain’t so bad…but then fail to reinforce that positive outcome. As such, we need to be obsessively predictive in how to introduce technology, its various problems, and how one could use it in practice in various phases of emergency management. So, we see the objective defined as:
Provide exercises and scaffolding for faculty in emergency management and homeland security (and students in and out of those programs) that practitioners can build on.
It works, for now, but I have a lot of work to do in actually defining those things, seeking the proper scaffolding, and various kinds of activities that can reify technological use while also expanding on technology’s capacity for creating disaster.
Objective 3:
The last objective is basically closing the loop. We have a goal of fostering an emergency management that comprehends technology as well as it understands natural hazards so that it may incorporate it into their everyday practice. Once this is done, the final step, the final objective, is to basically provide what amounts to design fiction of tech in EM. And so, the final step is to:
Provide accounts of how emergency management will begin to change given the way consumer technology is shaping consumer behaviour.
And with these, we have a bunch of goals to build in and around to produce an outcome that is worthy of all this effort. Up next, digging in…