Creating New Synergies by Combining Academic and Administrative Computing |-------------------------------------| | Paper presented at CAUSE92 | | December 1-4, 1992, Dallas, Texas | |-------------------------------------| CREATING NEW SYNERGIES BY COMBINING ACADEMIC AND ADMINISTRATIVE COMPUTING Les Lloyd Lafayette College Easton, Pennsylvania 18042 ABSTRACT During the twenty or thirty year evolution of computing in the college and university environment, the development of academic and administrative computing departments continued with little interaction at most schools. In the eighties, many schools combined the departments, realizing that there were opportunities to be gained in reducing duplication and providing expertise to a broader audience. There are issues that divide the two departments, namely the confidentiality of information and the fear on the part of academics that producing payroll checks will take priority over teaching and research needs. This paper will discuss the results of our merger at Lafayette College, the ways we have helped alleviate these fears and provide added value to our services to both academics and the administration without any increase in staff or funding. This paper is a follow-up to an article written in June, 1990 for The Edutech Report entitled "Why Administrative and Academic Computing Hate Each Other". Excerpts of that article are included here as background. -------------------------------------- Perhaps hate is too strong a word, but it sure seems like it fits when talking about academic and administrative computing folk. Why are discussions about these issues coming up now? Networking and downsizing. Academic and Administrative computing were able to remain completely separate entities on campuses that chose to structure departments that way until faculty, staff and students started asking for access to administrative data. While some have made such requests before, not until computers were connected to a campus-wide network did the community realize that it should be able to ask for and get access to data for applications such as on-line registration, department budgets, student accounts and more. History: The two areas of campus computing were almost bred for sibling rivalry. In the early days of computing, administrative computing ruled. There were a few "power users" in academic computing that knew how to use the behemoth machines, but the university had to run, people had to be paid and administrative computing had priority. As computers became easier to use, and more necessary in academics, the number of users, budgets and support staff increased. On campuses where the two centers coexisted in the same quarters, they were split apart, and often divided between academic and administrative reporting structures. Academic computing was growing, computer science came into its own as a discipline; at the same time, college administrative staffs were growing, government regulations imposed more needs on administrative systems and more departments wanted to computerize their operations. The stage was set for competition in computing resources and staffing. Priorities: What are the functions of the two areas? Administrative computing is a production facility producing paychecks, course schedules and personnel files among other jobs. Academic computing supports and encourages innovation, the kind of innovation that could bring an administrative system down at a moment's notice. Hackers are often the top computer science students testing out new-found knowledge. Administrative computing must resist "quick-fixes", and "new-for-the-sake-of-new software". Programming must be thoroughly tested before being released for use, a marked contrast to the student working on a project hoping that the professor doesn't check the one loop s/he can't quite get to work properly. The role of both departments has been somewhat well-defined since they were established, though not in terms of each other. It is seldom that an administrator needs access to academic computing facilities or resources unless s/he is taking a course or doing research. Similarly, while faculty have considered the concept of being able to look at an advisee's student records a desirable one, until computer networks were installed, there wasn't much belief that it would or could actually happen. When it became apparent that faculty could connect to any of the academic mainframes, the next logical question was "why not the administrative system?" Let's look at the administrative side of this. A committee or user's group probably works with the head of administrative computing to help plan priorities for programming and system development. Because of planning for budgeting and systems installation, scheduling for projects may be planned for several years out. When a campus is networked, a new priority becomes evident, that is faculty and student access to administrative data. How should administrative computing prioritize this new area against its existing "clients"? Who among administrative users, members of the administrative computing committee or in the administrative computing department will argue for faculty and student access taking precedence over "their own" projects that have been on the books for long time periods? Furthermore, will all projects for administrative users ever be completed, thus allowing a space in the schedule for network access issues? Personalities: Probably most because of the difference in priorities, the personalities of the individuals in the two departments can add to the friction. Administrative computing staff must be thoroughly detail-oriented because of the significance of the data passing through its systems. While programmers in academic computing are responsible for making sure their systems work, an error usually doesn't cost as much either financially or time-wise as one in administrative computing. If there is a bug in an academic program, it could cause problems in a class and get a few people mad, put if the payroll program crashes there are major repercussions for administrative computing personnel. These pressures are reflected in the types of people hired in each department. Visibility/Exposure: When was the last time your school newspaper ran an article about administrative computing? Compare that to the exposure that new computing labs, software development and new networking applications get. Of course, if all students received bills that were incorrect, there would surely be lots of talk about administrative computing. But generally, most students and only a few faculty actually consider that there may be another computer center on campus aside from academic computing. Sheer number of users makes academic computing, its foibles and follies, more visible to a greater number of people. Networking issues: If there is friction between the two computing centers, network access to administrative data could bring on a full-fledged conflict. Security: One of administrative computing's chief responsibilities is make sure that data stored on the system is safe. Password and terminal access is closely monitored. Allowing access to the system or its data poses a threat to the security measures that have been developed and employed successfully for years. Who "owns" the data?: In discussions about data ownership, some school policies say that the university owns all data and therefore a decision to share it can be made centrally. At others, each department owns its own data, the registrar, financial aid office, business office, etc. are in-charge of who uses data they are responsible for. Getting these departments to agree to data-sharing is not always easy. Legal issues: Many states and the federal government have very specific rules concerning what data can be accessed by whom. The individual is given rights to that allow her/him to see her/his own records and to prevent access to those records by others. These rules should be incorporated into the administrative systems and need to be dealt with when network access to administrative data is provided. Issues such as "does a faculty advisor, a department head or a professor who teaches a student one course have the right to see a student's record without his or her permission?" must be dealt with carefully by administrative computing personnel and academics. Paper versus electronic access: It is often simple to draw parallels between paper and electronic data access. In the above example, if a faculty member can ask the registrar for a paper copy of a student's transcript without the student's permission, shouldn't that institution allow the same access electronically? Often a distinction in policy between the two means of access is made when the end-result is the same. Reporting structure: If the computer centers were split apart 20 or more years ago, chances are that administrative computing reports to an administrative VP or financial person and that academic computing reports to a provost or academic VP. When each center had divided responsibilities, this structure may have made sense, but networking changes that. When priorities cannot be agreed upon by the respective department heads or computing committees, who negotiates a treaty, the vice-presidents? the president of the college? How much computing experience do the people that these departments report to have? Are they qualified to negotiate technical topics, or does the more knowledgeable vice-president, or the loudest computer center department head win the debate? Should the president be involved in these discussions if the administrators are not computer-aware? If not, how should these debates be resolved, by committee? Schools that have a "computer czar" or one person that was ultimately responsible for both computer centers are in a better position to discuss and settle territorial issues than are schools with completely separate reporting structures. Separate departments at many schools have led to a long history of competition and dislike amongst computer professionals in the two areas. Though networks have integrated many campuses, only a few colleges have true links between academic and administrative systems. Access to administrative computers by academic users is minimal at most institutions. Some have allowed access to selected users; "divided traffic" permitted access while ensuring security. In some cases, though the two systems were interconnected, the administrative system was invisible to academic users. What Happens When You Combine Operations? Reorganizing computing is no different than reorganizing any other department. There are fears and insecurities to deal with. The background provided above shows many of the obstacles to a successful reorganization of computing. When staffs have little or no contact and then are thrown together, there is a potential for problems, especially if a position is eliminated in the process (i.e. one of the two Directors). It is important to look at Computing Services from the clients' perspective. In many cases, a client of administrative computing has several places s/he has to call for assistance; an administrative programmer for help with administrative software, a user services person, perhaps in academic computing, for help with word processing and maybe network and hardware departments if applicable. When these departments are organized into separate units, the end-user can become frustrated by a lack of communication between these departments. For example, the client may call networking because they can't print to their shared printer; they may be referred to hardware and the problem may actually be the printer set-up in their word processing program. This issue is one of the key reasons for combining operations. Traditional administrative users may be confused about whom to contact for assistance because they were used to calling one person, i.e. the programmer or support person for their module. Once they start using PC software, they become a client of traditional academic computing and networking resources, support, training and documentation. In a combined department, situations like the ones above can be resolved easily by e-mailing others involved in case the problem is not solved in the first office. This also helps to educate the various staff members about what to look for in the future. It's not that this couldn't be done if there were separate departments, but it often isn't because of the way these departments were set up. One of the key advantages to combining operations is that no person is left to be "just the programmer", "the repair person" or whatever. Regular meetings and discussions broaden the experiences of staff members who learn some of the ins and outs of each of the functional areas. At the same time, this increase in knowledge of who does what can help people in their specializations because other members of the department have a better idea of who does what and what questions get referred where. ____________________________________________________________________ Sample WHOM TO CALL FOR WHAT cards from Lafayette: ADMINISTRATIVE COMPUTING: WHOM TO CALL FOR WHAT- 1992 VAX/POISE questions or problems: 5131- Tina DT#0 Shared printer questions or problems: 5131- Tina DT#0 Basic LINC/PC questions: 5506- Help Desk LINC problems (passwords/accounts): 5531- Fred ROSE LINC usage questions: 5510/5502- Dusty/Tracy ANDE/LOGA Standard PC software questions: 5510/5502 ANDE/LOGA Standard PC software problems: 5501- Sue LEOP Network problems: 5571- Mark WEBE PC system problems: 5509- Chris KOCH Windows questions/problems: 5510- Dusty ANDE Network installations: send RFS LINC Forms System New computer installations: send RFS LINC Forms System Documentation for standard software: departmental liaison or AHE 310 Purchases of supplies, manuals: 5504- Dale OSWA Rental computers: send RFS LINC Forms System Software library: 7086 (afternoons, Fall/Spring) Question: How do I do something? Problem: Something is wrong! ACADEMIC COMPUTING SERVICES: Whom to call for what-- 1992 Help with basics: 5506- Help Desk WordPerfect/LINC/Standard PC software questions: 5510/5502- Dusty/Tracy WordPerfect/Standard software problems: 5501- Sue Windows/Mac questions/problems: 5510- Dusty Network problems: 5571- Mark LINC system problems (lost passwords/new accounts): 5531- Fred Network installations (faculty/staff): 5510- Dusty PC hardware problems (all)/Network installations (students): 5509- Chris VAX/UNIX (new accounts: E-mail to KOST/problems): 5507- Phil Supplies/computer purchases: 5504- Dale Installing software on the network for course use: 5501- Sue Requests by faculty for new/upgraded computers: 5505- Les Software Library (afternoons fall/spring): 7086 Computer Room Reservations: 5504- Dale CAE- Engineering Graphics: 5400- Becky Rosenbauer Problem: Something is wrong! Question: How do I do something? ____________________________________________________________________ A combination of departments also provides the opportunity to create focus groups on topics that transcend traditional departmental boundaries. These might include user services, networking and training as examples. The other key issue in combining operations is alleviating the concerns of users that one department or the other will be stronger or that paychecks will take priority over academics. One way we've dealt with these issues is to keep the two systems separate so processing of administrative information never competes with academic work for system time. There are emergencies, for example, power outages, when one system has to be brought up first. In that case, administrative computing is usually the priority thought this rarely delays anyone more than a few minutes in actual processing time. The argument of one "side" dominating the other can be dealt with with proper management, good relationships between the two houses and especially ongoing work such as the aforementioned focus groups.