September 1, 2001

(Rev. September 4, 2001) 

Making a Difference – Revisiting the IU ER Project Five Years Later: Commentary

 

by Richard E. Barry

 

Disclaimer: this essay reflects the views of its author and does not necessarily reflect the views of the IU Advisory Committee or the IU Project Team

 

The Indiana University Electronic Records (ER) Project is a multi-phase project follow-up to the University of Pittsburgh Functional Requirements for Evidence in Recordkeeping Project (see also), all of which were funded by the National Archives and Records Administration’s funding arm, the National Historical Publications and Records Commission (NHPRC). I was asked to comment on Phase I of this project at the Society of American Archivists (SAA) 1996 Annual Meeting in San Diego[1] and have been asked to do the same thing at SAA’s 2001 Annual Meeting. 

 

Pittsburgh Functional Requirements Project

 

The Pittsburgh Functional Requirements (FRs) began in 1994 and was completed in February, 1996. It’s products that are described on the Pittsburgh Project site include: a LITERARY WARRANT inventory supporting the functional requirements; 13 FUNCTIONAL REQUIREMENTS for evidence in recordkeeping; a PRODUCTION RULES version of the functional requirements to facilitate system development; and a multi-layer model of METADATA SPECIFICATIONS including 67 metadata items derived from the functional requirements constituted a set of requirements aimed at addressing systemic needs for trustworthy recordkeeping. They were developed at three main levels: the organizational level, the recordkeeping system level and the record level.  Thirteen requirements were specified at these three levels:

 

Organizational Level: CONSCIENTIOUS ORGANIZATION: 1. Compliant

Recordkeeping System Level: ACCOUNTABLE RECORDKEEPING SYSTEM: 2. Responsible; 3. Implemented; 4. Consistent

Record Level: CAPTURED RECORDS: 5. Comprehensive; 6. Identifiable; 7. Complete; 8.Authorized; MAINTAINED RECORDS: 9. Preserved; 9a. Inviolate; 9b.Coherent; 9c.Auditable; 10. Removable; USABLE RECORDS: 11. Exportable; 12. Accessible; 13. Redactable

Phase I of the IU Project

Phase I was carried out between 1995-1997. The findings of this Phase were published in “The Indiana University Electronic Records Project: Analyzing Functions, Identifying Transactions, and Evaluating Recordkeeping Systems - A Report on Methodology,” by Philip C. Bantin and Gerald Bernbom.[2]

 

The Phase II project has moved considerably from its origins in some important ways. Unlike the Philadelphia City project that took the Pittsburgh FRs largely as a given, Phase I of the IU project viewed the Pittsburgh FRs as a set of guidelines and recognized that real-life constraints might require making adjustments to those requirements, e.g., where existing invested technology architectures might make full application infeasible for budgetary or organizational reasons, where compromises were necessary with IT or program stakeholders regarding priorities of the various FRs, where there might have been an inability to persuade management as to the importance of all FRs, where it was deemed wise to start with the doable aspects of the FRs and postpone some of the less feasible ones until after being able to a result of the agility of the IU Project Team in identifying roadblocks, which could have brought the project to an early and incomplete end, and shifting field slightly as necessary to quickly take advantage of ‘targets of opportunity’ that arose at IU that were not evident during the project planning stages. Reacting quickly to take advantage of such opportunities made it possible to move ahead toward the original broad ends, perhaps taking a somewhat different path to get there. Had the team not been so agile, the project could have come up very short in both its expectations and results.

 

Phase II is aimed at designing and implementing an electronic records system using business systems modeling and analysis in the first enterprise system design to make use of portal technology to capture role-based records in the university environment. Possibly the first anywhere to use this approach for high-transaction financial and HR business processes, it is highly relevant to organizations throughout the public and private sectors as well as academia. Consideration is being given to the use of a workflow engine for the capture of records. This is part of a commendatory attempt on the part of the Project Team to make the best of an unfortunate and unpredictable decision by IU management, following commencement of Phase II, not to provide budgetary support for a certified Records Management Application system – more on this subject later. The project also includes important auditing experience stemming from a strategic partnership between the Archivist and Auditor. The Phase II follow-on project goal is “to integrate the Pitt recordkeeping requirements and the IU methodology for applying them into the standard set of procedures undertaken by the institution whenever an information system is created or modified.”[3]

 

