Research Issues in Systems Implementation, Risks, and Tradeoffs
Anne Marie Makarenko
Electronic Records Meeting
Pittsburgh, PA
May 29, 1997
Today's worker relies on having access to a myriad of information and applications 24 hour a day, 7 days a week in order to carry out his or her responsibilities effectively. The worker is supported by a staff which handles the network technology, system backups, user training, and troubleshooting problems. The goals such staff have are to make sure that the appropriate information systems [1] are implemented, that they work well and that the information and applications are available for retrieval in case of a catastrophe. Archivists' skills as information managers add a third dimension to this situation, in that we can provide input on the front- and back-ends: our input to technology staff can add value to the information systems that are being developed, and we also have the opportunity to address records issues with the end-users. We are often in the unique position of being the only staff in our institutions with the knowledge of policies and practices to reduce the risk to which the institution is exposed, and applying this knowledge is especially important in relation to electronic records.
For some time now, Archivists have realized that they can and must play a role in system development, but the full potential of this opportunity has been realized by very few. A major barrier to our success in becoming involved is the lack of buy-in from the other people working on such projects. This clearly indicates that we have not yet proved the value we add to the process. The terms that are frequently used, e.g. systems which will ìaccommodate recordkeepingî and the ìimplications [of systems] for archivistsî suggest that archivists are still very much external to the process. A handful, albeit a growing one, of agencies has taken steps toward addressing the challenges proactively, but these steps need to be taken much further, more agencies must participate, and archivists must change their mindset to acknowledge that the majority of future archives will be developed and maintained in electronic systems.
Our efforts in the area of system implementation must focus on using the system to do what we cannot possibly do on our own: manage all record and non-record information in appropriate ways so that the business needs of the organization are met, the legal requirements are satisfied, and the history of the organization is documented and maintained. To do this, archivists will need to become involved at three levels: the organizational/professional level; the technological infrastructure level, and the system development and implementation level. The rest of this document will outline issues and areas for research within each level.
As has been stated by numerous electronic records archivists before me, we need to drive the development and use of information systems by being active members of the system development and integration teams. It will not, however, be productive to serve on such teams if we donít have adequate knowledge of the technologies involved. Users have one agenda, system administrators have another -- some of their plans even run against ours, but it is our responsibility to be effective in conveying the need for and the details of system components which will ensure the long life of valuable information. It will be important to develop methods of managing e-records which will be easy to implement and wonít make the system overwhelming or user-unfriendly. We need to make it clear that we are not imposing these requirements on the system developers, implementers, and users, rather, the requirements come from the nature of the information itself and the laws and values that apply to that information.
In order to take this role, archivists must have enough technical education to be able to understand and even suggest specific technology solutions. In addition, we have to develop our communication skills to facilitate discussions with other members of the multi-disciplinary teams that will be developing the systems. Using a common language (e.g., language of business) will also increase the likelihood that our ideas will be accepted and supported.
Archivists are poorly prepared to be launched into a role which requires such a level of technical and business savvy, and the only answer to this is to put a heavy emphasis on incorporating this training into the educational programs and post-degree seminars that are offered. The Master of Archival Studies degree curriculum guidelines which were approved by the Society of American Archivists in June of 1994 did not adequately address the issue of technological training, even though the CART curriculum development project final report was published a year earlier. [2] This indicates a serious lack of commitment to developing this important aspect of our profession, an aspect which is likely to become the largest part of our jobs within the next ten years.
Richard Kesner suggests a core competency model for archivists to enable them to contribute to the process of automating and "informating" business processes within an institution. [3] This model is very technology-intensive, and suggests a radical transformation of the archivist's job to a proactive member of teams directing the choice, implementation, and use of new information technologies.
In addition to our need for further education, another barrier to our success is the lack of hard evidence that what we are striving for actually adds enough value to a system to warrant the extra attention and expense. We need to actively apply our skills to the development of systems so that we can create examples and case studies outlining the successful and unsuccessful aspects of the projects. The process will also give us credibility with other professionals, making the idea of such systems less nebulous and overwhelming that they are now. There are success stories in other professions about developing electronic information systems which also do records management, in which archivists have had no part. We need to find out who has developed such systems and learn from their experiences.
An effort also needs to be made to shift the responsibility for electronic records management from ourselves to the creators and users of the record information. A method which we are planning to implement this fall at Babson College is to add records management (electronic and other) into the set of core competencies required of all Babson employees. In addition, when individuals receive computer training, one component of this training is an explanation of such things as how they should store their documents and what the implications of different storage techniques and locations are. This gives us the opportunity to train records creators as a part of the regular quality training they receive, thus mainstreaming the process. Users of technology need to be assured of the security of the records they create, and as we work toward this security at the systems level, we need to educate the end-users of the status as well.
On a more mundane note, it is still left to us to identify records in electronic information systems and set out retention and disposition schedules for them. This process must occur for the others to work, so it is essential that we develop models for inventorying records in electronic systems and models for the disposal or preservation of electronic information.
If we are to move toward the ideal of organization-wide, seamless electronic information systems which incorporate records management functions, we will need to have input into the very infrastructure being put in place to support the business process. The infrastructure can be a local or wide-area network, or a decision to invest in the use of a particular set of software tools which will serve as the basis on which everything else will run. Here it is important to drive the effort to develop standards for components of this backbone and implement technologies which adhere to these standards. An interesting twist at the infrastructure level is the occurrence of institutions that are looking for ways to exploit the existence of the Internet to support the use of applications and data exchange. This opens up a different approach to developing a backbone, and raises standardization and longevity issues.
At the most detailed level, archivists have been examining ways to influence the development of systems within their own agencies. This is the most difficult and, potentially the most important level at which the electronic information management process can be influenced. It is the most difficult because it is here that archivists know the least and, correspondingly, have the fewest tools and contacts. It may be the most important because this level is where things really happen. Well-implemented organizational policies are important, but a well-implemented system will go much further toward achieving our goals.
Margaret Hedstrom points out that research indicates that there is a benefit to involvement at the design stage of a system, but that trying to extract records after the fact from a system that was not built with recordkeeping requirements in mind is a waste of time. [4] This finding indicates that we should focus our efforts on developing systems, and create methods and models for doing so. The model developed by the team working on the Pittsburgh Functional Requirements for Evidence in Recordkeeping project [5] has been the basis for a number of projects in which attempts are being made to incorporate recordkeeping requirements into developing information systems.[6]
For example, the Philadelphia Electronic Records Project [7] has, as one of its goals, to attempt to apply the Functional Requirements model to a new personnel system being developed for Philadelphia's City government agencies. The success or failure of such a project at this level will determine the future possibilities for application to other developing systems in Philadelphiaís city government. A potential barrier to the success of the PERP attempt to work in tandem with a team of developers on this system is that even with a drastically scaled-down model of the Functional Requirements, it still appears complex and, correspondingly, that it might be too expensive to be accomplished. It is difficult to argue the case for the addition of a seemingly unwieldy component, especially when the whole concept of incorporating recordkeeping requirements is so new to the non-archivists on the teams.
The Pittsburgh Project has made clear the possibility of incorporating archives and records management functions into systems being used to support basic business functions. The model needs to be tested further and fine-tuned, and examples of the model's applicability must be created.
In addition to working with large transaction systems, it is also important to develop and implement automated records management tools for use with typical office records, such as is currently being tried by City of Philadelphia Department of Records. [8] This type of tool will drastically improve electronic records management at the system level because it allows us to develop the rules on the back end and rely less on the individual to make a major effort to manage his or her own records.
The risks involved with the use of information and record keeping systems are many, but they are not ours. Our role in this process is to manage the risk to which our organizations are exposed. The tradeoffs that are made, however, will affect our work directly. Any decision that is made in support of a simpler, cheaper model will most likely not include many of the features we have determined to be critical to success in maintaining the records in them for the long-term.
The path out of this current situation is clear: archivists need to build on the tools we have and the research that has been conducted, and move the effort forward. Research findings will do us no good if we donít take them to the next level. We need to test methods and gain real examples of benefits and drawbacks of the incorporation of records management functions into electronic information systems. When we have done this, we will have more influence with other professionals and will also have an infrastructure on which we can base future endeavors.
[1] For the sake of this discussion, I will define a system as a combination of specific hardware and software put together and used to support any number of functions. Examples of complex systems environments include LANs and WANs, transaction systems, document management systems, multi-media applications, etc. [return to text]
[2] Committee on Automated Records and Techniques, Victoria Irons Walch, project Coordinator. "Automated Records and Techniques Curriculum Development Project," The American Archivist, Vol. 56, #3 (Summer 1993), 468-505. [return to text]
[3] Kesner, Richard M. Information Resource Management in the Electronic Workplace: A Personal Perspective on "Archives in the Information Society" presented at a Meeting of the Scientific Committee of the 5th European Conference on Archives, May 29, 1997, in Barcelona, Spain. [return to text]
[4] Hedstrom, Margaret. "Electronic Records Research: What Have Archivists Learned from the Mistakes of the Past? Archives and Museum Informatics: Cultural Heritage Informatics Quarterly Vol 10, #4 1996, 319-320. [return to text]
[5] Project site located at http://www.sis.pitt.edu/~nhprc (May 1997) [return to text]
[6] For a complete listing and description of applications of this model, visit http://www.lis.pitt.edu/~nhprc/IApps.html (May 1997) [return to text]
[7] http://www.phila.gov/city/departments/erms/erm.html (May 1997) [return to text]
[8] See Philadelphia Electronic Records Project Update, NAGARA Crossroads, 1997-2 [return to text]