“Blogs, tweets, spaces, pages, books, oh my. There are so many voices that create so much noise, why on Earth do I think anyone would be interested in reading my blog?” I said to myself. I believe that I’m in fairly niche role, one that has some fundamental differences to similar roles and yet other differences are splitting hairs. When someone asks me what do, I’ve got it down to single, run-on sentence: I’m responsible for all the technology the American Red Cross deploys to large-scale disasters – between 50 and 70 per year where each lasts from two to four weeks. My team and are unique convergence of emergency response management, technical mobility, infrastructure stability and the critical interface between people and technology. Honestly, you probably think that I’m playing buzz word bingo with that statement so let me break it down.
Emergency response management is our capacity to work with the other facets of the Red Cross Disaster Services department to manage the response to the disaster, specifically responding to the humanitarian needs. Understanding the command, control and communication structures of disaster is necessary so we can speak the language of disaster response. We need to understand the needs and responsibilities of all of the segments of response to ensure we can provide the technology they need to do their tasks.
Technical mobility and infrastructure stability are usually viewed as oppositional, yet we need to bring them together in harmony. Our technology needs to move … and quickly. Our people need to assemble it and make it functional … and quickly.
And then we have all the end-user expectations of traditional IT shop of high up-time. This is where it gets amusing. Most traditional IT shops focus on maintenance and aim for the holy grail of 99.999% uptime – that is about 8 minutes of downtime per year. Every solution that traditional IT shop implements is custom one for the customer’s problem. There are meetings and change control documentation to change the network, install routers, switches, and so on.
My team and focus on speed to scale. We go into an empty building in an area just struck by massive disaster and — usually overnight — string up 50 to 150 workstation office complete with computers, IP phones, printers, faxes and connectivity through satellite link. Our solution is practically cookie-cutter with the same fundamental plan reapplied over and over again. The cultural differences to get this done are why usually say that a traditional IT shop is not positioned to do what do and we are not positioned to do what they do.
Similar to traditional IT shop, we also need to maintain our core infrastructure. We have two teleports for the satellite connectivity (or land-earth station if you prefer). We have our own call manager for the IP phones, email servers, file servers and so on that mirrors the corporate infrastructure. We need to be good network citizens to protect the security and integrity of the corporate network. After all, we are extending the corporate network to disaster zone and could potentially increase the risk exposure of the corporate technology infrastructure.
The human-technology interface is critical because if the responders can’t use or understand the technology, then it is all useless. We need to issue the equipment to people, track the inventory, educate the user, trouble-shoot problems, and generally be there to make it work. I have not run across many emergency responders who would consider themselves technical expert in addition to their expected expertise. These are the reasons why I’m going to start this blog. With the stage set, these first few posts will explore these topics. I also intend on plagiarizing (with credit) information from other sources that either directly or tangentially overlap. Let’s see where this stream of conscious leads.