1996 Review

 

The topics covered in my 1996 review were:

 

Participative Design of Recordkeeping Electronic Information Systems

Treatment of Functional Requirements

Meta-Data and Description

Build vs Buy

Reporting of Research Results to the Professional Community

Project Sustainability

Lessons for Future Projects

 

These topical areas continue to be relevant to this project and to lessons that might be applied to implementation projects elsewhere, and are addressed below as they apply to the Phase II project. There are, however, additional subjects not covered in the earlier review. Before addressing these subjects, a brief discussion of recordmaking and recordkeeping systems will help to illustrate the importance of this project and the potential contribution that it can make. I was also asked to comment on this research as it relates to other related on-going research in the area of information management and electronic records. Rather than treating R&D as a separate subject, I will mention research and potential futures where appropriate to the subject under discussion. As a general comment, however, there has not been an organized working session on electronic records research since the invitational conference on Electronic Records Research and Development at Ann Arbor and the Pittsburgh Electronic Records Research Working Meeting in 1996 and 1997 respectively. These very useful meetings were very much focused on on-going projects mainly in academia in the archives and records management community. They were effective because they were small and all virtually all participants had a responsibility in the agenda. At the same time, the results of these meetings were widely disseminated so that the lessons learned from them were not kept to the few most involved in the research. This is a good model for future such working meetings.

 

With the rapid pace of technological change, and maturing thinking about electronic records, it is none too soon to consider another such working meeting. In my opinion, this time it should involve others in the broader research community where important work is going on that could have considerable beneficial application to the electronic records application area, such as the work ongoing at the IBM San Jose Research Division (see below), computational linguistics and natural language processing research at Xerox and elsewhere, especially that related to automated classification of text, image and sound files, agent technology work at the University of Massachusetts, etc. All of these have pieces to the puzzle. Yet, few of them are even aware that the archives and records management (ARM) community has a puzzle that needs to be solved or that they may have some of the missing pieces.

 

The Nature and Management of Records

 

It may not always be so but, at present, it appears that the advent of digital records has not changed the basic meaning of recordness.[4] One possible exception to that statement has to do with the generally accepted description of the properties of records as having content, context and structure. Technology has moved toward multiple platforms for the presentation of the potentially the same documentation – from large wall displays to large-format TV and desktop computer monitors to hand-held computers and portable telephones, all of which already have browser capabilities. In future, we may very well see the business use of ‘heads-up’ displays that have been used for some time in combat aircraft and the emergence of a ‘Tablet Computer’ (currently under development at Microsoft) about the size of a sub-notebook or smaller. The Tablet will differ from existing hand-held computers in an important way: the latter have been designed to operate in conjunction with a desktop or notebook computer as a sort of temporary portable, whereas the Tablet is being designed with the aim of replacing desktop and notebook computers. 

 

What has all this to do with the meaning of recordness? These various platforms cannot present the same information in exactly the same structure. What one can see on a desktop computer in a single screen must be rendered differently to the user of a portable telephone. Thus, I believe that we may see more movement toward the storing of information in application-independent and structure-independent forms, especially but not only for documentation created, used and managed principally in electronic form (except possibly for convenience copies). With this kind of approach, documentation, including textual documentation, may be maintained more like a database than a document repository is today. A separate presentation layer in the design architecture makes it possible to render whatever structure is appropriate for the data to be presented on any platform.

 

If the kind of approach outlined above becomes a strong presence in the way that information and technology managers manage documentation, it may very well change our thinking about structure, and multiple structure formulations may simply become contextual information that is included as part of the metadata associated with the documentation. Some website designers recommend this separation of data and presentation layers for current websites and argue that it is better to avoid the use of, say, HTML at the object level on the grounds that that kind of manipulation can be added at the presentation layer. If one uses HTML at the base level, then whenever an XML or XSL replacement comes along, one has to reconfigure the entire database in order to take advantage of the added functionality of the new thing.

 

