A Case Study in Technology Transfer of Collaboration Tools
John Davidson, Lucy Deus
The experience of transferring the technology of Collaborative Virtual
Workspace spawned a number of new requirements for linking new elements
within the organization and other agencies. The community of interest
supported in the crisis exercise now has no fewer than eight separate
agencies, CINCs, or commands linked to their virtual environment worldwide.
The senior analyst for the crisis group became a major spokesman for
a new way of conducting crisis operations and has helped raise the visibility
of collaboration technology across the entire intelligence community.
The movement into the virtual world has not been easy, nor is the transition
complete. In the process to date, however, many cultural norms, policies
and infrastructures have been challenged. These challenges are discussed
in the next section.
Cultural Issues - Collaboration is not a Bad Word
The pilot organization has encountered numerous cultural barriers to
conducting operations in a virtual setting, from having to define new
ways of assigning credit for reports, to finding ways to keep middle
level managers involved, to overcoming a historical predisposition to
protect information rather than sharing it.
The analysts have always strained against the restrictions to gather
information from whatever source possible, including their counterparts
at other agencies. The provision of an online conferencing and document
exchange tool has raised the possibility of sharing selected information,
interim analytic results, working aids, and final product among the
staff across agency boundaries. This is revolutionary and has opened
many new questions, including:
- When multiple internal elements coordinate on a product, who "owns"
the final report?
- Likewise, when multiple agencies are involved, who owns the material
produced collaboratively?
- What happens to the existing hard copy-oriented workflow model for
analysis when everything is now exchanged online? Where is the accountability?
Where is the log?
- What does it mean to work virtually? How will I know when I've completed
an action?
- What role does mid-level management have in the process now? Is
there a role?
- What's to keep my analysts from "giving away the farm"
to some other analytic team?
- How will I control my people?
- How do I find someone to help with a problem? How can I find an
expert in X? How can I advertise my expertise in Y?
- I have a team of introverts. How can I ease them into working as
a team with others? While some questions have been answered as a result
of the collaboration pilot experience, other questions are unanswerable.
In many cases, the old business processes cannot be re-mapped into
a virtual world, and should not. Some tasks will no longer be needed
as their function is taken over by an online system. Some mid-level
managers are real barriers to productivity, and virtual teaming only
highlights this fact in high contrast.
Challenges to Technology Transfer
When the pilot community began its journey, it was already clear that
there were many technical issues to address in making collaboration
technologies fit into the computing and networking infrastructure. What
was not clear, however, was the extent to which these and other issues
would require the organization to undergo a cultural shift. The technical
issues encountered centered on the desktop environment and the network
substrate.
Desktop Computing
The organization has standardized its desktop on UNIX, but has many
flavors of UNIX (SunOS, Solaris, SGI, AIX) in place across its elements.
In addition, there is a growing contingent of Windows NT workstations
as offices begin evaluating the potential of migrating toward NT. As
the organization progresses forward to an enterprise collaboration infrastructure,
it will do so with the requirement for multiplatform support.
Audio Conferencing
None of the analysts' systems had microphones because they were removed
from the desktops in order to comply with an unwritten and undocumented
security policy against the use of microphones in operational spaces.
It took several weeks to dispel this myth, find the microphone caches
and redistribute the microphones back to the users. The policy had at
its origin a fear that the microphones could be remotely enabled across
the network to eavesdrop on operational spaces. There is some truth
in the observation that under UNIX devices can be remotely enabled,
but root access to the desktop involved would be required. The use of
microphones was approved for the analysts.
Networks
Because of the mature computing environment at this organization, there
also exists an equally mature and comprehensive campus-wide network
infrastructure that provides at a minimum, a 10 Mbps Ethernet to every
desktop. In addition, there are many high-speed connections to affiliates
located across the country and the world. Without these investments,
the organization could not have attempted to use collaboration technology
in any meaningful way. As the organization upgrades their local area
networks (LANs) to fiber, and then to asynchronous transfer mode, bandwidth
concerns with collaboration technology will become less of an issue.
Bandwidth
One of the fears network administrators faced when introducing collaborative
virtual workspace (CVW) into a new LAN was that the collaboration and
conferencing tools would bring the LAN to its knees because of increased
load. This fear was addressed by examining the sources of network loading.
Since the decision was made to disable video conferencing, only three
sources of bandwidth use needed to be addressed: audio, chat, and document
exchange.
The organization has institutionally limited the installed audio conferencing
tools to use the GSM (Global System for Mobile Communications) encoding
scheme, which requires 17 kbps during transmission. In addition, all
users are trained to use the "push-to-talk" mode in the audio
tool, so that network bandwidth is utilized only when the analyst intends
to speak to others. The pilot experience showed approximately 10 percent
of the on-line users had their audio tool enabled in an active conference.
Most LANs were able to absorb this kind of traffic without noticing
its presence.
The text chat tool generates much less traffic, measured in tens of
bits per second.
The document exchange interaction generates more traffic, but it is
in bursts, as users import or open documents to/from the document server.
This traffic can be compared to the use of a Web browser, as it is based
on the same HTTP protocol. In the pilot organization, the files used
by analysts within CVW are usually small documents, not large binary
files. There are exceptions, but most are text notes, smaller image
files or desktop publishing files.
Early on, the network administrators set up several LANs and ran network
loading tests with and without CVW for one week. The results showed
minimal increases in network loading because users are mostly single-threaded,
performing one network operation at a time. While they are collaborating
with others, they are not actively downloading Web pages, reading email,
chatting over IRC, or using other network services.
Managing Multicast
The organization has a wide range of router hardware in place. Some
of the routers were installed well before IP (Internet Protocol) Multicast
was defined as an IETF (Internet Engineering Task Force) standard, and
others have varied levels of support for IP Multicast. In all cases,
none of the hardware routers were enabled to route IP Multicast.
A virtual Multicast network (MBONE) was constructed and managed for
the CVW participants. Initially, multicast connections (tunnels) were
established by linking offices that needed to talk with each other.
Later, concerns arose that constructing an MBONE based on community
membership was inherently inefficient, and a physical network survey
was conducted to ensure that the virtual multicast network was not violating
any obvious limitations in the physical network topology. Several instances
of "doubling back" on connections in the MBONE were discovered
and corrected. Understanding the network topology and its usage is critical
to building an efficient and stable MBONE.
Challenges to Collaboration and Security
There were three main security concerns with CVW use in operations:
audio security, classification marking of rooms and document security.
The concerns arise from limitations of the current technology, and should
be treated as requirements for a collaboration infrastructure, based
on CVW usage experience.
Segmenting Multicast Addresses Used by CVW Buildings
The security administrators wanted to ensure that staff working in one
CVW building did not hear audio from another CVW building. To address
this concern, a study of IP Multicast segregation techniques was conducted,
and multicast boundaries were implemented to segment CVW communities
of interest (COIs) by multicast prefix. This means that for Target Community
A, the multicast packets would be prefixed with a unique address group
and access code for each community so no one has to resort to snooping
the packets. The main concern was privacy, not security per se, since
the participants were running on a secure network. With the rapid expansion
of CVW virtual buildings within the organization, there are now 10 separate
multicast group segments all riding over the same MBONE.
Audio Conferencing "Lurker" Issues
Because the IP Multicast protocol is a broadcast protocol, it sends
data across the Multicast network, potentially into LANs where there
are no active subscribers. It is possible to intercept the signals and
"lurk" in an audio conference if one knows the multicast address
of the conference. Obtaining this address without approval would require
illicit means. The organization approved the use of multicast within
its internal network, because the audio conferencing tool provided no
unique opportunity for "lurkers" that was not already present
in the agency's e-mail, FTP, Web, or any other network service. However,
the use of multicast-based conferencing with other networks (e.g., through
the firewall) remains a security issue until security safeguards become
available.
Observing Classification Levels in a Virtual Environment
The concern of how to handle classification levels in a virtual environment
is a valid concern that has not yet been adequately addressed. In CVW,
the room-locking capabilities have been employed to restrict access
to rooms and floors based on a "need-to-know" criterion. Security
administrators would like to see a clear statement of the virtual room's
classification level to advise the participants in the conference as
to the highest level of classification the room can support.
There are two requirements implied. The collaboration environment should
be able to access and act upon the clearance information of the users.
In addition, virtual rooms need to be dynamically marked with the aggregate
classification level of all the participants (or documents) present
in the room, as it changes, to keep the user informed of the active
security level. Policies and models need to be identified for the use
of security classification levels in virtual environments.
Document Security
In the present CVW, access to the persistent documents is controlled
by access to the rooms that house the documents. This model did not
satisfactorily support the requirements of the analysts.
The security staff have identified a requirement for a model that reflects
a document-level access control that is more consistent with the current
physical control policy. In addition, the network is permitted a specific
classification level. There are many instances where analysts wish to
share material at higher classification levels among themselves. The
security policy requires that they encrypt such material in storage,
pass it encrypted (via FTP, Email, or Web), and then decrypt only at
the workstation.
Technology Transfer Strategies Learned
The following strategies were identified by the Department of Defense
as having been learned through the bittersweet experience of deploying
and supporting collaboration technologies in their operational settings:
- The white knight
Find a white knight who can be the proponent - your voice doesn't
count. This is not a technical argument. The analysts/users are supreme:
In the end, their job has to get done. The white knight has to repeatedly
stress the potential or actual operational benefits.
- Technology is not the driver
If the users do not have a business reason to participate, you cannot
force it with technology.
- Technology is a moving train
With enough time, you can always find a better technical solution.
Use the 80 percent solution rule and get some results now. Migrate
later.
- The Boy Scout rule
Be prepared for the technical, policy and cultural challenges. Do
your homework and be ready to answer almost any question. This is
largely an educational process. You are the expert.
- Take no prisoners
Don't sweat it if some don't get it. Work with those who do. Bypass
the dead weight. There will be obstacles, most of them human. Avoid
confrontation, but if forced, take no prisoners.
- Corollary to the take-no-prisoner rule
Develop a source for your "Get out of jail free" cards.
You will need them.
- Share ownership of the effort
Involve support teams early and often. You shouldn't do all the work
or take all the glory. If they benefit as a result of the pilot's
operational utility, so do you. If you do it all, they won't own it
later when you want to move on.
- Failing isn't an option
When it works, everyone wins. If an element is not winning, find an
angle to help it win.
Conclusion
The last two years have been a wild ride as this organization encouraged,
facilitated, cajoled, embarrassed and used any other means within their
reach to implement an 80 percent collaborative technology solution.
We have learned that technology transfer is not largely a technical
activity, but rather a human or organizational one. Without a doubt,
technology must support the mission and be shown to be efficient, state-of-the-art,
and capable. But, technology transfer, in the long run, depends on persistence.
In many cases, resistance to change has to be simply outlived and worn
down.
The collaboration pilot experience in this organization is moving in
a new direction as the agency helps to sponsor the migration of the
collaboration technology into a true enterprise model. Such an Enterprise
Collaboration Architecture will support federations of collaboration
contexts, universal authentication services, defensible and supportable
security services, alternative document and data services, activity
logging services, and a host of other enterprise services that will
integrate collaboration technology as part of the agency's baseline
set of information services.
As they move toward that enterprise model, the technology-centric issues
will become more important and central to the process. But the hardest
challenge has been establishing an operational business case and applying
existing technology.
For more information, please contact John Davidson
using the employee directory.
