Yale's administrative computing systems have for years run on IBM mainframes under VM and/or MVS operating systems. Since the early '80s, most database systems were developed using Information Builders International's Focus, a hierarchical software product in common use at that time. Applications were generally developed in-house by a core group of staff who wrote the code required to support the business applications of the University. Yale's General Ledger, Payroll, Utilities and Student systems were all developed and are maintained in this environment.
In the last two years Administrative Systems reviewed administrative practices and consequently adopted a different engineering model to deal with the new requirements. First, it signed a campus-wide license to use Oracle's relational database system. Yale recognized Oracle as a leader in database technology and saw it as an engine capable of helping the University exploit its interest in adopting client server computing technologies for a new generation of administrative systems. Next, Yale elected to adopt the IBM RS6000 and its AIX operating system to launch new applications. It saw the two as natural compliments to Oracle, as well as lower cost solutions to its older mainframe environments. Finally, Administrative Systems realized the need to implement new solutions quickly, and saw, with the availability of a richer set of vendor supplied choices, the opportunity to buy off-the-shelf applications rather than to code such new systems from scratch.
Nowhere else can one see this strategy so fully deployed as in the area of student systems. In the Fall of 1994, Yale's Business Management Board reviewed and endorsed a plan to re-engineer the administration of services. The plan proposed an overhaul to the University's financial aid, loan, admissions, billing and collection processes. The goals of this plan were to improve regulatory compliance, automate certain processing activities, improve management information flow, enhance the management of grant and scholarship funds and improve the communication between Yale applicants and students and various offices supporting student related activities.
To achieve the plan, the Business Management Board created a new department, Student Financial and Administrative Services. The organization is comprised of the student records office, student accounts receivables (previously the Bursar's Office), University Financial Aid, and student collections. The new SFAS Director, Ernst Huff, came to his new position by way of California State University where he was Assistant Vice-President for Enrollment Services. SFAS along with other offices like Undergraduate Admissions, Undergraduate Financial Aid, the Graduate School and other school specific admissions and financial aid officers, are working to improve student services at Yale.
Administrative Systems provided technological leadership and support for the new systems, enabling SFAS and other offices to offer improved service. Administrative Systems along with the student systems users evaluated available system solutions. They performed a "build versus buy analysis," surveyed the marketplace including peer institutions, interviewed potential vendors and finally selected Scientific Computing Technology's (SCT) Banner software.
Banner is widely used throughout higher education; in part or in whole it is employed by hundreds of institutions. Banner uses the Oracle database and runs on a variety of platforms. Conforming to Administrative Systems interests in promoting lower cost solutions, Yale installed Banner on RS6000's running IBM's version of Unix, AIX. When Yale began its discussions with SCT, Banner only ran in character mode via a simple telnet to a host RS6000. As part of its upgrade strategy, SCT revealed a plan to release a client-server, graphical user interface (GUI) version of Banner. The new version would allow administrators to access a system which presented data via dialog boxes, pull-down menus, and other "point and click" desktop devices familiar to Macintosh and PC Windows users. Yale's implementation used both the character-based version and the graphical version of the software. Yale began using Banner as part of the 1996 Undergraduate Financial Aid cycle. Later in the year, it added student records onto the system. Both these activities use the older, character-based version of the software, Banner 2.0.1.
A significant portion of the implementation is the integration of data from Yale's older mainframe systems into Banner. The accommodation is planned by way of intricate software bridges that send and receive data to and from various legacy, student information databases maintained by Undergraduate Admissions, the Student Records Office, Medicine, Law, SOM, the Graduate School and other schools on campus. These Oracle-based bridges perform tests to insure the data being brought into Banner is correct, and then either reject or accept the data depending on the state of the information. Data accepted into the system populates Banner tables while rejected data is held for later review and potential correction.
Data being exported from Banner has similarly rigorous tests applied. Once the data is identified, copied from the database and reformatted, the information is sent to older systems like the Bursar System to be used to calculate student bills. Eventually, when the Banner's Students Accounts Receivable module is in use, such bridges like the one used to link student records information with billing data will no longer be required; all student record and billing will coexist in Banner.
Student accounts receivables, like the use of Banner for Undergraduate Admissions activity, is expected to take place using the graphical version of Banner. As you read this piece, SCT will have completed the initial install of the GUI version of Banner, 2.1.5, here at Yale, and SFAS along with Administrative Systems and other interested Banner users will be investigating the use of 2.1.5 in preparation for a summertime conversion. Version 2.1.5 makes use of high-end desktop computers, Microsoft NT file servers and the RS6000 hosts as part of its client-server architecture. All three are tied together using Yale's high speed Ethernet network. The host contains the database, the server provides views or forms to the desktop system, and the Macintosh and Intel-based desktop computers interpret the forms and format the data retrieved from the host into a user-familiar view of the information. The forms that are available and the data the user is able to view or modify depend on the security access granted.
The implementation of 2.1.5 will require upgrades to many administrative office desktop machines and communication methods. Ethernet networks are the preferred method of connecting to the servers and hosts involved in using 2.1.5, although Appletalk clients, running at slower speeds, are expected to perform satisfactorily. Desktop systems will need to be Macintoshes with PowerPC chips or Pentium driven IBM compatibles. All users will need 16 megabytes of RAM and a significant amount of free disk space to make use of Banner in its GUI form. Mac OS 7.5 or Windows for Workgroups 3.11 are the operating systems required on the respective platforms.
As administrative offices change and the implementation of Banner progresses, Yale students should see progress not only in the services they receive, but also in the delivery of important information. Bulldog Access will be the primary tool used to convey information to students. Bulldog Access is a popular information system which originated at Cornell and is now supported and enhanced by a consortium of universities that includes Yale. Bulldog Access has been in use here for over a year (see the March 1995 issue of Omnibus) and has recently been enhanced to allow students to review the status of their loans and bursar bills on-line. It is not only student financial and administrative systems that are undergoing change, but the systems students use such as Bulldog Access that will continue to develop and improve as Yale gains a greater capacity to deliver information in easier, though highly secure, ways.
The role of Administrative Systems (AS) staff has changed along with the new systems they support and implement. Formerly, AS staff designed a system to user specifications, wrote the code, tested the programs and maintained the software once the system was in production. Enhancements and upgrades were requested by the user, reviewed by AS for cost and delivery schedule, and then pursued according to feasibility. These roles continue to apply to the legacy portions of student systems, but not with regard to Banner.
The decision to buy a product like Banner casts AS staff in the roles of integrators rather than developers. To implement Banner to best meet the needs of their administrative clients, AS staff must understand the user requirements and inner workings of the technical aspects of the software. They must transition to the new operating environment and augment their existing legacy systems skill set with those required of Unix, Oracle and Banner. And, where Banner cannot entirely satisfy the needs of the University, AS staff will be called upon to complement Banner with their own development efforts, using their knowledge and experience in the new environment to assist in making the project a success.
Chris Kielt (christopher.kielt@yale.edu) is Associate Director of Administrative Systems C&IS.
Back to March 1996