This is not unlike the approach being undertaken in other research venues. The San Diego SuperComputer/NARA research project on very long-term preservation of digital archives uses an application-independent data approach. IBM work underway at its Research Division in San Jose, California, as reported to the August 29, 2001 Business Archives Colloquium meeting during the SAA’s 2001 Annual Meeting would separate data (at the bit-stream level), applications and a Universal Virtual Computer (UVC) to provide access to electronic documents hundreds of years after their creation.

 

Even if the emergence of electronic records has not yet changed the nature of recordness, their growing presence will continue to change in significant ways the manner in which records must be managed. As a practical matter, ER have also enormously changed the volume of documentation being produced and recorded that meet the test of recordness, and that must therefore be captured, controlled, preserved for future access and otherwise managed as records. This is true even if many such records are deemed to be of insufficient value to preserve for long periods of time or even much beyond their initial usage. Yet these are determinations that must be made as part of an ongoing appraisal and disposition management program in each organization. Because of the sheer volume of electronic records, we may also have to consider adopting tighter criteria in our appraisal decision making processes of new records, and even ‘re-appraisal’ of existing records, including archival records. The National Archives of Australia is tackling this issue today, out of necessity, despite some quite negative reactions to this possibility that have been posted on the professional discussion list of the Australian Society of Archivists.

 

Recordmaking vs Recordkeeping Systems

 

The reality today is that nearly all documentation, including records, is produced on computer-based systems of one kind or another. (There is also the very real possibility that some of these systems fail to produce records where they are needed to give evidence to the functions, business processes or transactions they support.) Yet, while the products of these systems may be recordworthy in the sense that they have generally accepted qualities of recordness, the systems themselves are not recordworthy. That is, they do not satisfy rigorous recordkeeping functional requirements. We may therefore characterize them as systems that are not trustworthy recordkeeping systems. What are trustworthy recordkeeping systems? Only those systems that have been designed with functional requirements generally accepted by the profession as meeting rigorous recordkeeping requirements. The Pittsburgh FRs (that spawned the IU project) and the US Department of Defense 5015.2 Records Management Applications (RMA) standard (endorsed by the Archivist of the US for use by all Federal Agencies) are examples of such FRs, as are the requirements developed in the University of British Columbia and the on-going InterPARES project and in separate evaluation exercises by the National Archives of Australia and, more recently, by the UK Public Records Office.

 

So what we have is a vast sea of digital systems, virtually all of which produce records and thus are recordmaking systems, and a handful or two among them that can legitimately be called recordkeeping systems. Indeed among the very largest of recordmaking systems that are not recordkeeping systems are the growingly popular ‘back room’ systems called enterprise resource planning (ERP) systems that typically manage all, or nearly all, of the financial and human resources transactions within an organization and sometimes among a group of organizations in a strategic alliance. The same can be said of the ‘front room’ customer interface management (CIM) systems and the more recent e-business systems that integrate front and back room operations. In short: we have a problem, Houston. We are producing an ever-increasing number of records in faster, bigger, recordmaking systems; but we are not managing these records in a trustworthy recordkeeping environment.

 

What is most interesting about the IU project is that its whole focus now is on capturing records produced by recordmaking systems into a trustworthy recordkeeping environment. The difference between a trustworthy recordkeeping system or RMA and a trustworthy recordkeeping environment is that the RMA refers to software whereas the latter embraces the whole range human, policy, procedural training and certainly technological infrastructure that is needed to ensure that functional requirements for sound recordkeeping are satisfied. To use a standards analogy, it is the difference between the 5015.2 and the AS 4390 or ISO 15489 standards.

 

