OBJS is currently performing a DARPA contract: Scaling Object Services Architectures to the Internet. This 3-year contract is intended to develop technology to insure that Object Services Architectures (OSAs) like that of the Object Management Group (OMG) are scalable and can interoperate with Internet technologies and tools like the World Wide Web. The specific project we are pursuing under this contract, Accessing the Global Information Base, is a focused way to demonstrating composition and federation of Internet services including an open query service and annotation service. The Application Scenarios task of this project is developing descriptions of scenarios that illustrate the use of OSA Scaling techniques and our global information base technology, and tie OBJS work to DOD operational needs. These scenarios will be the basis of actual technology demonstrations.
As part of this contract, we are developing a sequence of four scenarios of increasing complexity. The first three scenarios apply basic and advanced commercial-off-the-shelf (COTS) technology, plus additional technology we are developing, to the virtual office, using our own virtual office as a usability test case. The final scenario applies this technology to a DoD target application.
This report describes Scenario #1, Initial Use of COTS Tools in the OBJS Virtual Office. The intent of this scenario is to illustrate the construction of a working Virtual Office (VO), using a combination of straightforward operational techniques, and readily available COTS personal computer and Internet hardware and software technology. The scenario is somewhat conventional, but is intended to illustrate how to support both research and development activities and office administrative functions in a VO, based on the experience we have gained in setting up and using the OBJS VO.
This report also discusses some lessons we have learned from our initial VO experience, as well as some additional technologies that we feel would be helpful in our VO environment. Subsequent scenarios will involve both more refined uses of COTS technology based on our experience, and the use of new technology we develop, in both internal and DoD-related applications.
Much of our experience both with VO technology in general, and our own VO in particular, has already been documented in reports that are part of our Internet Tools Survey, specifically:
In addition, we have been active architects of the enterprise architecture developed by the National Industrial Information Infrastructure Consortium (NIIIP), which is focused on developing technologies that make it easier to set up and operate a virtual enterprise. See OBJS Participation in NIIIP Consortium.
For the most part, these activities (with some variation) are typical of those that must be performed by any group involved in detailed collaborative work, technical or non-technical. Particularly in our field (computer software research and development), many of these activities would ordinarily be performed using computers and the Internet, even in a conventional office setting. Hence, many of the activities and technologies described here will be familiar to people who use computers a great deal in their work, or at home. However, in a complete VO, additional considerations often arise that require modifications to existing practices, or the development of entirely new practices. Moreover, VOs are more often talked about than actually seen in practice. As a result, we hope that the description of how these activities are actually performed, and technologies actually used, in the context of an operational VO will provide added insight into the promise of this form of organization.
There are also additional home office facilities which, while not required in all cases, are in many cases either necessary or at least desirable. These include:
In addition to these individual facilities, some form of shared information space (e.g., a file server or Web server) is very helpful. In OBJS, one employee maintains an internal company-wide Web server. This server supports an internal corporate Web and file space, accessible via https (Netscape's secure http mechanism), with authentication by passwords and electronic certificates. This shared internal space allows employees to share information (e.g., trip reports, current task status, interim documents) in a way that is more convenient for many purposes than simply "broadcasting" the same material to all employees in email messages. For example, it reduces the amount of email traffic (and delays in downloading large attachments), allows employees to access information only when they need it, and provides a central organization for the material. Sharing information in this way is also more secure, since movement of documents via https is encrypted. The documents in this internal space are indexed, and a search engine is available for querying the documents. Restricted access to this internal space is provided to allow our Government customers to access progress reports, and to review documents prior to wider release.
The same employee maintains a company-wide news server. Internal newsgroups provide a centralized "home" for on-going technical discussions. Internal newsgroups and company mailing lists are dual-gatewayed, so that messages sent to a gatewayed mailing list are also posted to the news server. This employee also acts as Webmaster for a public OBJS Web site hosted at a commercial ISP. This site supports public Web pages providing general Internet access to reviewed and approved OBJS documents, and general information about our company. Once reviewed and approved, documents are moved from our internal space to our public Web pages via Internet File Transfer Protocol (ftp).
Legal and other general postings. The company is obligated to display postings informing employees of their legal rights. These are scanned and made available via our shared internal Web server, and/or mailed (electronically or in hard copy) periodically. The internal server is also used to post information about health and insurance plans, and other company wide information (e.g., policies and procedures).
Policies and Procedures. OBJS is governed by a collection of written Policies and Procedures covering Basic Office Supplies, Benefits Policy, Book and Subscription Policy, Home Office Furniture Benefit, Miscellaneous Virtual Office Policies (Drug Free Work Place, No Sexual Harassment, Equal Employment Opportunity, No Bribing), Other Direct Cost Policy, Reimbursement and Expense Statement Policy, Time-Bank Policy, Time Charging Policy, Travel Expense Policy, and Virtual Office Weekly Progress Reports. These policies are communicated to employees when they join the company via email attachment and hard copy. The policies, as well as forms for travel expenses, insurance, and hotlinks to IRS forms, FARS/DFARS regulations, and per diem rates, are also available from a company internal administration Web page. In setting up a VO, it is especially important that the Policies and Procedures prepare employees for some of the effects of the VO environment, and of company expectations in that regard. OBJS has adopted a specific Virtual Office Policy which relates the history of the OBJS Virtual Office, and describes the general implications of the VO environment on Policies and Procedures. Individual Policies and Procedures also reflect the specific requirements of a VO environment.
Progress reporting and tracking. Progress reporting and tracking is particularly important in managing VO activities, since employees are "out of sight". Progress can be reported in a number of ways. In the OBJS VO:
Purchasing and cost reporting. In the OBJS VO, some purchasing (e.g., relatively expensive items of hardware to be bought by the company) is handled by the office manager, with technical assistance from other employees if required. Other purchasing, e.g., office supplies and personal reference materials, is handled by the individual employees (following company Policies and Procedures). Product information is obtained via hard copy catalogs, phone inquiries, and Internet searches. Employees submit expense reports (including the costs of such purchases) via electronic mail, with hard copy followup (with receipts attached). This combination has improved the speed with which employees' expenses are reimbursed, while maintaining an adequate audit trail. Since our hardware/software environments consist of workstations or personal computers, acquiring both hardware and software by telephone orders from catalogs or via the Internet is both straightforward and fast. Employees also use corporate credit cards for company-related purchases and travel expenses, which provides one-stop billing, and eliminates waiting for reimbursements.
Timekeeping. Employees must follow normal timekeeping rules. Timesheets, in the form of Excel spreadsheets, are circulated to each employee monthly via email. Employees must keep their timesheets current on a daily basis, and must print and sign that week's timesheet at the end of each week. At the end of each month, the completed spreadsheets are emailed, and the signed hard copies are mailed, to the OBJS office manager. The electronic submission of timesheets helps support more timely processing of this data for billing purposes, and reduces the amount of overhead involved in this activity.
In both timekeeping and cost reporting, additional technology could potentially be used to eliminate hard copy altogether. For example, hard copy receipts could be scanned and submitted electronically, and some form of digital signature technology could be used for employee signatures. Mechanisms (and possibly changes in legal requirements) would be required that would allow such receipts to be considered as "original" for audit trail purposes, and would allow the digital signatures to be considered as equivalent to the original ones.
Recruiting. OBJS recruiting has been done via email and newsgroup postings, as well as by informal word-of-mouth "networking". Interviews have been conducted by a combination of ordinary face-to-face interviews, telephone interviews, and in one instance a videoconference between our Boston and Dallas locations (see below). In preparing for interviews, candidates' papers, resumes, and presentation visual aids are circulated via email attachments, if they are not already on-line. These means of recruiting have proven successful in building a high-quality company team, while reducing travel expenses. While these techniques cannot necessarily entirely replace conventional recruiting mechanisms, they are becoming increasingly-common adjuncts to those mechanisms. For example, listing open positions on corporate Web pages is now quite common, as is electronic submission of resumes. In addition, a recent New York Times newspaper article ("Don't Touch That Dial: Why Should I Hire You?", April 13, 1997) reports that use of videoconferencing for initial interviews is in increasing use in many corporations.
Office Hours. A key part of the VO policy is an understanding about office hours. In OBJS, employees are expected to be available for scheduled meetings (so far, we have only had one), and to be generally available during "working hours" (this has a somewhat elastic meaning). Employees indicate when they will be absent via email to the entire team. Employees can trade off other hours from work day to evening or weekend. Over time, availability is confirmed via weekly progress reports, contributions, and via phone or email interactions. Video conferencing would involve a more direct form of employee availability, and would also require more synchronization of availability. This can be a particular issue when employees work in multiple time zones (as in the case of OBJS).
Travel Planning. Even in a VO, some travel is still required, e.g., to meet with external colleagues or customers. A Travel Policy governs travel. Travel planning can be done either centrally, or be the responsibility of the individual employee (in either case, travel agents can be used). In OBJS, travel planning is up to individuals. Government per diem amounts for various travel cities are available on the Web, and OBJS forms for expense reporting are published on our internal Web server. Employees have used the Internet to find hotels/motels in travel cities, check airline schedules, etc., and either map software or on-line maps to determine proximity of lodgings to meeting locations. The Internet can also been used to make airline/car/lodging reservations. Access to travel information and services on the Internet is straightforward via index services such as Yahoo. Overall, the use of these electronic means to support travel planning has been successful, but does not necessarily replace more conventional approaches (e.g., the use of travel agents). Travel planning can involve arbitrary amounts of time, given the resources available on the Internet. Improved integration of map and travel service information would be very helpful, since it is often hard at present to determine the exact location of facilities (especially relative to others) for some purposes. In addition, the amount of information available on-line differs from facility to facility.
The Web. The range of information available on the Web is quite substantial -- news releases, white papers, reference guides, user manuals, publications, magazine articles, and, to some extent, email messages and News postings. Searching for relevant information on the Web involves the use of sites providing pre-organized collections of references, such as Yahoo, and/or sites providing search engines, such as Alta Vista. Multi-search search engines, which automatically access multiple individual search engines and merge (to some extent) the results, are also available. In OBJS, we make frequent use of these tools to find material on our research topics, as well as material relevant to other activities (e.g., travel planning, hardware/software products). We also make use of specialized search engines for research reports such as the Networked Computer Science Technical Reports Library.
Although these resources are usually straightforward to use, using them efficiently often requires some experience. For example, since sites can differ in their coverage of the Web, experience is helpful in determining which sites consistently provide useful results (opinions on which sites these are can differ from one individual to another). Determining the proper search terms (keywords) that will return the desired information is not always easy; experience is helpful in formulating queries that minimize the amount of irrelevant information returned, and maximize the chance that a relevant result will not be overlooked. Some Web search engines provide no ability to refine a search based on the results of a previous search. Alta Vista provides a facility called Live Topics that helps deal with this. In addition to returning the results of a search, Live Topics creates a structure of key words and concepts also contained in the returned Web pages. After looking the topic list over, one can narrow the search by selecting which topics to search on. However, instead of using the results of the previous search, the selected topics are added to the original query and another full search is performed. While this is somewhat inefficient, it at least helps in focusing the query based on the available information. Additional tools or Web resources that could help users with, e.g., search vocabularies and other metadata, would assist in the process of both formulating original queries, and refining the results of previous searches. Multi-search search engines sometimes make it difficult to adequately control a search. Some put a maximum on the number of results per query, and it becomes a race as to which search engines return their results first. Others allow a maximum per search engine. In both cases, the possibility of missing key results exists.
Information obtained via explicit search is pulled information. This has the disadvantage that the user must continually re-search, or re-visit relevant Web sites, in order to determine if new information has become available. It is also possible to obtain pushed information, i.e., the user indicates a desire to be notified when new information becomes available. Some specific sources maintain email lists to which people can subscribe for this purpose. Specific software products, such as Netscape's In-Box and Smart Bookmarks, also provide means of being notified when Web page content changes. Other tools, such as NewsTracker and PointCast, allow the user to personalize delivered news by selecting topics or channels. We have found these technologies to be useful in certain circumstances, although care in selecting sources for push information (and what specific information is pushed) is necessary in order to avoid being deluged with information.
News groups. Internet news groups can also be a valuable source of information in some areas. Such news groups are sometimes indexed by Web search engines, which can then be used to find relevant news postings. In other cases, specialized News readers must be used. In OBJS work, news groups such as comp.databases.object and comp.object.corba have proven to be valuable sources of information on their specific technical topics. In addition, they can be valuable in dealing with hardware or software problems (see below). Both Web resources and news groups require the user to exercise care in assessing the value of any information retrieved from these sources, since anyone can place information on the Web, or post information to news groups. Thus, a certain amount of cross-checking can sometimes be a valuable precaution. Experience is also useful in determining which posters are knowledgeable.
Internally-generated information. Organizing and searching information generated internally (together with information obtained from external sources) is an issue in any organization. For example, in OBJS we generate a large amount of email and documents, in addition to retrieving documents and other information from the Internet.
Individuals organize their own information however they please, although shared task-related information is organized according to task templates, as described in the next section on Internal Collaborative Activities. Email is typically organized in multiple files according to subject. Documents are organized into separate directories, again typically by subject. In some cases, employees have created desktop Webs of HTML documents containing links or references to other desktop documents, and documents both on our internal server and on external sites. This helps maintain meaningful relationships between documents. However, with the exception of HTML documents, these different sources of information are difficult to integrate, due to the limitations of current tools for integrating both HTML and non-HTML documents from these different sources. Improving the ability to integrate all kinds of electronic documents will be important in improving the ability for individuals to organize their information. Without such organization, it is easy to become "swamped" with the large amount of information that is available (or created) on a given subject (or related subjects). A better integration of the Web, desktop file systems, and other information sources (e.g., email) would also provide an enhanced ability to create the kind of shared information spaces that can serve as central repositories for company information and operations, both for accessing information, and for creating new information (since, in the context of the overall repository, it would be easy to establish relationships between the new and existing information). Providing this integration requires improved technology for integrating the various data types involved (e.g., HTML documents, email, etc.), as well as for integrating the various tools involved (e.g., integrated search tools that could then be applied to the various data types in the combined repository), since at the moment separate tools must often be used for each data type
Indexing our internal Web server has helped in locating documents based on their content. Separate tools can be useful for indexing email and files on individual users' hard disks. Some of these tools can also be used to index files on removable media (such as tapes or cartridges), so that information on them can be readily accessed even when they are dismounted (in other cases, separate tools must be used for this purpose). Another useful category of tools are those (e.g., FmView for PCs, CanOpener for Macintoshes) for viewing the contents of a file without having to launch the application that created it.
Hard copy materials. Conventional research (as well as other office activity) involves access to books, periodicals, and hard copy documents of various kinds. Organizing and searching such material is a typical problem in any office. OBJS employees typically use conventional techniques for organizing their hard copy material. To date, there has been no significant attempt to use PC database software to index hard copy collections. Some professional societies (e.g., IEEE, ACM) have begun to provide some of their technical literature, originally published in hard copy form, on CD-ROMs. These include the proceedings of some important conferences, and archives of past years' technical publications. Some OBJS employees have made individual use of this material. Since these CD-ROMs typically come with search software, they make the job of finding relevant articles much simpler. In some cases, the material on these CD-ROMs also includes links to external Web pages providing additional information on the subjects covered. This form of material also has a beneficial effect of reducing the amount of shelf space in the home devoted to retaining many years' worth of technical literature. In OBJS, we have investigated (but not yet implemented) creating an internal server-based archive of CD-ROMs, using CD-ROM juke box hardware. Such an archive is quite feasible with COTS technology.
The Virtual Office White Paper notes that hard copy materials are harder to share in the distributed workplace than in the central workplace. The white paper refers primarily to the cost involved in this (i.e., in having to duplicate material at multiple locations), but it is also an issue in simply obtaining timely access to the information. In a central office, it is possible to borrow publications from colleagues or central libraries (although colleagues are an important source even where a research library is available, since colleagues are more apt to have access to specialized publications that may not be of wide-enough interest for even a research library to acquire). In OBJS, we have in some cases used scanning and faxing to address this problem. In other cases, an on-line source for the same material has been found. As the white paper notes, this is becoming less of a problem over time as publications increasingly go on-line. This is especially a consideration in our particular profession (computing), since many of the journals and documents that we most rely on are moving fairly rapidly in the direction of on-line publication, and some of the most current documents we need to access are available on-line before they are available elsewhere.
In OBJS, documents are generally written either as Microsoft Word documents or as HTML documents. When composing HTML documents, we generally use WYSIWYG HTML editors (e.g., Word Internet Assistant, Netscape Navigator Gold, Adobe PageMill), which allow document creation without needing to directly enter HTML tags. However, these editors do not support the full functionality of HTML (or support different advanced features), and sometimes it is necessary to edit the HTML directly, a capability not provided by all HTML editors. Also, some HTML editors do not provide spelling checkers. Hence, sometimes an ordinary text editor, or a different HTML editor, must be used. To read documents created by these editors, in some cases the editors themselves can be used; in other cases, a Web browser must be used. Some editors contain an internal browser, or provide for the launching of specified external browsers. Separate tools are also frequently necessary in order to prepare graphics (e.g., diagrams) for insertion into these documents. Email messages are sometimes written using the text editing capabilities of the mailers themselves; in other cases, they are prepared using HTML editors or text editors and either attached to or inserted into the messages.
Once documents are written, they must be made available to their intended recipients. This is done by either attaching them to or inserting them in email messages, or by publishing them as Web pages. We are increasingly publishing documents to our internal Web server, as opposed to attaching them to email messages. This creates an indexed, shared information space that is readily available to all employees. For reasons of security, we publish Web documents using Web publishing tools (generally, the Netscape Navigator Gold Editor), rather than providing incoming ftp access to the internal server. Current Web publishing tools are better adapted to the low-update environment of conventional Web site administration, where documents are only infrequently added or modified. They are somewhat cumbersome when used in an environment where there are rapid and frequent update requirements, such as in a VO shared information space. Enhancements in these tools would improve the ability to use the Web as a VO shared information space. The same tools can also be used to publish non-HTML documents (e.g., .doc files created by Microsoft Word), although the process for doing this is even more cumbersome. Incoming ftp access to our internal server would make some of these operations easier. However, this would require the use of either secure ftp or Virtual Private Network technology in order to provide the same security as we currently have using https. We have investigated these technologies to some extent, and could adopt one of them if the need became sufficiently compelling. IPsec, the emerging IETF standard for secure TCP/IP, is the ultimate solution, but it will not be usable over the open Internet until IPv6 is widely deployed, which is still in the future.
In addition to writing documents and posting them in a shared information space, there is a requirement to create linkages between related documents (both local and external), and to maintain the referential integrity of the collection of documents over time. As noted already, improving the ability to integrate and interlink all kinds of electronic documents will be necessary in order to improve our ability to organize our information, making it more usable in our research activities. We currently use tools such as HomeSite and CyberSpyder Link Test to verify links between HTML documents. Such tools would need to be extended to support linkages between arbitrary kinds of documents.
In preparing documents, as in accessing them, a better integration of the various tools (drawing tools, HTML editors, emailers, etc.) would help avoid the need to switch between tools in creating the more complex documents. The amount of integration available differs between tools, and also between platforms. Desktop integration technologies, such as OLE and JavaBeans, are beginning to address this requirement, but current applications do not always take full advantage of these technologies.
The need for employees to maintain their own computing environments means that they must devote a certain amount of overhead time each month to keeping their environments up to date, performing backups and other maintenance, and dealing with any problems that arise. Given the level of reliability of some PC-level platforms and software (e.g., Web browsers), and the speed with which changes in this software occur, this overhead can sometimes be significant. For example, in the OBJS VO the Web browser is a critical tool, particularly for those employees who also use it to read email and news. Some employees have encountered problems with this software (they are relatively frequent on some platforms), and these can become serious productivity bottlenecks. At least one employee has encountered a major disk failure (in this case, the availability of a complete backup on removable media allowed for a complete recovery), and several employees have encountered operating system problems of varying severity (e.g., failure to boot). Additional time is sometimes also required to deal with interoperability issues that arise in a heterogeneous computing environment, even between versions of the same product running on different platforms.
In dealing with these issues, access to on-line sources of information and software is a significant asset. For example:
Software delivery via the Web, or at least the notification of the availability of such software, is an excellent motivation for push technology. This would allow users to register their interest in being made aware of new releases of certain products, or of further information about those products (e.g., bugs that are reported), when it becomes available. Some vendors currently maintain mailing lists to which people can subscribe for this purpose, and the push tools mentioned above could also be used for this. However, this technology is apparently not yet in widespread use for commercial software change notification. This is illustrated by the fact that many messages posted to product-specific newsgroups ask about problems that are well-known to frequent readers of those newsgroups. Moreover, in many cases patches or upgrades to address those problems have already been made available for download at vendors' Web sites, unknown to the persons posting the messages.
In general, we have evolved relatively effective means of brainstorming via email and by annotating distributed documents. However, in some cases the threads of discussion got relatively long, and it became difficult to maintain context using only these mechanisms. For extended brainstorming sessions and discussions, NNTP or Web-based conferencing might provide some improvement, better supporting long, threaded messages and replies. Even in a relatively unstructured situation like brainstorming, it is often best if one participant does some initial thinking (makes a proposal or sketches the terrain), which can focus comment from others. Topics that wander too much are inefficient to discuss electronically. So far, our email discussions have not needed to be particularly confidential, which has allowed us to use ordinary Internet email. For confidential discussions, additional security technology, such as message encryption, would be required.
Group members also communicate with each other via email, in some cases with attachments (e.g., figures illustrating architectural ideas) and phone calls. Advantages of email are that it supports thoughtful comment and creates a record of the communication. A current disadvantage is that email conversations on technical topics cannot be directly linked to task templates, and messages sometimes appear to carry more emotional baggage (e.g., flames) than similar comments made in person. Advantages of phone calls are immediacy, and the ability to flexibly shift the topic of conversation. Disadvantages of phone calls are the potential for less-focused conversations, and the lack of a permanent record of the discussion (unless the calls are recorded, a mechanism which we have not yet used).
So far, we have found that a conventional divide-and-conquer strategy is adequate for co-authored documents. One person acts as lead, with the others writing up their individual sections, and either sending them to the lead via email or, more recently, posting them to the internal Web server as HTML documents. The combined document is then recirculated to all authors (in some cases to the whole team) for review, and then posted on the internal Web server. When interchanging interim versions of documents, revisions are indicated either by using specialized revision or annotation facilities (e.g., in Microsoft Word), or by writing revised text in different colors. This color-coding can be done in both Microsoft Word (and most other word processing software) and in HTML documents. Color-coding activities by week has also proven effective in our Weekly Progress Reports, since it enables incremental progress to be rapidly tracked.
We have not yet been extensively involved in situations where multiple individuals have had to collaborate on a document in a tightly-coupled fashion, or where they have had to work on different closely-interlinked Web pages. This will probably become more frequent as our work progresses (collaborative software development is a special case), and as our OBJS shared information space become more populated. Supporting this will require better annotation, version control, and configuration management facilities. The Netscape Enterprise Server, which we use for our internal Web server, supports checkin/checkout and versioning of individual documents, but the capabilities are relatively limited, and we have not yet made much use of them. As it is, we have noticed that better version control, and annotation by something other than color, would have been useful in a number of situations (e.g., in merging the comments made by different people on the original draft of this document).
While we have not yet installed videoconferencing in our individual offices, we have gained some limited experience with commercial videoconferencing services. We recently completed our first recruiting interview with a remote job candidate using Kinko's commercial videoconferencing service. This involved one of our employees and the candidate in a Boston location, and four of our employees in Dallas. Overall, we felt that this use of videoconferencing was a success. Even though it was somewhat expensive ($600 for two hours during a weekday), this was far less than the corresponding air travel and hotel bills would have been. However, this did not involve the use of Internet videoconferencing technology, which has problems with unpredictable quality of service, as noted in the Internet Tools Survey section mentioned above. Our general observations were:
Some industry observers feel that businesses in the next few years will focus more on data collaboration/conferencing than video conferencing. This is because data conferencing is more feasible with current technology--it takes less bandwidth, and imposes fewer demands on Internet QoS (ordinary conference calls can be used for the audio portion). Whiteboarding is an example of this. The idea is to collaborate around a common document in real time. This may be a diagram, plan, or spreadsheet in addition to a dynamically drawn whiteboard. This has been shown to improve collaboration, enabling the participants to come to closure more quickly. This is an example of the quality of service tradeoff, mentioned above, that current technology sometimes makes necessary.
We have also not as yet used calendaring and scheduling facilities, although the subject was raised at a recent face-to-face team meeting (our first), and we have recently installed the Netscape Calendar Server (for use with Netscape Communicator) on an experimental basis. While employees generally use email to notify the whole team of scheduled activities (such as travel) in advance, there is no central source for this information. As a result, it is easy to forget, and it is cumbersome to have to search archived email messages to find such information. Products are available to support calendaring, and our central server could provide a host for this service if necessary.
For our team, the use of electronic means for external collaboration does not represent a change from the VO environment as compared to a centralized one, since much of this external activity took place electronically even when team members worked in conventional offices. In general, a large amount of external interaction within the computer research community already takes place electronically. For example, publication increasingly involves the electronic exchange of material and provision of journals on-line. During the last year, team members have submitted papers for publication, with the entire process being electronic (no paper changed hands from submission, through reviewing, to final publication). Such things are becoming increasingly commonplace, and illustrate the feasibility of the VO environment, at least for some types of work.
lesson #2: Current tools are generally quite usable for straightforward VO tasks, but would benefit greatly from better tool integration. Such integration can reduce the overhead (e.g., the need to switch between tools) in performing complex tasks, and hence improve productivity. For more complex tasks involving information organization and access, and fine-grained collaboration, improvements are required in individual tools (e.g., for Internet searching and document annotation), tool integration, and data integration. Technologies (e.g., OLE) for integrating both desktop applications and Internet applications are starting to address the tool integration problem, but much progress remains to be made. At the moment, for example, there are multiple integration technologies (helper applications, plugins, and Java) just in the context of Web browsers.
Similarly, better data integration, e.g., of the Web, desktop file systems, and other information sources such as email, would be extremely useful. Such integration, for example, the ability to create links between these different types of information, would provide an enhanced ability to create shared information spaces for use as central repositories for company information and operations, both in accessing information, and in creating new information (since, in the context of the overall repository, it would be easy to establish relationships between the new and existing information). Providing this integration requires improved technology for integrating the various data types involved (HTML documents, spreadsheets, email, etc.), developments in standard data interchange formats, and improved technology for integrating the various associated tools. These integration-related issues illustrate the general need for better componentware and scalability technology, which is the focus of our research.
lesson #3: Our early use of a simple, shared information space (an internal Web) illustrates the promise of a more thorough implementation of this facility. Our task templates have provided a common structure for task-related information. This, together with search tools, has made it easier for us to find relevant material, and has also improved internal communication. However, as noted above, improvements in individual tools, and better tool and data integration, are required to fully enable such shared information spaces.
Papers exploring collaboration technology have noted the role of a "community (or external) memory" in developing a "virtual community" (see, e.g., papers from the ACM CSCW '96 Workshop, ACM SIGGROUP Bulletin, 18(1), April 1997). An example is provided by "MUDs" (Multi-User Dungeons and Dragons, or Multi-User Domains). In contrast to conventional "chat" systems, where the participants only "talk" to each other, in MUDs the participants can also create and modify objects in their environment. These objects play the role of the MUD's community memory, and provide an important mechanism for interaction among the participants. Similarly, a number of industry commentators have observed that an immediate goal in many businesses is to build an intranet for sharing enterprise information, making the full spectrum of business information available on-line. This is, for example, driving the connection of corporate databases to corporate Webs, making all this data available for uniform access via COTS Web browsers.
The "community memory" in an organization, or a situation description in a C4I system, is essentially a distributed data structure for recording current, past, and future state. Such structures support push-pull population of the structure, search/navigation to locate information of interest, information source and other "pedigree" metadata, etc. Our shared information space is a small-scale first generation variant of this type of distributed structure. A key goal of our research is to develop technology that enhances the ability to construct such shared information spaces. A key issue in Scenario #2 will be to investigate simple, low-budget ways to do this. Since our VO has no large shared databases in the conventional sense, a special issue for us is determining how to do this using Web/desktop technology to the greatest extent possible--"the Web as a database". A further requirement, as noted above, is to better integrate desktop documents (Word files, Excel spreadsheets, etc.) with Web information.
lesson #4: In a VO environment, individuals assume responsibilities for maintenance, administration, etc. that, in a conventional office, are generally provided by other people. The overhead involved with implementing and operating the individual offices in a VO environment needs to be carefully considered, in terms of such things as overall costs, and the level of effort this will require of individuals. One area we have only begun to explore is how to reduce the support burden on VO members. This will be important in scaling the VO to a wider variety of collaborators, some of whom need computing facilities but do not have skills to maintain their own environments. Techniques that could be employed include contracting with local support facilities, and the use of telemaintenance tools for allowing remote support personnel to access local computers. Telemaintenance is currently available on mainframes and some LAN routers, and tools such as pcANYWHERE and Carbon Copy can be used to provide a limited amount of remote support for PC-level hardware and software. Technology is also becoming available for automatically keeping PC-level software up to date (e.g., the LiveUpdate feature in Norton Utilities for NT).
lesson #5 : There are many potentially-useful COTS/XOTS tools that we have either not yet made use of, or which have been used only by a few individuals. For example, we rely primarily on Email to exchange ideas, and use the phone relatively infrequently (even for regular calls, let alone conference calls). Similarly, we have not yet used virtual whiteboards, Talk/Chat facilities, or Internet phones. This may have in some cases inhibited collaboration, by raising the threshold to be overcome in having in-depth discussions. We also have tools in place that could be used more intensely. For example, we could make more use of our OBJS newsgroups. They act as persistent central placeholders for ideas exchanged and feedback comments. At the moment, everyone houses this information locally in email archives. (However, as noted already, we have increasingly been using our internal server to house all OBJS documents -- trip reports, progress reports, task status reports, proposals, minutes of attended meetings, whitepapers, ARPA reports, etc. -- making them all easily accessible and searchable).
In general, this reflects the following factors:
lesson #6: General use of videoconferencing is not yet a real option. This is particularly true of videoconferencing over the Internet, since the qualities of service available are generally not acceptable. On the other hand, more attention needs to be paid to data and voice collaboration as a way of improving collaboration, while addressing current Internet quality of service issues (similar observations about the relative importance of high quality voice and data services versus live video were made in some papers at the ACM CSCW '96 Workshop cited above). We will continue to monitor and experiment with these technologies.
#1 Investigate additional COTS tools, together with more refined use of existing tools.
Previous sections have noted a number of additional COTS tools available for facilitating work in a VO. We intend to pursue use of such additional tools in subsequent work. We will adopt tools incrementally and opportunistically as needed, and as usable versions become available. This includes the use (or more widespread use within OBJS) of tools such as those in the following list:
#2 Further develop our shared information space
A particular focus in the immediate future will be further developing the use of our shared information space. For example, the need for information on our experiences with various VO mechanisms (and the more advanced activities in later scenarios) suggests the need for us to be continually documenting our experiences, and feeding them, and suggestions for improvements, into a central "experience repository" as part of a shared information space contributed to, and accessible by, everyone. As noted already, a shared information space provides important support for other collaborative activities as well.
Part of this work will involve investigating straightforward techniques and existing tools to support enhancements in our ability to support a shared information space. Possible examples include:
At the same time, our task templates are an exercise in creating a shared data structure that we progressively complete to accomplish our "mission". In that sense, they resemble a situation description (or a plan) in C4I. Hence, pursuing this work provides the basis for both scenarios and technology that more directly relates to DoD requirements, as well as the basis for experimenting with new technology that we develop to more fully address these requirements. For example, we expect tools that we are developing to be able to assist in tasks such as creating a semiannual report from monthly reports by, for each section, doing a sectionwise concatenation of corresponding sections in each monthly report. The pre-existence of the base data for this in a semistructured form would obviously be helpful, and, in fact, the existence of at least some structure in documents is often the norm in much operational information.
As noted already, intensive operational use of a shared information space requires improved tools for creating and managing both the information, and its relationships to both internal and external information sources, e.g., tools for such functions as:
Another area that will be of increasing relevance as our work progresses will be distributed, collaborative software development. An extreme example of this type of activity is illustrated by a short piece in the March 31, 1997 issue of Computerworld (p.130), which describes the development of Debian GNU/Linux, a Unix-compatible operating system. Among other things, this operating system will run an onboard hydroponics experiment on the next space shuttle. The operating system was developed by 200 volunteer programmers who collaborated over the Internet and never physically met each other. More information (and free source code) is available from http://www.debian.org.
Although software development obviously involves the use of specialized tools such as compilers and linkers, this activity can be properly viewed as a special case of the creation and maintenance of a shared information space, as described above, and requires the corresponding types of tools. For example, Lessons Learned Administering Netscape's Internet Site, by D. Mosedale, W. Foss, and R. McCool (IEEE Internet Computing, 1(2), March-April 1997, 28-35) is a recent article on Netscape's experience in administering its Web site. The paper notes that:
"In some ways, the creation of Web content resembles a mid-to-large programming environment. Our content comes from several different sources within the company, and we chose a document revision system to manage its development as multiple contributing editors added and deleted material from the content tree."
The paper describes the use of a versioning system, which was originally designed to track source changes made by groups of developers working on the same files, in managing HTML changes to their Web documents.
Collaborative software development will also ultimately (although not necessarily in the immediate future) involve licensing management and software search capabilities, both to search for available components published on the Internet for importing into our own work, and as part of our research into general componentware enabling technologies.
#4 Further scenarios
Scenarios following Scenario #2 will increasingly focus on the use of new technology we are developing, specifically:
Our near-term work on enhancing our internal shared information space will provide a bridge between our current work and the use of these tools. For example, SSISSS is intended to be capable of searching and extracting material from arbitrary sources in our shared space, including ordinary documents, Web pages, and email and news files.
This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.
© Copyright 1997 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this survey.
This page was written by Frank Manola, with input from the entire OBJS team. Send questions and comments about it to firstname.lastname@example.org.
Last updated: 5/6/97 fam
Back to Internet Tool Survey -- Back to OBJS