Distributed Collaborative Environments for
Decision Support

by William K. McQuay
Technical Advisor, Information Directorate,
Air Force Research Laboratory

1. INTRODUCTION

As downsizing trends continue in both government and industry, organizations increasingly require more efficient, effective collaboration and knowledge sharing for geographically dispersed personnel across multiple application domains in order to solve complex problems and accomplish difficult tasks. Often past research has treated knowledge sharing as purely an information technology problem and has ignored an organization’s cultural foundations and related process changes needed for successful collaboration. This paper reviews the application of distributed collaborative environments to information and knowledge sharing for Air Force acquisition and technology development. This research is a significant benchmark in the evolution of collaboration in that information technology, process change, and the sociology of human interaction are woven into a fabric of knowledge sharing - the knowledge focused organization.

2. INFORMATION VERSUS KNOWLEDGE

During the past 50 years, information-centric applications have followed an evolutionary path focused first on data processing, then information management, and now on knowledge. It is conventional wisdom that we have evolved from the Industrial Age into the Services Age, and that two-thirds of all Americans are now working in what is labeled “the service sector.” In turn, this service-based society is becoming a knowledge-based society, where more and more of the people are working in the knowledge related industries that process information.

In everyday conversation, we casually use the terms information, knowledge, and understanding. How does information differ from knowledge? The confusion between knowledge and information has caused managers to sink billions of dollars in information technology ventures that have yielded limited results [1]. European knowledge-focused research emphasizes the human aspects, rather than pure information technology and notes that “managers must realize that, unlike information, knowledge is embedded in people, and knowledge creation occurs in a process of social interaction” [2]. One of the leading modern day information system philosophers, C. West Churchman, in 1971 wrote that knowledge resides in an individual person and not in a collection of information [3]. Recent research in Japan and Sweden comes to the same conclusion [2,4]. In our everyday life, we learn and gain new knowledge through communication, personal interactions and frequently “bouncing ideas” off other people. Unlike conventional tangible assets, knowledge will grow when it is shared [2]. Thus, one can conclude that knowledge sharing is inherently a social, collaborative activity and can be cultivated within an organization.

To clarify our discussions, we need some basic working definitions. We define data as raw facts; information as data in a context relevant to an individual, team or organization; and knowledge as an individual’s utilization of information and data complemented by his or her unarticulated expertise, skills, competencies, ideas, intuitions, experience and motivations. A key implication in the above definition is that knowledge is created only by individuals and is specific to the individual who created it. An organization cannot create knowledge by itself but can support creative individuals or provide the environments for them to create and share knowledge. Knowledge is often divided into two categories: explicit and tacit [4]. Explicit knowledge can be expressed in words or numbers, and shared in forms such as data, technical drawings, equations, specifications, documents, and reports. Explicit knowledge can be readily transmitted among individuals and formally recorded. Tacit knowledge, on the other hand, is highly personal, hard to formalize, and difficult to communicate or share with others. Tacit knowledge has two dimensions: technical (skills or crafts such as that represented in the knowhow of the master craftsman), and cognitive (know why, perceptions, values, beliefs, and mental models) [4].

Of all the knowledge that people possess, the knowledge that the organization should care about is the knowledge that people need to do their work. Most knowledge remains in people’s heads and never gets formalized, documented, and shared [1]. The organization can enable knowledge sharing through an infrastructure which we will call a distributed collaborative environment (DCE). Information technology tools for document management and enterprise portals can archive explicit knowledge, which is classical information often in the form of documents. But the tacit knowledge is much more difficult to address. Collaborative communications (chat, instant messaging, desktop conferencing, forums, threaded discussion groups) can provide a partial impetus for cultural changes to enable the flow of tacit knowledge among an organization’s personnel, and it is critical for management to encourage such interchange as part of the workforce culture at all levels. The ultimate goal of which we must formalize and share is process models and complement them with the mental models everyone has as part of their tacit knowledge base. A key aspect of our U.S. Air Force Research Laboratory (AFRL) research in distributed collaborative environments has been the creation of product and process models (in an electronic format) based on the tacit knowledge of our senior engineers and scientists. Thus the DCE is not just tools but explicit knowledge in the form of data and information bases, the enabling of tacit knowledge description through product and process models, accessibility of on-line engineering and domain specific tools, and the most important resource --our people - dynamically interacting with each other and the collaboration environment. This concept is graphically depicted in Figure 1.
Figure 1. AFRL Distributed Collaborative Environment

3. LEVELS OF COLLABORATION