There are basically only two ways to get the products of a recordmaking system into a trustworthy recordkeeping system. One is to port the records produced by such systems into a trustworthy RMA, such as those certified to be minimally compliant with 5015.2. Satisfaction of additional functional requirements will be necessary for organizations that are in regulated industries such as financial services, pharmaceuticals, food and nuclear power, all of which have their own recordkeeping requirements. This might be achieved through the use of well-designed application program interfaces (APIs) that provide the necessary links between the producing system and the RMA. The other approach is to do what is necessary to change the recordmaking systems in ways to make them become also trustworthy recordkeeping systems. Organizations may find that one approach is better for certain types of recordmaking systems and not for others. For example, it may be that highly unstructured records, such as produced in email and word processing systems, are more amenable to being ported into an RMA. At the same time, it may be feasible to make highly structured, transaction-based systems such as many financial and HR systems, including ERPs, become sound recordkeeping systems through embedding recordkeeping objects within their existing software. Some combination of these approaches may be the most practical solution for many organizations.

 

Participative Design of Recordkeeping Electronic Information Systems

 

The IU Phase II ER Project, in my opinion, has been a model of participative design similar to what we saw with the original Pittsburgh project. The Project Team has been very careful to involve all the key IU stakeholders in defining, designing and carrying out the project. The Project Director has engaged an active Advisory Committee (AC) and has generally taken its advice. Examples include the defining of the role of the AC and the timing of its meetings, what kind of communication vehicles would be used to facilitate the greatest remote interaction of the Project Team and AC between its meetings and the formulation of substantive project deliverables.

 

The AC meeting schedule, which is really a metaphor for serious AC input to the project, offers an example of how this approach was adopted and used.  Because of grant/budget limitations, it had been possible to plan only two AC meetings over the life of the whole Phase II project. The plan called for one meeting at the beginning and one meeting at the end of the project. The AC saw little value in following this plan. What purpose would a meeting at the end serve, when it would be too late to alter directions, if that was seen to be necessary by the AC? The AC therefore proposed a schedule of three meeting, recognizing that it would take additional funding to accomplish that – one at the beginning of the project to fully orient the AC to the project aims and planned methods and provide at least for the possibility of some very early feedback; a mid-term meeting to assist in evaluating any course changes that might be needed at that stage; and, if additional funding could be obtained at a later time, a third meeting at the end of the project for final testing and fine tuning of deliverables. The AC recommended that if further funding was not forthcoming, it would be better to drop the end-project meeting than a mid-course meeting. This approach was adopted and the second meeting was held in July 2001. This gave the Project Team the opportunity to consider AC reviews of substantive products well in time to have an impact on the outcome of the project.

 

The AC recommended the creation of a separate private website separate from the IU ER Project website for the purpose of facilitating between-meeting interactions of the Project Team and AC and to provide a vehicle for sharing papers and for creating a project archive. This was agreed by the Project Director and an eGroups website was established. It was used with good success until Yahoo bought eGroups. This resulted in a transition from eGroups to YahooGroups that required all members of the group to register as YahooGroups users. This, in turn, required the submission of more mandatory personal information than had been the case with eGroups and some members of the AC found it unacceptable. Consequently, not long before the last AC meeting, the new use of the YahooGroups project website was discontinued. Had it not been for the policy change with Yahoo, this approach would have worked very well. The alternative would be to place all working papers on the IU ER Project public website. This was the approach used by the Pittsburgh project including its own advisory group deliberations. While there was some criticism of the fact that the Pittsburgh papers were being published in draft form on the project website with typographical errors, the much more widely held view was that the professional public was most happy to be able to access project documentation while it was still hot off the press and not have to wait till the next conference to learn about the project’s progress. I recommend the same approach now for the IU project.

 

Other research projects, including some funded by NHPRC, do not have near the level of participation as the IU project has demonstrated already. One major NHPRC project was a year or more into its work before its advisory committee was invited to look at any of its products. It was neither provided an early opportunity to become oriented to the project or to have any influence on its important starting directions. Even when project team meetings were held in cities nearby the residences of its AC members, the members were not invited even to observe the meetings, let alone offer their views.

 

Another project’s advisory committee has never met due to lack of funds. It will be compelled to do its work, prepare its deliverables and ask for advisory committee inputs at the end of the project, very possibly without any group interactive meeting at all. Surely these cases are not what NHPRC intended when it encouraged the use of advisory committees. Professionals do not appreciate simply being on the letterhead without any substantive role. At least one advisory committee member of one project resigned from the committee in protest of such practices. A number of past and present project leaders have indicated concerns over micromanagement of their projects from above. They understand that higher-level managers have to exercise fiduciary trust in the management of grant money. However, some feel as though they are in straight jackets making it very difficult to adjust project directions to the realities of project environments. It is also evident that it is a subject that no one wants to vocalize for fear of worsening matters.

 

