Page Last Updated: Wednesday, 27 January 2016 09:43 EDT, 2001, 2002, 2008, 2016

HARTLEY CONSULTING
Solving
Complex Operational and Organizational Problems

PROJECT: Joint Virtual Analytic Center (JVAC)

Dr. Dean S. Hartley III


Project Metadata Keywords
Label Name Other Year DurationYrs
Client J8 The Joint Staff
Dates 1999 1.1
Employer DOE Oak Ridge Facilities
Partner N/A
Pubs JVAC Architecture, Phase II, Y/ACT-3170 lead author 2001
Pubs JVAC Architecture, Phase I, Y/ACT-3149 lead author 2000
Team Mike Borgsmiller, Curtis Light, Steve Payne
Classification issues
Collaborative computing
Computer hardware issues
Configuration management
Decision analysis
Distributed analysis
Information storage and retrieval
Knowledge Management (KM)
Metadata
Military study process
Organizational structure
Software issues
Software reuse
Virtual environment
Web design

Purpose: The purpose of the JVAC is to increase the analytic capabilities and capacities of the joint analysis sites, despite flat or declining budgets. We defined the requirements for electronic collaboration to support joint analysis at the Unified and Specified Commands and implemented the system in both an unclassified and a classified environment.  Figure 1 depicts some of the JVAC concepts.

Figure 1


Joint Analysis Background:

Analysis projects may be divided into five basic phases (Figure 2): search the literature, refine the study plan, collect data, analyze the data, and report the results. The first phase involves a "literature search." This search includes a search for previous Department of Defense (DOD) analysis projects that bear on the current project, as well as a more general search of documents that might inform the analysis process. We are using the word "literature" very broadly to include a wide variety of information sources, including live experts. Thus, search areas would include other Commands, the Services' analytic organizations, Office of the Secretary of Defense (OSD), and J-8 for projects and the Defense Technical Information Center (DTIC), the Service schools and academies, plus civilian university libraries, for relevant documents. The JVAC information collection facilities will be part of this phase.

Figure 2

The second phase involves a refinement of the study plan to select the appropriate model (or models) to use in the study and the decision on how to use the models (including where and by whom the model(s) will be run). Part of the model selection process is identifying people with appropriate skills (in the context of the project) to illuminate the issues under investigation. Collaborative discussions (including the use of e-mail and phone calls) will be part of this phase.

The third phase involves collecting input data, running the model(s), and collecting the output data from the model(s). Each of these may or may not involve collaborative processes. The data collection can involve discussions with several sources (e.g., intelligence agencies, logistics experts) concerning the precise types and formats of data needed for the study, including model-specific assumptions and data modeling required to convert available data into the data required for each model input. The data then must be transmitted to the organization(s) running the model(s). Further collaboration may be involved in describing the concept of operations for each model run to support the experimental/study design and in synchronizing and aligning efforts among the collaborators. These two parts of the third phase will require voice, text and graphics collaboration to ensure complete understanding by all parties involved. Desirable graphics collaboration might involve collaborative viewing of PowerPoint slides, static model screen shots, imagery data, or spreadsheets. Or graphics collaboration might require the more challenging task of simultaneous views of a model's graphical user interface (GUI) during model execution. The collaborators may include various DOD organizations and contractor organizations (most notably the Joint Analytic Support Program (JASP) contractor) at various geographical locations. The data collection may be straightforward transmission of data files to the study group or it may mix with the fourth phase.

The fourth phase involves analysis of the data. In some cases, the supporting organizations running a model or models for the study group may participate in the analysis. In this case, collaboration using voice, text (e.g., databases and spreadsheets) and graphics (e.g., PowerPoint slides) will be required to ensure complete understanding by all parties.

The fifth phase involves creation of the analysis report and briefings of the results to the study sponsor. While this might require collaborative work involving document management, US Pacific Command (USPACOM) analysts stated that (in their opinions) collaborative document management would be relatively minor (e.g., PowerPoint slide collaboration), as they are responsible for the product and take complete control at this point.