Collaboration means different things to different people. Our working definition of collaboration is two or more geographically dispersed individuals working together to share and exchange data, information, knowledge, and actions. In the laboratory, the product of the collaboration is defined broadly, for example, to include writing a report, creating software, or designing hardware. Collaborative environments provide the framework and integrate models, simulations, engineering tools, and other domain specific tools to facilitate knowledge sharing and collaboration between the multiple disciplines needed in the organization.

The full spectrum of collaboration and the close relationship of collaboration and interoperability at the technical level is demonstrated in the Command. Control, Communications, Computer (C4) Intelligence Surveillance Reconnaissance (ISR) Architecture Working Group's Levels of Information System Interoperability (LISI) Maturity Model, as depicted in Figure 2 [5]. LISI considers five increasing levels of sophistication regarding interaction and the ability of the system to exchange and share information and services. Each higher level represents a demonstrable increase in capabilities over the previous level of system-to-system interaction. Level 0 is an isolated standalone system with manual data exchange via tape or diskette. Level 1 is peer-to-peer electronic exchange as in email with homogeneous but separate data and applications. Level 2 includes basic group collaboration across programs with heterogeneous product exchange and some fused information. Level 3 is sophisticated collaboration with shared data for a domain, business rules and processes, and fused information products. Level 4 is advanced collaboration with distributed information across multiple domains, simultaneous interactions, and shared data and applications. The conventional use of the word “collaboration” is level 1 under the LISI categorization. What we see is the potential for multiple levels of collaboration in an organization. The AFRL DCE encompasses all of these levels to enable collaboration throughout the enterprise.

Figure 2. Levels of Collaboration

4. DEFINING A DISTRIBUTED COLLABORATIVE ENVIRONMENT

A distributed collaborative environment (DCE) is a collaboration framework instantiated with domain specific resources to support a context-specific collaboration. A collaboration framework, in turn, is an open standards agent-based infrastructure of communications, data processing, decision support, knowledge processing and resource management services which can be configured to support a collaboration. The DCE interconnects the participants (decision-makers, scientists, engineers, etc.), computational resources, and persistent databases for the purpose of developing a product or other action related to decision support in the organization. A DCE enables geographically, temporally, and disciplinarily distinct resources and users to seamlessly interoperate, gracefully enter and exit the collaboration, and archive and recall work products over the course of the life-cycle [6]. A DCE supports both single individuals and collaborating groups by managing and distributing “virtual workspaces” [7]. These virtual workspaces contain the necessary visualization and resource management tools each user needs to contribute to decisions throughout the life cycle. The collaboration can be active for days, months, or years. Users may be active (not necessarily on-line) for minutes, hours, days, or years, depending on their utility to and interest in the on-going collaboration.

A distributed collaborative environment (DCE) applies state-of-the-art information, visualization, process and workflow management, communications, modeling, and simulation technologies to provide a common framework within which the organization and its partners can collaborate across the life cycle. A DCE implements functions such as the following, permitting collaboration members to:

  • Access electronic versions of explicit knowledge usually in the form of documents such as test plans, test reports, proposals, reviews, calendars, specifications, requirements, test schedules, meeting minutes, action items, computer aided design (CAD) drawings, visualizations, databases, technical reports, and briefings
  • Maintain documentation and software under configuration control with traceability and archiving of changes and automatic notification of updates and newly created action items
  • View, discuss and generate documents with each other using desktop video and audio conferencing Present data and information to various users in domain-specific and content-specific formats applicable to each user's current needs
  • Identify, release, and check out documents, computer software, or information
  • Translate and mediate data between heterogeneous processing systems and diverse functional user domains
  • Remotely control and share the use of applicable tools and resources
  • Monitor the progress of tasking and alert managers and engineers to assess the impacts of variances in tasking and changes in plans, schedules, and configurations
  • Remotely activate applications, such as simulation models or remote compiling and patching of software and data extraction

In the next 10 years, clusters of geographically separated resources will be integrated by advanced communications networks into distributed collaborative environments. Users will search repositories for the resources needed to solve their particular application, will assemble and configure the resources into a virtual decision support system and will execute or use the virtual system to solve their problem or accomplish their task. Additionally, products resulting from one task will seamlessly interact with the products of other tasks to accomplish unique functions. The DCE will emphasize product and process models which capture and provide information and explicit and tacit knowledge about the organization’s development process. A product is broadly defined to include writing a report, creating software, designing hardware, or developing an alternative course of action for a senior decision maker.

Product models provide details about the specifications and requirements of a product, its structure and behavioral characteristics, its design and development constraint rules, and the different versions of the design and implementation. In this context, a product can be a prototype piece of hardware, a report, or an experiment/session. Product models also define any special test equipment or facilities required to support design and/or development.