Speaking for myself, it is evident that NHPRC needs to review its fee structure for advisory committee members. Especially for consultants who are not on anyone’s payroll, but even more generally, there is little relationship between the fee structure and the time invested in research projects.  These comments are not intended, nor should they be interpreted as any kind of attack on NHPRC.  NHPRC has made enormous contributions to the identification and resolution of electronic records issues – perhaps more than any other single organization. If NHPRC has already commissioned an independent, anonymous survey of past NHPRC project managers, I believe that they will already know about both the very positive value of its grant work that I have described above, as well as some of the areas that need attention. If not, I believe that they would be well served in doing so.

 

Treatment of Functional Requirements

 

Thus far in Phase II, most of the work has been at a high level of business systems analysis and modeling. The main role for functional requirements (FR) has been in educating IT, audit and operational stakeholders involved in the project to what recordkeeping and its related functional requirements are all about. So far, beyond the findings reported in Phase I, only impressions have been gained about the appropriateness of Pittsburgh FRs to this kind of project. At least at this stage, it appears that the FRs will be much more useful in the design of new systems than in the adaptation of existing recordmaking systems. As I understand it from the Project Archivist’s paper, the initial idea of coupling the PeopleSoft ERP with a 5015.2 RMA was dropped at the suggestion of the IU director of PeopleSoft implementation.

 

The initial plan for Phase II was to undertake an RFP process to procure an RMA to link in with the recordmaking systems to be covered by the project. This would make it possible to implement the first of the two architectural options outlined above, porting records from a recordmaking system into an RMA. The RFP was issued and several bids were received and evaluated. However, in another untoward development, the University decided on the basis of the bids that budgetary limitations made such a procurement action impossible. Thus, both the PeopleSoft and RMA aspects as originally planned had to be abandoned.

 

With a less entrepreneurial Project Team, the project would likely have had to be terminate at that early stage with little completed research or development to share with the IT, archives and records management professional communities except for the contributions of the joint audit/archives audits. The audit work has been most beneficial in implanting the importance of sound recordkeeping to best practice on the part of auditors and good management on the part of the rest of the organization. This alone would have justified the project; however the project would have fallen very short of its original ambitious plan.

 

Largely because the Project Team saw an opportunity to do it another way and grasped at that chance while it was still there, life was breathed back into the project.  This is where it becomes important for grant agencies such as NHPRC to take a practical approach to research projects. It is now on a course that, while facing some important obstacles and issues, should produce some most valuable case material for the auditing, IT, archives and records management professional communities.

 

What has transpired, as I understand it, is that financial and human resources transaction-processing systems are being developed outside of the PeopleSoft environment as part of the workflow-management-based shared infrastructure system called Enterprise Development ENvironment or EDEN and the One-Start portal interface. The transactions produced in One-Start/EDEN will be front-ended into PeopleSoft. The concept is that the transaction records will be captured in the front end and those will become the ‘official records’. This is a big step in the right direction for getting the high-volume transaction records under recordkeeping control; but it leaves yet to be resolved the question of the disposition of the PeopleSoft records. It would be shaky ground to attempt to define the documentation produced by PeopleSoft as non-record in nature. Addressing this issue will be an important challenge for the next stages of the project.

 

Meta-Data and Description

 

The Phase II project is not yet far enough along to settle on what its approach will be in deciding on metadata and description. The Project Team has been examining the Business Acceptable Communications and Australian approaches to metadata, as well as to descriptive standards. The more the project moves from design to development, the more important it will become to address metadata.

 

Build vs. Buy (now also vs. Rent)

 

