NARA: a sneak preview.

For almost 30 years, the National Archives and Records Administration (NARA) has been involved with managing electronic records. It accessions data files and other electronic records of archival value from federal agencies and makes them available to researchers. NARA also provides guidance to agencies on how to manage their electronic records. One solution NARA currently recommends is the implementation of a records management application (RMA) to manage office automation records, including e-mail. Yet many of NARA's staff involved with electronic records never had the opportunity to actually use a RMA to manage their own records. NARA's own records management program does not have the capability to manage electronic records electronically; agency staff are required to "print and file."

To correct these two conditions, the NARA records management team (RMT) joined forces with the NARA Modern Records Program two years ago to install and test an RMA. Planning began in the winter of 2000; the contract was awarded in September of the same year. Live system testing began in April 2001 and ended six months later. The contractor delivered final reports in December.

NARA's RMA project, dubbed RMA2000, was meant to be a learning experience. The Modern Records Program would acquire expertise and knowledge that it could incorporate into future electronic recordkeeping training with agencies. The RMT wanted to gain hands-on experience with installing and using a RMA so it could make educated decisions in the future about deploying the technology agency-wide. The RMT also wanted to know what actions were necessary to connect the system to NARA's IT infrastructure and which of the agency's records management procedures and disposition standards might require revision to accommodate the RMA. Moreover, the RMT wanted to test the usefulness and accuracy of autoclassification technology that had begun to appear on the market.

Since this effort was considered a learning experience, the project team limited the number of participants to 30 -- enough to be statistically significant but not so many as to complicate the implementation. End users included clerical staff, staff archivists, and the General Counsel to the Deputy Archivist of the United States. TrueArc's Foremost, a commercial, off-the-shelf RMA application, was selected because it was the only RMA then available that fully integrated autoclassification via a product called AutoRecords. Foremost also satisfied NARA's three-tiered architecture requirement.

The project team decided early on that it would work through a systems integrator, placing the responsibility squarely on the contractor to deliver a turnkey system rather than having to install and configure the system on its own. The selected integrator, GRC International, together with TrueArc, also developed the test methodology for the project's AutoRecords component, performed the autofiling and training tasks, and collected all pertinent test data. At the test's conclusion, GRC was responsible for writing and delivering a final lessons-learned report as well as an analysis of the test data.

AutoRecords uses neural net technology to classify documents automatically and file them into the system. The project team wanted to determine whether autoclassification was a solution to the "compliance problem" (i.e., the reluctance of employees to take the time to actually file their own records in an electronic repository). In the test model devised for the project, AutoRecords' results would be compared with the records that participants manually filed throughout the entire test period. These manually filed documents were first verified by the RMT for filing accuracy, which ran as high as 96 percent.

First, the contractor ran a routine to train AutoRecords; the product is supposed to "learn" over time and increase its accuracy rate. AutoRecords looks at previously filed documents and electronic folders, analyzes what kinds of documents are in each folder, and stores the analysis to use when filing subsequent documents.

When implemented as designed, AutoRecords files a document as the user declares it a record. If the software has any doubts as to where the document should be filed, it consults the user for suggestions. For the purpose of the test, however, this aspect was eliminated. Users manually filed records and AutoRecords filed a duplicate set of records in the background. This was accomplished by the contractors doing a search of all records manually filed since the last filing, copying them, and submitting them to AutoRecords. The results from AutoRecords' autoclassification and filing were then compared with the manually filed records, and statistics were gathered.

Installing a RMA requires significant planning and configuration because a RMA's success depends to a great degree on how it is configured. The project team found that the two most important configuration issues it needed to grapple with were the file plan's granularity level and the ability -- or inability -- to implement an open repository. During the requirements-gathering interviews early on, some participants indicated a need to file records into elaborate subject-file schemes that they felt would be necessary for document retrieval. The contractor complied and devised several granular file schemes.

After the system went live, it soon became evident that filing into a large number of small buckets was extremely cumbersome, significantly affecting the rate of compliance. The file plan was then revised to reduce the number of buckets and make them more general in nature -- few big buckets versus many small buckets. The contractor convinced the "granular filers" that they could retrieve documents by using the powerful search engine built into Foremost. Unfortunately, AutoRecords' needs muddied the waters because, the engineers indicated, AutoRecords worked best filing into a more granular file scheme. Although the issue was never fully resolved, the contractor did revise the file plan somewhat, reducing the granularity and making manual filing easier.

The second issue revolved around how open the repository should be to all users. At the project's very beginning, the contractors advocated having a mostly open repository, with most documents accessible to all. Accommodations would be made for sensitive documents by assigning higher security levels to them. This follows the growing trends of data sharing and data mining. At a general end-user meeting in November 2000, all participants nodded in agreement, not really aware of this arrangement's implications, as going live was still five months away. Six weeks before going live, when the project team reminded participants about the open repository, the response was less than enthusiastic. To stave off an insurrection, stovepiped organizational access soon prevailed. That required some very complex arrangements using Foremost's access control lists and security levels. Diagramming the configuration covered three walls of white board. For the moment, corporate culture prevailed over technology.

As of this writing, NARA is analyzing the data delivered by the contractor in its final reports and intends to issue a full report within the next few months. What is immediately evident from the RMA2000 project, though, is that implementing a records management application, even a small one, requires large amounts of sweat, patience, coordination, technical expertise, and a hard look at the organization's business practices. Even though RMAs are COTS products, buyers cannot expect to break the shrink-wrap on the box, install the product, and expect it to work overnight.

(Editor's Note: The products mentioned in this article are examples from the author and do not constitute endorsement by ARMA International.)

Richard W. Marcus is the Records Officer for the National Archives and Records Administration. He may be reached at [e-mail].