return to index
4 Implementation Issues for ESRS (System-Specific Concerns)
The implementation of the student records system at each university will reflect the environment for which it was designed. The size, structure, requirements and resources of the university will have determined the system implementation. The history of the system development, when the system was implemented and upgraded, will also have influenced the type of system. Some universities may have small and fairly simple systems to meet their needs. More and more universities are opting to implement integrated software packages, such as PeopleSoft. Most universities have developed some kind of Internet-based interface to the system or to information contained in the system. 23 For FERPA compliance, these interfaces must insure that access is limited to information that authorized users are allowed to see. By now, it is unlikely that a university has not developed an electronic student records system of some kind, however simple. This means that archivists and records managers will be participating in the management of an existing system, and so must understand the implementation at their university. Section 4.1 discusses some of the options that a university must address for a student records system implementation.
University archivists and records managers must understand the specific implementation of the student records system at their university to be able to insure that the records are properly scheduled and to enable the development of the preservation strategy.
The degree audit matches the courses taken and credits earned to the degree requirements, generally those requirements that were in effect when the student began the program. The requirements evolve over time and must be tracked to produce the correct result for each student. Licensing for the Securities Exchange Commission as well as the legal and medical fields, professional certification, State Department clearances, other employer requirements, and patent renewal requests may require more context for and content of a students academic record than the traditional transcript provides. The degree audit may provide the needed verification. The student records system may include degree audit as a function or the function may be handled outside of the student records system. A manual process that is completed upon request may support this function. A version of the Personal Record Card may be used to support the manual function. Degree audit is an important function, and the Archives needs to work with the registrar to make sure that long-term requirements can be met and what the role of the archives will be.
At Cornell, for example, the degree audit function is not part of the student records system and is handled individually by each college within the university. Not all of the colleges use an automated process. When PeopleSoft is implemented for student records, the degree audit function will be included as part of the new integrated system. Appendix K provides an example of a degree audit program at Cornell in the College of Arts and Sciences. Until PeopleSoft is fully implemented, the Cornell Archives should follow the development of the College of Arts and Sciences project to determine which colleges will participate, to identify the degree audit process for colleges that will not participate, and to consider the impact of the student records module when it is implemented on degree audit.
Whether the function is part of the system or handled separately, the university must consider how the function will be supported over time. Archivists and records managers should be involved in determining the long-term recordkeeping requirements.
System design and implementation
System design and implementation
Since the majority of universities predate the active use of computers for recordkeeping, the processes needed by the university may never have been completely analyzed, automated, or synchronized for computing. Modules were probably developed as needed and not as part of a cohesive plan. The demand to provide uninterrupted support for the entire academic year may make system analysis difficult to incorporate in the university's workplan. Sometimes universities must force themselves to address more long-term issues to avoid problems that could interrupt university computing.
Many universities have initiated university-wide system implementation projects. Packages such as PeopleSoft are increasingly popular (see PeopleSoft Web sites listed in Appendix D, Relevant Sources). The M-Pathways project at the University of Michigan is a good example of such a large system redesign and implementation project. The project's goal is to replace all of the core systems at the university between 1995 and 2001, including the student records system. PeopleSoft is at the heart of the implementation. There is a lot of documentation on the Michigan Web sites about the project (see Appendix D). The project initiated by the Bentley Library to look at the archival impact on student records may be of particular interest as more and more universities have selected PeopleSoft but few have conducted the kind of analysis that Michigan has. The results of the Bentley M-Pathways project are due in December 2000.
Archivists and records managers should monitor and participate in projects that affect access to or the preservation of student records. The results of projects like Indiana and Michigan, and InterPARES' student record case studies, should provide useful examples for other universities.
With the definition of SPEEDE/ExPRESS, AACRAO has provided a mechanism for the secure delivery of transcripts upon request, as well as automatic tracking of the requests and delivery to provide a service and to protect against fraudulent transcripts. Many universities are implementing SPEEDE/ExPRESS to handle transcript requests and meet recordkeeping requirements for providing transcripts. Cornell, for example, will be implementing SPEEDE/ExPRESS. If universities implement electronic transcripts using SPEEDE/ExPRESS, the entire process will be fully documented. Historical transcripts could be delivered using the same process, if the historical records are accessible to the system. Appendix L provides more information on SPEEDE/ExPRESS.
Archivists and records managers should monitor AACRAO's SPEEDE/ExPRESS developments and consider the recordkeeping implications of future developments.
Many universities are using data warehouses to support distributed university computing and to provide access to legacy systems. The University of Arizona is acknowledged as the leader in this kind of implementation, and their experience would be a useful example for other universities. Cornell recently implemented a series of data marts, including the Student Records Data Mart, to provide faculty and administrators with access to key systems. 24
Data warehouses have been of interest to archivists. Articles by Richard Kesner and Piers Cain address recordkeeping issues that data warehouses raise. For student records, there are several considerations. Data warehouses should only provide a copy of the records, not direct access to the records. Therefore, as long as access to records complies with requirements, and preservation strategies are established for the systems to which the data warehouse provides access, the implementation of data warehouses need not affect recordkeeping. It can be difficult to implement access restrictions within a data warehouse. This is particularly important for student records and FERPA compliance. The auditors at Cornell completed an audit of the Accounting data mart. The Archives should review the results and consider how the approach could be used for a cooperative audit of the Student Records Data Mart to include recordkeeping considerations.
Data warehouses should be audited and analyzed to insure that access to records is adequately controlled. This should be a cooperative process within the university. The results of evaluations should be documented and shared.
The discussion of FERPA in AACRAO's Student Records Management includes the admonition that "with electronic records, your level of responsibility is far higher than your level of control." 25 Since 1989 when that statement was written, and with the implementation of the Internet, computer security has become very sophisticated. To insure that records created and maintained in an electronic environment are adequately protected, universities must establish a comprehensive security plan that protects both the online and physical assets of the electronic systems. 26 The archives should be involved in developing and maintaining a comprehensive security plan that insures that stored records are well-managed and secure. The Cornell Archives, for example, has good contacts with information technologies staff throughout the University to support such an initiative.
Secure access is particularly important for student records to insure that universities comply with FERPA regulations. AACRAOs Academic Record and Transcript Guide contains a whole section on security.
4.2 Cornell Example
Background on Cornell's ESRS
Historical Background: 1960s - 1990s
Historical Background: 1960s - 1990s
In the 1960s, Cornell used punchcard technology for student records, using a 1401 Autocoder emulator to run on an IBM 360 mainframe computer. To register, students placed their cards behind the card for the classes they had selected. The Autocoder then produced a class list. Around 1980, Cornell contracted with SCT, a contractor that specialized in university computing projects, to build the Student Records and Registration System (SRRS). In spite of a significant investment in the project, the SRRS system was not successfully implemented. As a stopgap measure for SRRS, CIT developed a batch SRRS system that was unpopular because of the high expectations for full SRRS functionality. The registrar designed the Student Information System (SIS) to replace SRRS, but some processes such as grading and bursar records run in the older, batch SRRS system. SIS uses procedural SAS on an underlying Adabase database that runs in the background. Student records were converted to SIS in 1983. The conversion required an audit of earlier records. SIS records from 1988-on are in the Student Records Data Mart discussed below. CIT maintains the SRRS/SIS system on the Cornell mainframe (CornellC).
There are 5,000 new students each year, with approximately 25,000 class enrollments per semester plus grade changes. All of the SIS data is currently available on the mainframe. The PeopleSoft modules will contain 3-4 times the amount of data as SIS, so data may need to come off-line when it is implemented.
Around 1990, Cornell initiated the Mandarin project to create tools to build distributed applications to support faculty and students. In 1994, the project shifted from a largely Cornell-based project to a consortium of twenty-four universities. The consortium produced a toolkit and a suite of infrastructure services that could be purchased by universities. The Mandarin project led to the Bear Access infrastructure at Cornell, which supports Internet access and distributed university computing. Bear Access supports software updates using version control and provides security through Kerberos. Legacy systems can be wrapped in an appealing interface. Bear Access was a precursor to Web sites and portals, with features like downloadable software, marking favorite locations, and easy remote access. Project SALSA (Service And Licensed Software Acquisition), a Mandarin implementation in Java, provides software delivery architecture.
Project 2000 and PeopleSoft
Project 2000 and PeopleSoft
Around 1995, Cornell began Project 2000, a university-wide system implementation to incorporate all of the University's core systems. Cornell selected Informix over Oracle and PeopleSoft over other packages. The HR module in PeopleSoft runs on Informix, and Cornell has a site license for Informix. Major delays were announced in the spring of 1998, and the project finally stalled after implementing the HR module.
Cornell also selected Brio over BusinessObjects as a query tool, primarily because 40% of the University, in particular accounting, use Macintosh platforms. Brio has Macintosh interfaces, but there may be problems for Mac users. 27 Brio will use a server-side process for ad hoc queries. It is difficult to implement and maintain client-side querying. The accounting system is in Oracle. The middleware will be on the server, not distributed, because it is also hard to implement Oracle applications on the client-side.
The PeopleSoft student records module will contain data from fall 1993 forward. The University Registrar's Office is planning towards a three-to-five year implementation of the PeopleSoft Student Records modules. For now, the student records are still online in the SRRS/SIS system on the mainframe, which are accessed through Just the Facts and the new Student Records Data Mart discussed below.
In the lull following the PeopleSoft problems, a number of projects have been planned to look at university work flows and data administration and to map data elements and definitions. Cornell has not had a central data model that identifies and exploits data and relationships. These projects should make future implementations of university modules easier.
Access: Just the Facts and Student Records Data Mart
Access: Just the Facts and Student Records Data Mart
The core of the current student records system, behind the online student access system Just the Facts and the new Student Records Data Mart (SRDM) for faculty and administrators, is the old SRRS/SIS system. Just the Facts is a Bear Access application. Neither Just the Facts nor the SRDM can replace a fully functioning student records module. The student records system needs to be further developed to meet student, faculty and administration computing needs and expectations. For example, the SRDM cannot provide effective dating of reports, a point-in-time history, so it cannot support a degree audit process.
CIT designed the SRDM. It was completed in May/June 2000. The SRDM is supported by an Informix database consisting of 5 tables: student, class, enrollment, term, and term history. The SRDM provides two or three designated people in each college with views of the data. BRIO will allow designated people to do ad hoc views of data. Once a week, to populate SRDM, information on current students is pulled from SIS. The official record is on the mainframe. The data is partitioned by year. Ideally, the SRDM would handle all users and be refreshed every night. Since the SRDM cannot support comparisons, a full refresh of SRDM content is required every time
Students can pre-enroll electronically using Just the Facts. The registrar checks the enrollment. Adding and dropping courses is a manual process. College registrars access SIS by Telnet; updates then become available in the SRDM in the next refresh. Just the Facts provides students with direct access to information from SIS. The system could not support the batch queries that colleges require through direct access to SIS, but it can accommodate individual requests by students.
There are data marts for student records, accounting, and Human Resources. Data marts are also being built for Student Financial systems (Bursar and Financial Aid records), Admissions, and the Graduate School. The Graduate School has a shadow SIS system because SIS only allows for tracking three committee members and they need up to eight.
In accordance with Cornells approach to complying with FERPA, there is no central querying facility. In contrast, the University of Arizona provides central access to student records. Arizona carefully controls and monitors use, punishing those who access records for unauthorized purposes in violation of FERPA. Cornell uses a data mart model, while Arizona uses a data warehouse model.
Records Management and Archival Records
Records Management and Archival Records
The Cornell University Archives has hard copy records for the period through 1981 when the SRRS/SIS system was implemented. There is an implemented backup and maintenance system. Just the Facts provides access data back to 1988 and it should be possible to provide access to the data for 1981-1987 in a similar way, if desired. Apart from having to check information on the hard copies in the Archives because of unreadable microfilm, the University Registrar is able to provide students with any transcript upon request.
The University Registrar's Office confirmed that there is microfilm covering: 28
The University Archives actively participated in developing Policy 4.7- Retention of University Records. Appendix J contains the results of a comparison of AACRAO and Cornell retention periods. The difficulty in comparing the retention periods led to one of the recommendations in the main report.
Issues raised during meetings with Cornell staff
Documenting academic context
Documenting academic context
The University Registrar fulfills most transcript requests. Some special requests, such as licenses for SEC, legal, medical, and biomedical fields; State Department clearances; and the requirements of some other employers, may require degree audit information, course descriptions, and syllabi content and other contextual information. Though the value of course documentation is widely recognized, course documentation is not centralized and is not consistently captured. See section 5.4 of the main Electronic Student Records Systems project report for a discussion of course documentation considerations.
The Academic Technology Center at Cornell actively supports faculty in the use of course Web sites. They host Web sites for faculty members, provide training in support for building Web sites, are developing tools and templates to make building Web sites easier, and maintain CourseInfo, a software package that supports web-based educational applications. These services were not developed to support the long-term capture of information, but with the implementation of these technologies, course Web sites and CourseInfo may contain the best or only version of course documentation. For example, course descriptions and syllabi may only be approved for new courses and major changes, which means that information on file may not reflect current courses.
The PeopleSoft module would allow for tracking changes in courses over time and tracking different instances of the same course. For example, the introductory Economics classes are taught very differently and would be documented differently as one uses Web-based instruction and the other uses traditional methods. The computer science introductory class changes regularly to reflect current technology.
The PeopleSoft project used the course catalog as a prototype. CUinfo has the historical electronic catalog content from 1996, but only the current year is online. This may be a source of some course documentation.
The provision of replacement diplomas is an aspect of academic documentation that may be overlooked. Cornell keeps templates for diplomas registered at Jostens. 29 The Registrar can print a replacement diploma for any year but no longer on vellum.
As noted, SIS/SRRS is maintained on the universitys mainframe, CornellC. There are well-defined and implemented backup and recovery procedures for the systems on CornellC. For SIS/SRRS there are two parts to the backup: one for the system software Adabase and one for operating system MVS. The Adabase backup uses a journal process that supports point-in-time recovery for four to six weeks into the past. Adabase utilities provide database backup, with overlapping backups. MVS utilities perform disk image backup. There are weekly, monthly, and yearly backups. The year-end backups are retained for seven years. The backups are copied to an off-site location for disaster recovery.
Human error creates biggest losses; for example, unwanted deletions by a database administrator. Some of the old year-end backup files are on 3420, round 9 track magnetic tapes. 3480 is becoming obsolete, so the computer center is moving to 3490. Robots read bar codes, and 3480 does not have bar codes.
Cornell should consider doing a system audit of SIS/SRRS and a COM (Computer Output Microfilm) version of the data, especially for 1981-1987, which are not accessed by the SRDM.
All SIS/SRRS data is live on CornellC. The Registrars Office is looking at storage formats for student records. They would prefer CD backup to COM because they want the content to be easily searchable. They are also looking at digital imaging. If the PeopleSoft student records module implementation proceeds, all of the historical data will not be converted to the new system. Since Cornell has some of the leading experts on digital imaging and preservation, the University Archives and the Registrar should work together on identifying the optimal storage formats for short and long-term access and preservation.
Recently, auditors and archivists have been discovering the similarities of their goals and priorities. There are differences, such as auditors need to insure that current business processes are secure and effective and archivists needs to insure long-term access to evidence of business processes, but both focus on aspects of effective recordkeeping and need to be aware of relevant laws, regulations, policies and requirements. The auditors at Cornell and the University Archives have been working more closely together. The PeopleSoft implementation would have provided opportunities for joint projects. Opportunities for cooperation should be explored more broadly to take advantage of the complimentary skills of each group.
There is no comprehensive survey of the status of student records systems, and as soon as such as survey was conducted it would be out of date. It is clear that most universities are actively using the Internet, both internally and externally, given the wide use of Web sites, listservs, and other Internet-based applications. PeopleSoft and other vendors have a growing list of higher education clients. Cornells situation seems to be a common one for student records systems at universities. In fact, their experiences with SRRS/SIS and PeopleSoft are all too common. For example, in the Federal Government, the Bureau of the Census, the first agency to apply computer technology in 1890, continues to implement some of the newest technologies as well as being burdened with a large number of legacy systems and obsolete technology. Early adoption in computing does not make development less complicated; it often makes it more complicated. Universities in general have led the way in the majority of computing developments and, in fewer instances, implementation. Wide use of e-mail long before industry and government is a good example of early development and implementation.
While it is not feasible to have a complete survey of universities, the more universities share their experiences and work cooperatively towards preservation solutions, the easier the problems will be to solve.