My 1996 review of Phase I of the IU ER Project outlined several pros and cons to buying shrink-wrapped software rather than developing custom software within the organization, the so called buy vs. build (or make) options. Some of these are spelled out in my 1996 review of this project, so I won’t repeat all of them here except to say that the history of home made custom software systems has many unpleasant examples. Documentation is often poorly written, very incomplete or non-existent. Organizations become so dependent upon the one or two individuals most familiar with the system, and in complicated systems there may not be anyone who knows the ‘whole’ system, that they may become captives to a few technical specialists. Ultimately those people move on and the organization may find itself in big trouble. Moreover, most large organizations will not want to place today’s software engineering tasks dealing with mission-critical systems using advanced programming techniques in the hands of amateurs. Depending on the circumstances, it can also be naïve to assume that developing and supporting complex software in house can be done at great savings to the organization. Software developers invest millions of dollars in their products. Most organizations will have to go through similar processes to achieve anywhere near equal quality and results. The difference is that the vendor has a world’s worth of potential clients over which to spread development costs and ultimately to make a good return on a well-done product. The in-house developer has only one organization against which to spread its costs – itself.

 

We could now add to the Build vs Buy options the Rent option. The application service provider (ASP) model has come into its own since Phase I. While the ASP approach is used by some for outsourcing the storage of paper-based archives, much less is known about that approach for electronic records solutions. Many professionals are reluctant to turn over their electronic files to an outside vendor for reasons of security and to ensure better exercise of procedures within organizational policy parameters. There is also the issue of software selections by the ASP, whether their choices are in agreement with the client, what control the client has over future changes in software and standards that may have an impact on the future access to critical organizational electronic records. If these hurdles can be overcome, it may be possible to accrue some of the benefits of buying vs. making software in the ASP service areas. This could, indeed make a good approach for limited aspects of recordkeeping for business continuity planning reasons if reconstitution of vital electronic records should become a necessity.

 

Phase II began with the proposition that any software that would be used for the records management aspect of the project would be a vendor supplied COTS (commercial off-the-shelf) product, and very wisely so in my opinion.

 

Because of decisions that were not within the control of the Project Team, IU elected not to go the COTS route because of budget constraints and, thus, the software needed for the electronic records interface will have to be home grown. A much better solution would be to procure an effective RMA with a strong API kit that can reasonably readily be used by in-house staff to connect up to the recordmaking system. This is also not a budget-neutral solution.

 

Reporting of Research Results to the Professional Community

 

The Pittsburgh FR Project led the way in webinizing its project reporting. As noted in my 1996 review of this project, IU has followed in the same vein. Similarly, the Project Director has been a fluent writer on the subject and regularly speaks at professional conferences on the status of the project. The Project Archivist is supporting this model, and very good papers have been drafted. I recommend that more of the work in progress be placed on the project’s public website, even in draft forms. What better way can we get the attention of software developers and give early warnings and tips to the practitioner world that is sorely in need of even trial information.

 

Project Sustainability

 

Project sustainability is always an issue whenever any of the project staff are funded by grant money that will ultimately disappear. In my earlier review of this subject, I recommended that the project team not rely solely upon the IU IT staff for technical support, but to buy or build technical expertise within the archives part of the Project Team. This has worked out very well with the Project Archivist who has become very knowledgeable of portal technology that is being used in this project in a very innovative manner that goes beyond most portal implementations. Similarly, the project team has become versatile in the methodology of business systems analysis, including the Project Director. As part of that methodology, enterprise modeling is a key element of any successful enterprise system design and implementation. This has become a central part of the IU ER project and one that hopefully will be the subject of full project reporting during the course of the project. That alone will constitute a very useful product for other archives and records management professionals. Having said that, it is important that the University does not lose the valuable human capital that has been developed in this project and take appropriate steps to either make permanent the temporary staff associated with this project or replace them with permanent staff in a timely enough fashion to allow their proper training.

 

Other Issues

 

Reading over the project documentation and with only very limited recent discussions with Project Team members, I offer some additional issues that may have already been resolved. If not, the Project Director may wish to take them into consideration for the next stage of project work.

 

Should recordkeeping requirements be integral to the business process models of the processes that produce the records or should recordkeeping be regarded as a separate process of its own that other processes interact with?

 