While product models focus on all aspects of the product design and development, process models provide detailed definitions of the engineering, development and evaluation processes used to design and develop the product. Specifically, process models provide information and knowledge on how to use various tools and resources to perform the numerous scientific, engineering, development and evaluation tasks associated with technology and product development. A collaboration workflow visually instantiates the process model.

Often in a collaboration, a team is made up of many participants with different backgrounds, experiences, and specialties. They literally do not speak the same language. The DCE must provide a domain-specific view in the native terminology of each of the team participants. There will be multiple user interfaces as shown in Figure 3. For example, the engineers on the team must be able to employ the applications that they customarily use. The engineering user interface must be intuitive for the engineering domain. Similarly, the manufacturing, financial, logistics, management, and end user must be able to access the information, databases, and other resources in a fashion natural to their way of doing business.

5. COLLABORATION TECHNICAL REFERENCE MODEL

The AFRL DCE architecture is built upon a seven layer technical reference model as depicted in Figure 3 [8]. The layers are applications/resources, application/resource interfaces, common collaboration services, domain specific collaboration services, communication services, system support services, and the physical network.
Figure 3. Collaboration Technical Reference Model

Applications/Resources
Applications/resources are the objects needed by a user to perform a task. These applications/resources can include engineering models, simulations, commercial administrative and business software tools, hardware simulators, cost models, affordability and cost of function tools, and other laboratory or test facilities. These applications/resources can also include collaborative communication resources, such as distributed white boards, video teleconferencing systems, multi-user virtual environments, or corporate e-mail needed by users to collaborate with other users. Finally, and most importantly, human beings are also very valuable resources within a collaborative environment.

Applications/Resources Interfaces
Application/resource interfaces provide two basic functions: they accept input data from a user and process it for presentation to another entity within the collaboration, and they accept data from some other source in the collaboration and process it for presentation as output data to a user. Note that the term user can refer to a human or an inanimate resource such as an intelligent agent. The basic interface categories are:

  • Human Interfaces: GUI, touch screen, mouse
  • Data Based Interfaces: Interfaces to OODBMS, RDBMS, SQL
  • Hardware Interfaces: Computer, test equipment, facilities
  • Model Based Interfaces: Real-time & non real-time existing and next generation M&S
  • Software Interfaces: COTS packages and tools across multiple disciplines

Common Collaboration Services
Common Collaboration Services are the core services that make up the application independent agent-based framework. Significant in this area is the use of intelligent agent technology which can capture both explicit and tacit knowledge to support the organization to configure resources, assemble resources into executable processes, create and manage collaboration work flows, support the discovery of resources applicable to a defined collaboration, support session and experiment planning, control and manage the display of information, and manage the shared information among participants. Collaboration service categories include:

  • Collaborative Communications: Chat rooms, discussion groups, shared whiteboards, shared applications
  • Security Services: Individual access control and data/information security
  • Workflow - Implementation of process models for producing a product
  • Data Management -- Data mediation, access, archiving, routing
  • Product Models
  • Process Models
  • Smart Enterprise Common Object Model (SECOM): Runtime implementation of the enterprise product model and shared information for the collaboration
  • Collaboration Agents: Intelligent agents to coordinate user interaction, manage specific resources, data mediation and translation, and control workflow
  • User Interaction/Control: User interfaces configuration and window management

Domain Specific Collaboration Services
Domain Specific Collaboration Services provide services that are needed to support a specific customer base or domain. These services are commonly needed throughout that domain and require exceptions, extensions, or special considerations from core services, such as real-time services, view generation, and audio system interfaces.

Communication Services
Communication Services provide for the functional interoperability and interconnectivity management of physically distributed enterprises. The communication service categories include:

  • Filter Management: Management of out-bound messaging and data filtering
  • Bandwidth Management: Management of network bandwidth requirements
  • Object Management: Management of object attributes, name space, persistent storage, and object backup
  • Protocols: Such as Hypertext Markup Language (HTML), Hypertext Transport Protocol (HTTP), eXtensable Markup Language (XML), Java 2 Enterprise Edition Services (Java 2EE), and the Distributed Component Object Model (DCOM), etc.

System Support Services
System support services are the low level processing services required to run any application on a computer, whether it is domain specific, middleware, or communication services. These services include such items as operating systems, memory managers, data buses, and system clocks.

Physical Network
The previous layers rest upon a physical network that provides basic connectivity. The network could be the Internet, dedicated communications lines such as T-1, or a corporate intranet.

