Moving Toward a Campus-Wide Information System: Leveraging the Existing Investment in Information Technology Copyright 1993 CAUSE. From _CAUSE/EFFECT_ Volume 16, Number 4, Winter 1993. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: jrudy@CAUSE.colorado.edu MOVING TOWARD A CAMPUS-WIDE INFORMATION SYSTEM: LEVERAGING THE EXISTING INVESTMENT IN INFORMATION TECHNOLOGY by Alan Hargrave ABSTRACT: Baylor University is committed to providing faculty, staff, and students easy access to the information they want and need--whether scholarly, general-interest, or administrative/specialized--through a campus-wide information system. Their CWIS approach, based on leveraging existing resources, is built on several key principles that have facilitated the development to date. Just what is a campus-wide information system (CWIS)? Ideally it is all things to all people. Any time one needs information ranging from today's news or weather to the class list for next semester, the CWIS should be the first place consulted. Technology has provided an exceptional opportunity to deliver information directly to faculty, staff, and students. The problem with many technology solutions today is that much of the information these users desire is not directly available to them. For example, it is not unreasonable for a student to want to view a current copy of his or her transcript. However, on too many campuses it is still the exception rather than the rule that this is directly available in any form without a trip to the academic records office. This is true even though the transcript is probably maintained in machine-readable form on a computer. For a CWIS to solve the problems of information delivery to the campus community, it must meet three important criteria. The first of these is accessibility. The ideal CWIS can be reached at any time from any location. In practice, the CWIS should be available 24 hours a day from any kind of computer workstation, both on and off campus. Even though it is difficult to implement this ideal level of accessibility, any CWIS that does not aspire to this goal may be limited in its success. The second criterion for a successful CWIS is usability. The system must be easy to use, and it must be easy for a user to find the desired information. These are not necessarily the same. Elaborate menus may make a system easy to use, but if a person cannot find the desired information, the menus are of little value. The need for training in the use of a CWIS should be avoided if at all possible. One should not need a high level of expertise to successfully use a good CWIS. Finally, and probably most importantly, a good CWIS must provide the information that people want. This information can be divided into two categories: general interest and specialized. General interest information--such as today's weather, the daily calendar of events, and the menu at the student cafeteria--is what will attract people to the system and make them regular users. Specialized information is that which has a very limited audience, either by the nature of the information or by necessary restrictions imposed on its access. For example, a student's transcript is certainly specialized information, in that it should be accessible only to the student or the appropriate staff or faculty member. Many current CWIS implementations do an excellent job of providing general interest information but do not go on to provide specialized information. The transcript example cited above might not typically be considered as a part of the CWIS. While there are good reasons not to burden a general interest system with specialized information, the former can provide simple links to the latter. For example, one feature of the CWIS might be to call the transcript program. The transcript program need not be part of the CWIS per se, but could actually be a totally different system with its own security, etc. A major advantage to such an approach is that the CWIS becomes the single point of access for many sources of information. Providing a general interest CWIS is relatively easy since several tools are readily available. Examples in use at Baylor include Gopher from the University of Minnesota and TechInfo from MIT. One simply installs software on a server and provides document files that contain the information. Access software is then installed on client workstations so that the information can be viewed. Depending on the particular implementation chosen, software is available for a wide variety of both server and client platforms. More challenging is the provision of the specialized information that can be a part of, or accessible from, a truly comprehensive CWIS. Much of this information already exists in computerized form on our campuses. The problem is that most of it is "locked up" in production systems and inaccessible to the average user. How then do we provide an information-rich environment within the context of an existing investment in information technology? The existing investment in IT The volume of information that must be processed to run a college or university requires that automated systems be employed. Most campuses have invested heavily in systems to handle areas such as registration and enrollment, student billing, and financial aid management. Whether these systems were locally assembled or purchased, one thing that most have in common is that they were developed to automate existing tasks. While these automated systems may help process large amounts of information, they do not always lead to a better product for the student. To improve the quality of our administrative information systems and move toward a CWIS, we must first look at the types of people who use the information they contain. There are two basic types of information users: (1) the production user, and (2) the casual user. The production user is represented by the campus staff member whose job involves a high level of interaction with the information system and requires a high level of efficiency from it. In contrast, the casual user likely does not need the information on a daily or frequent basis and tends to be less concerned with efficiency in the same sense as the production user. This person's concern is, "Can I get the information I want, when I want it, and how easy is it to obtain?" The problem with many current information systems is that they were written with the production user in mind. This is not to say that they were poorly designed or that they have not benefited the campus. Certain tasks can and should be automated. However, by designing for the production user, other users, such as faculty and students, are often not considered. Too often this means that these users cannot directly benefit from our systems. Hence they do not perceive any benefits from the systems. How then do we provide information to non-production, casual users in the broader campus community? Few campuses can afford to completely re-write (or re-purchase) all of their information systems just to satisfy this need. Even if purchasing a new system is an option, most commercially available systems are only now beginning to recognize the need and to begin development in that direction. Therefore, we must find ways to provide information directly to faculty and students by taking advantage of existing systems. In other words, we must leverage our current investment to maximize its benefit. At the same time, new systems must be designed with these ultimate "customers" in mind. Many campuses deal with providing information to an audience outside that of the production user by providing alternative access methodologies. For example, user-friendly front ends are often developed so that ad-hoc queries can be performed against production data. In the past, this was often a difficult approach. However, now there are a variety of tools available that make this a very reasonable approach. It is this approach that has been taken by Baylor and which is described below. Baylor's CWIS approach Designing a system that is "all things to all people" is a challenging task. The fact that this task seems so daunting has probably kept many from even attempting it. However, a more manageable approach is to select individual systems and design an interface for the casual user one system at a time. These smaller systems can then be integrated under a kind of umbrella system that forms the basis for a CWIS. The Baylor Information System (BIS) is such an umbrella system, composed of many elements. The goal of the BIS is to provide first-hand (i.e., direct) access to desired information in a manner that is easy for the casual user of the information. The latter part of this goal is particularly important, in that most of the development effort is spent there. Much of the information provided under the BIS is available first-hand from the production systems used to feed it. However, access through these systems is geared toward the production user, and this often presents a significant hurdle for the casual user. Production systems also often lack the kind of security needed for general access. For example, the transcript module of our student system does not have the ability to restrict who has access to which student's transcript. The only control is over who has access to the module as a whole. Properly designed front ends can overcome these limitations in the production application. Before describing the BIS, a description of the environment at Baylor is in order. Baylor University is a medium-sized liberal arts institution with an enrollment of about 12,000 students, who are served by 1,400 faculty and staff. The desktop environment consists of over 1,700 Macintosh and 450 IBM-PC (or clone) workstations. Most of these are connected to the campus AppleTalk/Ethernet/Token-Ring/FDDI network. This network provides access to file and print services as well as access to various host computers and the Internet. Production systems in use include the Student Information System (SIS) from SCT, a locally developed Human Resources System (HRS), the College and University Financial System (CUFS) from AMS, and the multiLIS library system from Sobeco. SIS and CUFS are run on an IBM 4381, HRS is run on a Honeywell DPS 8/49, and multiLIS is run on a VAXcluster. The Center for Computing and Information Systems is responsible for the maintenance of these production systems and for the development of the BIS. Principles for leveraging production systems Leveraging these production systems into the BIS involved several principles described below, along with examples of their application. Principle #1: Carefully select the target workstation There are two common approaches taken here. One is the lowest- common-denominator approach, often necessary when a wide variety of client workstations exists on campus. It often means designing non- graphic, character-based systems that sometimes use the client workstation as a simple terminal. This can limit the ease of use for the client as well as limit the information display capabilities. The second alternative is to select a particular workstation and concentrate efforts in that direction. In Baylor's case, the large number of Macintoshes on campus led us to select it as our primary workstation. Also, the "point-and- click" graphical nature of the Macintosh lends itself well to the casual user for which the BIS is designed. Even with this choice, there was still an element of the lowest-common-denominator approach, in that most of the Macintoshes on campus are low-end models (Plus, SE, or Classic) for which performance is a concern. Limiting our efforts to one client allowed us to bring a much higher level of functionality to that platform than would have been possible with multiple platforms. Principle #2: Adopt a tools-based approach It is important to take advantage of existing tools so that development does not have to start from scratch. In particular, a wide variety of what are called "information harvesting" tools is readily available. Some of these tools serve as the foundation for application development while others can be used directly. For example, the BIS makes extensive use of Data Access Language (DAL) to access data residing in Rdb databases on the VAXcluster. DAL is a standard protocol for accessing data in relational databases, and it forms the foundation for some of our programmed applications. Also, DAL extensions built into programs such as Microsoft Excel allow them to be used directly to access host-based data. We are now in the process of developing a new application that takes advantage of this functionality. A corollary to this principle is to try as many tools as possible. The BIS relies on information from a variety of sources, and no single tool works well with all of these sources. Also, different tools have different strengths when it comes to issues such as security and presentation capabilities. While it is important to try various tools, it is not advisable to use too diverse a group of them in the actual CWIS. Maintenance and support of the applications then become a problem. It is more effective to pick the tools that work well with existing production systems, and stick with them. Principle #3: Deliver prototypes Many components of the BIS were developed as prototypes that were delivered to key individuals for testing and feedback. The importance of this principle cannot be overstated. Prototyping generally avoids a long system-design phase in favor of rapidly assembling a working model for an application. The prototype can then be placed in the hands of potential users and the design refined as they provide feedback as to whether or not the application meets their needs and is easy to use. For example, the front end to the financial system was placed in the hands of a few department chairs who routinely needed the information it provided. They offered valuable insight into what was required of this component of the BIS. Principle #4: Don't just emulate the production system It usually turns out that casual users are only interested in key functions, so it makes sense to enable those functions without wasting time trying to deliver an interface to the whole system. Additional functionality may be added later if it is really needed. At the same time, value can be added to the information in the production system. For example, there is a particular piece of information in our production financial system that is stored as a two-letter code. The BIS front end to that system takes care of translating that code into a meaningful phrase for the user. Principle #5: Be willing to create derivative information Some production systems simply do not provide the needed information by themselves or adequate information harvesting tools do not exist. In these cases, one must be willing to create derivative products that bring together the necessary information to make them accessible. Derivative information sources violate conventional wisdom that there should be a single source of a particular piece of information. However, with proper procedures for automatically updating the derivative information, most problems can be overcome. The student advisement (transcript) module of the BIS is a good example of a derivative information source. The transcript module of the production student information system does not store transcripts, but creates them on demand by collecting the appropriate information on the specified student. Unfortunately, this can be a rather slow process. To overcome this, transcripts are created in a batch mode and loaded into an Rdb database. The student advisement system then retrieves complete transcripts from this database in a much more timely manner. Another example of a derivative information system included in the BIS is our directory application. The original source for directory information on students is the student information system, while directory information for employees is stored in the human resource system. Information from each of these sources is updated daily into one derivative database against which the BIS directory application runs. Principle #6: Use existing systems where possible Some "production" systems actually are very usable as they are. In the case of the BIS, the library's card catalog is available directly from the production system. This menu-driven application is simply called from the BIS main menu. Principle #7: Include a healthy dose of general interest information The emphasis of this article is toward making use of existing information systems as a part of a CWIS. However, most of this information is specialized and only specific pieces are of interest to any one individual. Including generous amounts of general information in the total CWIS increases its utility, and people establish the habit of consulting it. In Baylor's case, this general interest information is supplied through an implementation of TechInfo from MIT. (Our implementation is known as BearInfo, after the Baylor mascot.) Information contained in BearInfo includes the University calendar of events, the microcomputer store price list, and the class list for the current and the next semester. The class list includes enrollment totals, so that students can easily check for open and closed classes during our pre-registration process. BIS evaluation How does the Baylor Information System stand up against the three criteria stated earlier for a successful campus-wide information system? Accessibility to the BIS is not universal. In its present implementation, full BIS functionality is available only from a Macintosh workstation connected locally to the campus network. However, since the majority of the workstations on campus are Macintoshes, this has not been a severe limitation. As for usability, much effort has gone into providing interfaces that are easy to use and focused enough in their scope that information is easy to find. In terms of the information that people want, we have provided interfaces to most of the production systems so that more information than ever before is available from an individual's desktop. Table 1 summarizes the major components of the BIS and the information provided by each. ************************************************************************ Table 1: Major Components of the Baylor Information System Components -- followed by who they are accessible by -- and key information available BearInfo Faculty, staff, and students General interest information, schedule of classes (including current enrollment), weather maps, etc. Gopher Faculty, staff, and students Similar to BearInfo Library Catalog Faculty, staff, and students Catalog for all library units including item status White Pages Faculty, staff, and students Names, addresses (mail and e-mail), telephone, etc. White Pages Deluxe Faculty and staff Extended directory type information such as faculty degrees and student status Student Information Department chairs and above Class enrollment lists, student class schedules, and admission status Financial Information Department chairs and above Current budget status, expenditure and encumbrance details, purchase- order and travel expense tracking Advisement System Departmental advisors Student transcripts (ordered by semester or by department), degree plans Recruitment System Department chairs and above ACT/SAT scores, indicated interests, and potential college major Executive Information Appropriate administrators Tracking of student applications, admissions, and enrollment ************************************************************************ This is not to say that there are not limitations in the BIS. Student access to some important modules is still not provided, since security and other issues are yet to be fully resolved. Security is currently provided primarily at the application level, by restricting who has access to particular components. Efforts are under way to provide additional security flexibility through a security server (Kerberos or something similar). Some modules are only available during certain hours because of the schedules for the production systems on which they depend. Finally, there is still much information that is not available through a friendly interface under the BIS. It is worth noting that the increased availability of information through the BIS has heightened awareness of the strengths and weaknesses of the production systems against which the BIS runs. The impact of this on the production systems has been an increase in demands for both the quality and quantity of information stored in them. Closing thoughts Providing a good CWIS requires a vision of an information-rich environment that empowers faculty, staff, and students. While this vision is commonly shared with regard to scholarly information, administrative information is often excluded. And while privacy considerations require that certain information be regulated, campuses must move from being information controllers to being information providers. A basic model is that if the information is about me, it should be easily accessible by me. Some of this information, such as my address, should even be modifiable by me. Granted, such an openness can result in abuses. However, the alternative is a tightly controlled system that is perceived as unresponsive to the faculty, staff, and students who expect it to serve them. Security of information that should be private between the institution and the individual will always be an issue, and justifiably so. However, we must address this issue rather than letting it be an excuse not to provide direct access to information. The banking industry provides a good model for this in automated teller machines. Certainly the security of an individual's money is a very important issue. However, if banks had spent all of their time lamenting potential misuse of ATM cards, we would still not have automated tellers. Instead, a means of providing security was implemented through personal identification codes, and personal banking has been radically changed as a consequence. The CWIS can be an important mechanism to foster more of a service approach on campus. As more information is placed directly into the hands of users, some traditional production tasks may no longer be necessary, freeing personnel to engage in direct service to the faculty, staff, and students. There is obviously a very real cost to providing a CWIS. However, the issue to address is not what it will cost to do it, but what it will cost not to do it. As additional emphasis is placed on the quality of the total educational experience, institutions that are not focused on providing ready access to all types of information resources will be unable to compete with their peers. An effective CWIS can contribute to increased satisfaction and the ability to continue to attract and retain faculty, staff, and students. ************************************************************************ Principles for Leveraging Existing Production Systems Carefully select the target workstation Adopt a tools-based approach Deliver prototypes Don't just emulate the production system Be willing to create derivative information Use existing systems where possible Include a healthy dose of general interest information ************************************************************************ Alan Hargrave is Associate Director for Academic Computing and an instructor in physics at Baylor University. He is responsible for directing all phases of academic computing, including mainframe computing systems, microcomputer laboratories, and programming support. He also coordinates services for special academic needs such as library systems and supercomputer access, and coordinates planning for long-term development of academic computing facilities and staff. Dr. Hargrave holds a master's degree in physics from Trinity University, and a Ph.D. in physics from Baylor. ************************************************************************ This article was adapted by the author for CAUSE/EFFECT publication from a presentation made at the CUMREC meeting in May of 1993. ************************************************************************