This topic has been the subject of considerable debate in recent years. My recommendation is to keep recordkeeping aspects as intrinsic to the process that produces the records as can feasibly be achieved. I realize that this is not always possible, but believe it is the wise way to go if, at the same time, the integrity of records can be maintained. While that is not always easy, it is not often an insurmountable problem and should not be used as an argument against this approach unless there are intrinsic problems, particularly if there is a healthy level of system and data redundancy built into the system. We are already beginning to see the rise of what will someday be ubiquitous electronic recordkeeping. There are many more RMAs today than there were in 1997 with serious recordkeeping functionality as well as, in some cases, workflow management, knowledge management support and rudimentary automatic document classification. There will be many, many more in even a few years. We are also witnessing the advent of software developers using the OEM approach to RMA software, whereby developers of recordmaking systems that are not recordkeeping systems are licensing the code of RMA producers and integrating into their recordmaking systems. Ubiquitous recordkeeping will hasten the day when recordkeeping is tightly linked to business processes and, through them, to principal organizational aims. Isn’t that what we want to see? Of course, where the main business of the mother organization is recordkeeping, such as national and state/provincial archives, recordkeeping processes do constitute a separate set of business processes once records are received by the organization.

 

Some types of records lend themselves well to self-recording and scheduling approaches, obviously based on criteria built into the system by knowledgeable professionals. Systems managing highly structured information, such as ERPs and other transaction-based systems tend to fall in this category. Such systems, that have the properties of:

·        highly structured and more coherent records sets,

·        more tightly controlled operating environments,

·        few access rights and low access levels,

 

are more amenable to macro-appraisal at the business process or transaction-class levels and more appropriate for automated or computer-assisted records disposition management.

 

Email systems, on the other hand may be likened to paper. Their products may be related to any business process so are lacking in coherence in records sets, and while usually they are highly controlled in terms of system administration, they are less controlled in the sense that many more people make use of the system and have access to it. Such systems are much more difficult to macro-appraisal and automated disposition management. In such cases, the records have to be placed in the appropriate ‘file folder’ either by action of the creator or by using automatic classification tools; but the latter are still in their infancy and not well tested. Evaluation of automatic classification products for recordkeeping purposes would make an excellent candidate for a research grant. If NARA or others are doing such research, it would be most beneficial for the results to be published to the ARM community.

 

A lesson learned in this project was that the Project Team would have to give in to IT/IM on what kind of modeling language would be used, in this case Unified Modeling Language (UML). Will similar lessons be learned in the adoption of metadata standards? Are we going to be able to persuade the IT side of the house to adapt specialized archives description standards and metadata? What can we learn from this project about negotiating metadata and other standards?

 

Date-driven vs Event-driven retention schedules

 

Some retention schedules are driven by dates (e.g., seven years from record creation.) Others are driven by events (5 years following completion of a project). Date-driven schedules are much easier to manage and automate. However, if it is any bell weather, during NARA’s Electronic Records Working Group, the vast percentage of the proposals for records schedules were event driven. The Project Team should consider how much of a problem, if any, this poses for the One-Start/EDEN approach.

 

Relationship of independent transaction-based applications systems under the OneStart/EDEN system and the ERP (PeopleSoft).

 

As currently planned, records from the former will be captured but not from the latter, on the grounds that the latter being declared as “not the official record.”  Whether this is a jurisdictional or technological issue, or a combination thereof is not clear. This is an issue that should be revisited. If the PeopleSoft transactions can be carried out without producing recorded documentation like that being designed into OneStart/EDEN, it is one thing. If PeopleSoft is actually recording transactions, that it quite another matter and IU faces the situation in which both incidences of the same record can subjected to different disposition actions. Since any recorded PeopleSoft transaction documents would be subject to courtroom discovery judgments, it would be important for their disposition to be harmonized with the so-called ‘official record’.  This would seem to be a weak link in the information and records management strategy for IU if not addressed.

 

Whither goes Pittsburgh?

 