Since the Air Force desires to leverage commercial information technology, our Technical Reference Model also allows us to assess the commercial sector and identify technology gaps in the commercial sector and the areas needed for AFRL investment.

6. CONCLUSIONS

AFRL DCE experiments have demonstrated the maturity of the framework and infrastructure necessary to integrate geographically distributed resources into a working collaboration. Based on the experiments we have observed the following: collaboration within multiple levels of a laboratory are achievable, a DCE can reduce time to conduct design and analysis, resources and experts can operate in native environments, and management can gain increased insight into the engineering process. As a result, DCEs will be applied to several future major analyses. One significant use is for AFRL technology planning, integration, and coordination. The initial technology study will investigate strike operations against time critical targets in a 2010 timeframe. The scenario will show the campaign-level payoff of technologies associated with an uninhabited aeronautical vehicle (UAV) designed to locate critical mobile targets. The UAV is ideally suited for this initial activity since it cuts across many technology directorates.

With such experiments, DCE technology allows the laboratory to formalize current organizational processes, build upon “best practices” and extend them when appropriate into new areas. Both explicit and tacit knowledge are employed and in some cases tacit knowledge converted into explicit organizational knowledge. DCE allows the laboratory’s most important resource - people - to be in the loop to bring the wealth of their experience and insight to bear on activities for decision support.

Advances in software and computer technology are making distributed collaborative environments possible and affordable for the engineering process in government and industry research. DCE is becoming a crucial means of information and knowledge sharing and systems integration for research and development. The initial research in DCE has successfully demonstrated multi-directorate collaboration and information sharing ability. A key area of research is focusing on the open standards agent-based framework, product and process modeling, and structural architecture needed for collaboration. The use of product and process models and use of intelligent agent technology to describe explicit and tacit knowledge and to be able to dynamically act upon that knowledge is a significant milestone. AFRL is continuing the evolutionary development of DCE technologies and their employment to create a laboratory fabric of knowledge sharing - the knowledge focused organization.


REFERENCES

[1] Conference Board, “Beyond Knowledge Management: New Ways to Work and Learn”, Research Report 1262-00-RR, 2000.
[2] Karl Erik Sveiby, The New Organizational Wealth: Managing and Measuring Knowledge-Based Assets, San Francisco: Berrett-Koehler, 1997.
[3] C. West Churchman, The Design of Inquiring Systems, Basic Concepts of Systems and Organizations, New York: Basic Books, 1971.
[4] Ikujiro Nonaka and Hirotaka Takeuchi, The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation, New York: Oxford University Press, 1995.
[5] Department of Defense, Command Control Communications Computer Intelligence Surveillance Reconnaissance Architecture Working Group, Levels of Information System Interoperability (LISI), 30 March 1998.
[6] William K. McQuay, “Put a Virtual Prototype on Your Desktop,” Program Manager Magazine, 94-99, September-October 1997.
[7] Vance M. Saunders, and William K. McQuay, “Collaborative Virtual Prototyping,” 1997 Joint Avionics Weapon Software Support and Simulation Conference Proceedings, June 1997.
[8] AFRL/IFSD, “Collaborative Technology Development in the Air Force Research Laboratory, Requirements for an Air Force Collaborative Enterprise Environment,” January 2000.
[9] Ty Hayden, “A Collaborative Enterprise Environment Experiment Using Simulation Based Acquisition Technologies,” Simulation Interoperability Workshop, Simulation Interoperability Standards Organization, Spring 1999.

About the Author

If you have any comments or observations, you can contact William McQuay at william.mcquay@wpafb.af.mil, (937) 904-9214, AFRL/IFSD, 2241 Avionics Circle, Wright-Patterson AFB, OH 45433. William K. McQuay is Technical Advisor, Collaborative Simulation Technology and Applications Branch, Information Systems Division, Information Directorate, Air Force Research Laboratory. He directs the Electronic Concepts Simulation Research Laboratory (ECSRL) and has 31 years experience in research for advanced simulation technology and the development and utilization of digital simulation models for the Air Force development, acquisition, and test and evaluation process. Current research initiatives include distributed collaborative environment technology for the simulation-aided acquisition and test process, distributed mission training, and distributed command and control. He received a BS in Mathematics from Towson University, a Master of Applied Science in Operations Research from Southern Methodist University and Master of Science in Engineering in Computer Science from Johns Hopkins University.


Citation

McQuay, W. K., "Distributed Collaborative Environments for Decision Support", DSSResources.COM, 08/28/2003.


The Air Force Research Lab Information Directorate provided permission to archive this article and feature it at DSSResources.COM. This article was posted at DSSResources.COM on August 28, 2003.