Instant Collaboration: Using Social Networks in Emergency Response

September 2012
Topics: Emergency Preparedness and Response, Systems Engineering, Collaborative Computing, Cloud Computing
Crisis events require a diverse set of response agencies, as well as their respective systems and services, to collaborate smoothly.
Emergency responders

Crisis Computing

The recent earthquake and tsunami in Japan prompted a massive humanitarian response. Innovations such as Google People Finder and other computing tools allowed relief groups and citizens to coordinate the mobilization of people and supplies. At the same time, civil, military, and non-governmental organizations used their computing capabilities to collaborate in allocating scarce resources appropriately.

Crisis events may vary, but they all require rapid response from agencies and communities. To coordinate their activities, these diverse responders——who probably never expected to be working closely with each other prior to the event——must assemble computing capabilities that can share information and work in concert with each other.

Assembling shared computing power is a difficult problem. Creating computer systems flexible enough to address the needs of both individual and cooperative response efforts is tough to achieve with traditional systems engineering. Agencies initially produce their computing services and systems without knowing how they might work with other agencies' systems in a response effort. Capabilities designed in the initial production might prove incompatible with other systems or not flexible enough to meet the needs of a particular response effort.

Instant Collaboration Using Social Networks in Emergency Response

Some Late Assembly Is Required

Because we can't force all response agencies to use the same systems and services, we need an "Instant On" ability to pull diverse responders and their respective computing capabilities together in a short period of time. One method for creating an Instant On capability requires system designers to focus on "late assembly of a capability" and "shared agreements."

Late assembly of a capability decouples the development of systems and services from the assembly of a shared capability. Instead of designing whole capabilities upfront and hoping that they prove compatible with other systems and applicable to future response efforts, designers create the components for capabilities and assemble them as and how they are needed.

In essence, capability design will follow a Home Depot model. If you need to add a room to your house, Home Depot won't sell you a room. Home Depot doesn't know how much space you have in your house for a room or what you want to use the room for. Instead, Home Depot stocks all the components you need to build a room that fits your requirements.

Agreeable Components

But when you buy supplies from Home Depot, how do you know all the plumbing will fit together or the electrical components will be compatible? You know because the various plumbing and electrical component manufacturers have agreed to common standards. In the same way, response agencies create and maintain a set of shared agreements on capabilities.

One form of shared agreement is the adoption of a technical standard. However, we see an even greater use of shared agreements to cover conventions for identity and access management, security, test, accreditation, data semantics, privacy, and process coordination. This enables each agency to independently build the systems and services it needs for its mission, while certifying that key systems and services will meet applicable shared agreements for future assembly into shared capabilities during a response.

MITRE advances the Instant On concept in three areas. First, we work with sponsors to help them build deployable examples of late assembly of a capability, creating an agile and adaptive ecosystem where component providers independently and concurrently produce components that are certified to meet shared agreements. End users can then assemble these capabilities, based on the shared agreements they have in place, when the need arises for them. Finally, in a departure from traditional systems engineering, where development is driven by unchanging requirements, the Instant On concept allows end users to give direct feedback on the components back to their providers, which is used to shape future component development.

Second, MITRE helps its sponsors coordinate "co-engineering" sessions in order to build the close collaboration and cooperation required by an Instant On ecosystem. These sessions build shared understanding, which optimizes group performance and ultimately creates shared agreements for capability assembly and other related purposes.

Third, in order to better apply Instant On concepts to future sponsor work, MITRE conducts fundamental systems engineering research to learn what makes co-engineering teams effective, and what support—ranging from distributed collaboration tools to complex visualization techniques to anthropological considerations—is optimal.

Using Instant On systems engineering approaches, responses to critical events will be significantly different. Responders will have system and service components "on the shelf," pre-certified to applicable shared agreements, and ready for assembly in the field. When responders need to negotiate new, shared agreements, co-engineering teams will convene to hammer them out. Markets will serve as a community hub for driving component innovation and for sharing lessons learned from each event response. Response effectiveness will be dramatically higher, especially in the early response period, where today we frequently experience a great deal of chaos.

By helping response agencies adopt and use Instant On systems engineering methods, they can more readily assemble and evolve shared capabilities in the field. In turn, this lets agencies respond more effectively, helping them to help us in time of crisis.

——by Harvey Reed


Publication Search