Phase I did broadly verify the Pittsburgh work with some adjustments to fit in to the IU environment. It isn’t clear to what extent the Pittsburgh FRs have been a particular focus of the Phase II project as, so far, they have not been directly addressed. It will be very useful for this project to address this subject among future deliverables. This is important because there is little by way of empirical data on the adequacy or of the Pittsburgh FRs for the design of real-life systems, or whether they may constitute an overkill of what is needed. During that project, we discussed the issue of whether all Pittsburgh FRs were equal in importance or if some should be weighted more heavily than others, but no conclusion was reached on this subject. While the IU project has not slavishly adopted the Pittsburgh FRs, and has moved on from that being a central focus of Phase I, we all have much we can learn from the IU and Philadelphia City projects in working with the Pittsburgh FRs and metadata schema.

 

Roles definition in OneStart/EDEN

 

Current user roles for OneStart include Student, Faculty, Staff (Admin). Other roles worthy of consideration are might be Alumni and Public Clients. As the OneStart portal is presently transaction oriented, roles are defined in terms of what forms-enabled services are suggested by different roles. Extension to Alumni and Public Client would therefore be contingent upon delineation of potential roles for these classes of users, e.g.: Alumni (updating of contact information; submission of news for the Alumni newsletter; submission of annual financial gifts by credit card); Public Client (request for information on university offerings in continuing education courses; requests for research access to archival resources, requests for rental of conference or other facilities).

 

Roles rules will have to address additional issues:

·        What should be done when an approval authority is absent or when someone else is designated to act for the absent authority? Approval rules will have to establish time limiters that, when reached, cause the request to be diverted to another position or returned to sender with instructions. Defining authorities as positions rather than individual names might address this problem, such that the Inbox for a particular position authorized to approve/disapprove a given set of transactions. Such an Inbox could be directed to the desktop of whoever was acting in the position at any time.

·        How will future records researchers or courts determine who was in charge on any given day? As email is typically used for managers to announce their travel plans and acting assignments during their absence, this important accountability information is getting lost unless special provisions are made to track it. Somewhere in the system, records should be maintained of acting assignments.

 

Lessons for Future Projects

 

The lessons I continue to learn from the Indiana ER Project are validations of, with a few additions to, the lessons outlined in the 1996 review of this project (see fn 1):

 

1) Design the deliberative process by which recordkeeping requirements will be incorporated as carefully as you would the system itself.

2) Get budget analyst assistance up front, from within your own group or externally. Enlist assistance from the offices of the CFO and CIO (and, I would add, general counsel, auditor and facility manager) to ensure that your project fits into current year, new year, medium-term and long-term planning and budgeting exercises to gain interest and avoid funding gaps.

3) Work toward full-time internal IM and IT skills within ARM unit.

4) Understand and weigh the information architecture options for dealing with metadata and description issues. I would now add: make the best use of business systems analysis and modeling tools to understand the relationships among business aims, areas, processes and transactions and how recordkeeping is best related and/or embedded in them.

5) Don't leave the outcome of the buy-vs-build (and now vs-rent) options to circumstance, happenstance or arcane procurement regulations.

6) Make the best use of the technology to share project results as they emerge. The World Wide Web is ideal. And share the real results, warts and all. To this lesson I would now add: Get a trustworthy recordkeeping system (e.g., what I would call an “EDMS+” such as those certified under the US 5015.2 Records Management Applications standard that we didn’t have in 1996). And, furthermore: work toward enterprise-wide recordkeeping solutions, not isolated unit solutions or partial recordkeeping solutions.

7) Don't deliberate. Implement. Like these guys are!

 

Conclusion

 

The IU ER Project has matured considerably since its first phase and is now developing excellent methodologies and designs that others will be of considerable benefit to others. It is a project that NHPRC can rightfully include in its lists of outstanding projects that are cutting into new territory and contributing to a broader understanding of electronic records throughout the archival community. It also validates the importance of what NHPRC is doing and the priority the Commission has given to electronic records research. The IU Project Team should press on with its enterprise approach and seek to respond to the above issues within its limited means. We should all learn from the experience of IU and others who are now actively involved in implementation projects, such the National Archives of Canada, Covington & Burling and the United Nations High Commissioner for Refugees (UNHCR), and do what it takes to encourage further enterprise implementations of electronic records solutions.