In Java programming, there is the idea of a "virtual machine." A virtual machine is a computer system that doesn't exist in real life. Yet programs can be written for it. The code is interpreted by a runtime environment. Through this arrangement, Java programs can operate on different operating systems rather than one exclusively. Depending on one's background, the concept of a "virtual organization" might be unfamiliar. The abstract organizational structure can be invoked to deal with emergencies. I recently wrote about participating in a tabletop exercise simulating a train derailment. Our group took on the form of the organization. This means that certain roles and functions, internal processes, and logistics could take shape in a short period of time. There was little need to build up from scratch. Whether there is an earthquake, pandemic, or terrorist attack, the abstract organization can be invoked. People can work on processes that "run" on this virtual environment - even before play or any incident occurs. In this blog, I will be writing about the possibility of implementing a standardized data system for the environment. I will discuss how data can be extracted from behavioural tagging in a transactional environment.
I recently wrote about the hazards of the "institutional response." I said that there is a need to gather data in order ensure the effectiveness of the response. Although I was writing in generalities, I was actually setting the preamble for this blog dealing with a data system for the virtual organization. The standardized structure - whether in its purely abstract form or instantiated to deal with an incident - represents a type of institutional response. The organization has to adapt to the circumstances of its operating environment including the availability of resources, the interactive dynamics between people, and the nature of the challenges that must be confronted. This sort of adaptation requires an abundance of data. Consider for example a war game (simulation). Seriously give some thought on how the behaviours and interactions of people should be converted into data and made accessible. How precisely should details be symbolically converted and retained? Vagueness and generalities don't work when writing computer code. Up to a point, the challenge relates to programming. However, I suspect that even skilled programmers would wonder about how to configure the data and data system to make calculations even possible.
At some point near the end of my derailment simulation - as the number of key events started to build up - I began questioning how a person might go about preserving details of the complex interactions. I pondered on how the data can be made accessible for study later - particularly using a computer. For organizations, there is probably a need to "externalize" the insights gained from simulations: learning should not be a process limited only to those that participate. It should be possible even for those that don't participate to learn from experiences. An idea came to mind as I was trying to deploy and keep track of my resources during the simulation. I thought that it might be worthwhile to translate certain types of behaviours into transactional data. Keeping in mind my earlier comments about the virtual nature of the organization, the data system if functional might run on every instance of the organization regardless of the exact application. I notice that are already management products that take advantage of the virtual org (example).
What Transaction Data Is
I think that when people talk about "transactions," they usually mean financial transactions. I have found that almost anything can acquire the look and feel of a transaction. A transaction can exist for any transferable asset - giving rise to data such as time, source, destination, quantity, type, and duration. Specifically in an emergency simulation, items that can be transacted might include the following: police cruisers, ambulances, buses, trucks, firefighters, police officers, nurses, food, clothing, beds, phones, and computers. I would say that there are limited dimensions when dealing with financial transactions. In a non-financial context, on the other hand, it is possible to "sell suggestions" and for others to "buy suggestions." A person can ask for "all available suggestions" and then accept a handful of a certain type. Converting group dynamics into transactions is probably no simple feat. I recognize that the conversation will not end with me. I just want to offer up some ideas.
Transactions by Tagging Method
Since I had resources available for deployment during the simulation, I was surprised that nobody asked me what I had to offer. I decided that - rather than relying on the attitudes, impressions, and instincts of participants - there had to be a friendly and constructive way for a person to "bring products to market" so all available resources are out in the open. It is not necessarily a participant's place to impose resources on other people. I also understand how, given competing priorities, a participant cannot necessarily be given the time or opportunity to routinely update others on the current availability of assets. I though it would benefit everybody for me to be able to maintain an up-to-date inventory of products and services in real time; this inventory would be presented to market maybe using a type of dashboard. In retail, the transactions that people know best occur at the point of purchase; of course, there are all sorts of transactions throughout the process long before the purchase. I propose that transactions can be used as a type of universal communications language
The "market" would have also served to tell me what other people needed. I could attempt to obtain the items not on my inventory but within my scope of influence. The data system would therefore have the ability to influence workflows and priorities within the standard organization. It could help people exhibit the most enabling and constructive behaviours possible given the pressing needs of the organization.
I had a difficult time keeping track of where I was putting resources - remembering how many assets were placed in which locations to perform what specific functions and duties. I also had difficulty determining and therefore reporting existing balances. I started using something almost resembling a ledger, which seemed rather awkward. I reasoned that it would be better for a computer to manage the bookkeeping: it could generate data streams to reflect my current status and also support future strategic analysis. I developed a tagging system as a precursor to the processing environment. The tagging approach is described using the two tables below: the top table is for the participant to use in his or her role gathering resources; the bottom table is used for the distribution.
CA0-StrikePackageObject: the collector needs any strike package available
DE0-StrikePackageSupplyObject: the dealer can offer a limited strike package
CA1-StikePackageAcceptanceObject: the collector will accept anything sent
In the above examples, the first three characters determine which table is being used and the placement on the table. The tags provide information relating only to the movement of objects. It might already be apparent from these few examples that the transactional environment converts simulation exercises essentially into a type of chess game. I know that playing chess is probably not widely regarded as a transactional activity. Nonetheless, there is a movement of assets on the chessboard. The pieces have primitive functions. A knight can move in L-formations. One would not send food and water to a knight in chess. However, the basic idea of deploying assets strategically in a transactionally-supported simulation is comparable to playing chess.
In a normal transaction for example in a retail setting, there is an exchange of cash for goods and services. No effort is made to understand the reasoning behind the transactions - probably because the reasons can be so varied. But I believe this is a certain reoccurring rationale applicable to emergency scenarios: 1) the perceived abundance of inventory in relation to the dealer; 2) the perceived abundance in relation to the collector; 3) the perceived abundance of the broader market excluding the collector; and 4) the perceived abundance of the broader market excluding the dealer. I will give an example. Assume the collector would like to obtain a piece of merchandise from the dealer. The dealer would therefore need to have some inventory. The collector approaches the dealer due to perceived abundance. However, the collector can also pursue other sources in the market if there is a perception of relative abundance on the exclusion of the dealer. The asset object can retain details of these perceptions.
Details of physicality can also be embedded in the object: location of the merchandise; destination; package dimensions; weight; and the name of the private sector supplier. It might seem wasteful to record these details within data objects. However, we have vast computer processing capabilities these days. Consequently, the tagging system holds information about the movement of assets while the objects have details about the underlying assets and rationale behind the exchanges.
Conversion of Language to Transactions
A rather specialized area of data science deals with the need to extract meaning from large amounts of text. Any kind of dependency on normal conversation during an emergency can be problematic given the lack of normalcy in the situation. I have raised the use of transactions to get around not just the linguistic barriers but also lack of interactive norms that become apparent in big emergencies. For example, it can be said that there are probably differences between police departments deployed during a multi-jurisdictional emergency. But the lack of a stable situational language becomes really apparent once different functions become involved in the operation: e.g. police, paramedics, hospitals, fire departments, city public works, and maybe the military. Given the absence of commonalities in communication, this setting is actually problematic for the extraction of data - assuming the absence of a logical intermediary. The logical intermediary - that is to say, the transactional environment - can on one hand be considered a unifying language and on the other a means to capture computer-friendly data from all the turbulence.
Extraction of Data from Transactions
I'm unsure how others approach the extraction of data from a relational data stream (a stream that explains how things relate to each other). I generally "throw events." Given the framework I just described, it would be possible for events to be thrown for all of the following: when people request for services; when there is an agreement to send services; when there are inadequate resources to meet the demand; when there are excess resources; when the services are sent; when delivery is required for a specific time and location; when all available suppliers are canvassed; when there is network failure to provide the service. The possibilities can get quite lengthy. When a particular situation occurs, an event symbolically representing that situation can be thrown, causing a registration of value such as an increment. How exactly the resulting numbers should be handled is quite a big topic on its own. For example, I'm sure some would make use of a statistical approach.
For now, I just want to focus on the how the data system on one hand can record and maintain transactional data - from many different participants and the group as a single entity - while on the other hand generating streams of data during the execution of the simulation. I emphasize this latter point because I think there tends to be a jump in reasoning that precariously diminishes the challenge of the undertaking. It's been said that highly skilled individuals are needed to do all sorts of complex calculations. That's rubbish of course. Computers do complex calculations. The theorization to enable computer processing requires some effort. Suffice it to say, "Let's collect some data" might not be as simple as it seems once a person has to break down behaviours and real-life events into computer code to enable bulk processing.
Characteristics of Flow
When I originally started writing this blog, I thought about expressing the dynamics in relation to "buyers" and "sellers." (I use these terms conceptually rather than literally. There isn't necessarily any real buying or selling.) I consider some participants in a simulation both buyers and sellers. What is bought from an outside supplier can later be sold. Consequently, I avoid the term "buyer" and instead make use of the term "collector." A collector can become a dealer. On the image below, I try to highlight the direction of flow between dealers and collectors involved in an ICP-EOC relationship; these dynamics existed during my derailment simulation. The symbol D-C indicates a dealer-collector function. S is a private sector supplier or the main source of a particular product or service.
I don't want to confuse matters by elaborating greatly on what is an ICP or EOC for those unfamiliar with the acronyms. The entities tend to be invoked or activated during an emergency. However, I will point out that both these entities usually exhibit the organizational similarities I mentioned earlier. Such instantiations might therefore represent candidates for the data system for the transactional environment. I certainly believe that for instances of the organization that persist for some time, the data system might be useful even on the absence of an emergency. The virtual org simply provides some reference points to plug in the data system.
My objective in this blog is just to get some ideas out for others to consider. I hope readers find the general concept of making use of transactions worth considering for their own initiatives. I discussed the distinction between transactional code and events. I said that events can be used to generate quantities, which might then be accessed using statistical methods. However, events do not have to be interpreted in a traditional mathematical sense - focused on the amplitudes. For example, events can be portrayed fractally for the purpose of pattern recognition. When dealing with complex data objects, I consider the idea of reducing the complexity into neat and simple numeric streams of numbers for convenient statistical analysis borderline blasphemous. However, I hope most would agree, irrespective of the approach or methodology ultimately used on the data, it is first necessary to collect data. This seems like a simple observation on the surface, but actually the underlying mechanics of such an undertaking are probably quite elusive.
The sophistication and stability of the virtual machine has helped to preserve usefulness of the Java code. I still use code that I wrote in the 1990s on different platforms. Similarly, I believe that the virtual org will create many data-oriented opportunities. When organizations talk about data silos, this represents a nagging problem that can adversely impair the performance of assets. When these silos exist in emergency situations, the ability to overcome them might mean the difference between life and death. If there appear to be silos, one way to determine the nature of the impairment is through testing and data gathering during stress testing - for example, during a simulation or exercise. In this blog, I have suggested that, in support of data-gathering, it can be useful to implement a data system intended for the virtual org; because it becomes possible to gain insights in relation to different instances of the organization regardless of the exact application.