The joint analysis community is comprised of the analysis organizations in the Unified and Specified Commands and the Joint Staff. Each of these organizations is responsible for performing analysis studies to support its commander. In the past, these organizations had two basic options for improving necessary analytical capability and capacity: develop sufficient in-house capability and capacity for anticipated analytical tasks or support extensive travel to and from external sites with the necessary analytical capability or capacity. Travel was required to support collaboration, because no communications medium could support all of the various types of interactions required to define problems, develop data, perform analyses, and report results. Naturally, each organization created its own balance between the options in acquiring the required support. However, even with a good balance, the cost of analysis was a constraint on the use of analysis; moreover, periodic situations of over- and under-capacity were the unavoidable result of uneven demands for analysis.

New technologies, characterized by the Internet, cheap massive computing, and multi-media computing, are creating the opportunity for a third option. The third option is electronic collaboration. The increasing availability of high-bandwidth communications and human-oriented user interfaces support the required analysis interactions by using information technology (IT). With advances in IT, sharing analysis resources, reducing costs, and reducing capacity and capability imbalances is possible.

This new capability affords a benefit beyond the obvious cost benefits. Analysts from multiple organizations can collaborate on projects that in the past would have been performed in isolation. Because participation will not be restricted to Department of Defense (DOD) organizations, at its fullest extent, all federal organizations could be permitted access, along with selected non-federal and even non-U.S. organizations. Collaboration will significantly improve the quality of the analysis at all locations. Because the analysis center will be virtual (not be situated at any one physical location) the concept has been named the Joint Virtual Analytic Center or JVAC.


JVAC Project: The Joint Staff/J-8 organization, particularly the Joint Analysis Operations Program (JAOP), is responsible for improving support to the joint analysis community. J-8 determined that an organized effort was required to create technological support to collaborative analysis. As a result, J-8 instituted the JVAC Project. J-8 subsequently requested the support of the Department of Energy (DOE) in Oak Ridge to perform initial design and implementation, followed by a process of evolutionary change and improvement, at the government owned facilities in Oak Ridge. The project began in March 2000.


JVAC Vision: The JVAC will be a worldwide, virtual, collaborative computing and communications environment that enables the joint analysis community to support decision-makers and staff effectively in near-real-time from dispersed locations.

The word "virtual" is used here as short-hand for processes or technologies that reduce the impact of space and time differences among collaborators. Thus, if a collaboration tool permits a geographically dispersed group to collaborate almost as if they were collocated, the term "virtual" would be applied (e.g., a virtual meeting). (The tool need not be "high tech," e.g., for a particular purpose a conference call on the telephone might be sufficient.) In addition, if a system allows a person to operate a simulation running on a geographically distant computer, that system might be termed "virtual." In the case of the JVAC, both instances (group collaboration and application sharing) will apply. In addition, the adjective "virtual" applies to the word "center." In these important respects, the JVAC will not have a physical "center," rather it will appear to be centered at each user's location.


JVAC Concept of Operations:

The JVAC is organized to support the analysis process shown in Figure 2: several individual users "sit around a virtual table" and have the functionality of their individual workstations augmented by the common functionality of the JVAC. Figure 3 illustrates the JVAC knowledge management system. (Knowledge management is the purposeful and systematic collecting, processing, organizing, analyzing, synthesizing, retrieving, and sharing of data, information, and knowledge among knowledge workers, decision makers, and organizations.)

Figure 3

The diagram emphasizes that each analyst will create work products in the collaborative workspaces and will have his own local repository of data (on each system, classified and unclassified, as current technology and procedures require separate systems for unclassified and classified data) to address "need to know" and copyright based usage and dissemination restrictions. We expect the analysts will transfer valuable material from the unclassified system to the classified system and will preferentially work on the classified system. In using local repositories, each analyst will be able to legally correlate his personal archive of data, e-mails, etc., with JVAC Knowledge Repository data. This architectural approach means each analyst's PC must be adequately configured to meet the performance demands of his autonomous search tools, the storage requirements of large volumes of Local Repository data, and the needs of data mining tools. However, from examining the various search and analysis tools, it is clear that the most powerful (and potentially most useful) tools will require more effort in mastering and using the tools than most analysts can afford. These tools belong in the PACOM Virtual Information Center (VIC) or in VICs created by other commands. The VIC has the time and the mandate to spend the effort to gather information and collect it into usable products. All of these resources support the analyst in producing work products.

The dashed arrow leading from the "work products and info nuggets" to the "JVAC Knowledge Repository" indicates that conscious user action is required to move any information produced as work products or gleaned by data mining (from the Local Repository, connected External Data Sources, the VIC products, or the JVAC Knowledge Repository) into the JVAC Knowledge Repository. This recycling can serve to enhance all analysts' searching activities and optionally automatically profile their interests. The timeliness and the degree to which this recycling of prior finds can occur will depend upon the operational security and copyright issues that JVAC analysts must consider before posting the information into the shared repository. The JVAC Knowledge Repository will minimally support the placement of a resource reference with an associated abstract in order to convey to other analysts any new find's availability to other JVAC analysts without violating "need to know" and/or copyright restrictions preventing the placement of the actual information.

Eventually, to support this architecture, autonomous knowledge portal software and/or some form of document management centric server software will be required to populate, manage, and search the JVAC Knowledge Repository. However, we will start with a more rudimentary "abstract and file" system.


Features vs Products:

Numerous products supply features JVAC requires; however, no product supplies them all (with full functionality). In the table below, IWS refers to InfoWorkSpace and KM Portal refers to a generic Knowledge Management portal.

  IWS Net-Meeting Same-Time QuickPlace Cold-Fusion KM Portal S-Q-C Combo I-Q-C Combo
Synchronous Communication                
Text Chat F   F L     F F
Whiteboard F F F       F F
Application Sharing F F F       F F
Private, persistent workspace F     F P   F F
Document Sharing F F   F P   F F
Audio F F           F
Video L F           L
Asynchronous Communication                
Calendar L     L P   LP L
User-Modifiable Pages       F P A F F
Threaded Discussions F   F F P A F F
External Resource Links       F P A F F
E-mail F     L P   LP F
Information Management                
Simple Search Capability F     L P F LP F
Complex Search Tools         P A P  
Data Analysis         P A P  
Database Support       P(L) P F P  
Document Management       L P F LP F
User-Customizable Interface         P A P  
Multiple File Format Support     L L P F LP L

F = Full capability, L = Limited capability, A = Assumed capability, P = Programmable capability,

S-Q-C = Sametime + QuickPlace + ColdFusion, I-Q-C = IWS + QuickPlace + ColdFusion.

 

Figure 4 illustrates some of the functions of a whiteboard.

Figure 4

 

Figure 5 illustrates the concept of a persistent, private, virtual workspace. Persistent means that what ever is left in the workspace will be there when the participants return, whether in a few minutes or after several months. Private means that only designated participants may enter the workspace. Virtual means that the workspace is available at each participant's workstation, where ever he or she may be in the physical world.

Figure 5

 


Problems: Despite (or because of) technical advances, the technologies required to implement the JVAC are not without problems. An example is shown in Figure 6. The full functionality of JVAC requires the use of multiple internet "ports" and the use of "active code." Firewalls and proxy servers can be (and are) configured to prevent the use of these ports and this type code. Each organization controls its own firewalls and proxy servers (or has a separate organization to do so). Thus, negotiations are required at each barrier to permit the JVAC to work as planned.

Figure 6


Conclusion: The early version of the JVAC is up and running. It does not have all the desired functionality, yet; however, that is coming.


If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.

Return to Hartley's Projects Page