Models for the organization of academic computing
Authors: R. G Brookshire
Venue: Proceedings of the 17th annual ACM SIGUCCS conference on User Services (1989)

The organization of academic computing is complex and requires many different dimensions to be described properly. Each dimension is a continuum which extends between two models of academic computing. The models represent opposing views of how academic computing ought to be arranged, and they define the dimensions which they anchor. One dimension, for example, extends between totally centralized computing at one end to totally distributed computing on the other. Another dimension is characterized by having the library model of computing at one end, where services are free to all patrons, and a fee-for-service model at the other end, where each computing service is charged back to customers. This paper proposes yet another dimension, one which encompasses the purposes of the enterprise, how it is organized, and how the staff do their work. It is a dimension defined by the contrast between the university faculty department and the commercial data processing shop as models of academic computing. The distinction between a faculty department and a DP shop is an artificial one, of course. I believe, however, that it is an illuminating comparison, one that forces us consider just what it is an academic computing organization is supposed to do and how it should do it. This paper will compare and contrast these two models in terms of how they define the goals of academic computing, how the department should be organized, and how the staff should conduct themselves within that organization. Consider for a moment a teaching department in a university or college. The purpose of the department is to teach an area of study&mdash;its facts, theories and methodologies&mdash;to students. The theories, which explain how the field is organized, and the methodologies, which prescribe how the subject is to be studied, are more important than the facts, which are subject to interpretation and may be superseded by new knowledge at any moment. The students progress from general, introductory courses to more advanced courses. What would an academic computing department which followed this model be like? First, it would have as its goal the training of faculty, students and staff in the use of computers. Giving users a good understanding of computer basics, a theory, and some general problem solving tools, a methodology, the department would concentrate on teaching computer users to help themselves, not on solving their problems for them. Just as faculty would rarely teach the same subject to the same students twice, so the academic computing staff would rarely see the same users for the same problem twice. A user who comes back is returning with a different, more advanced problem, just as a senior may take a difficult seminar in the same department in which he took a survey course as a freshman. An academic computing department which is successful under this model will create computer users who can help themselves just as a college graduates students who can go on to do independent research. A teaching department has a nearly flat organizational structure, usually consisting of a number of faculty and a department head or chairperson. On entry to the department, each faculty member has basically the same credentials and qualifications: a terminal degree in the discipline. Faculty are distinguished from one another by their areas of expertise, and their rank is based primarily on seniority. Faculty of higher rank do not supervise those of lower rank. In an academic computing department which uses this model, the structure may be nearly flat, with the all or most of the staff reporting to a single manager or director. As faculty have their areas of expertise, so the staff of this department have their specialties. Promotion within the department is based mainly on seniority. The staff will have similar backgrounds and qualifications, possibly with most holding master's degrees. The work of college faculty is characterized by autonomy. They are free to choose their research projects within their fields, and may pick the courses they teach, once the basic needs of the of the department are fulfilled. The can conduct research or teach using any methodology that seems appropriate, and are not required to account for their time on a regular basis. Large projects are handled by committees, many of which are ad hoc. An academic computing department which was like this would allow its staff members to choose their own areas of concentration or projects when the core functions of the department are met. They would choose the software and hardware for their projects based on their own independent judgment. Staff may work flexible hours, and the committee structure might be employed to deal with big undertakings. Following this model, academic computing staff would be largely responsible for their own time, and act with a minimum of supervision. The faculty department model for academic computing has some clear strengths. As the cliche advises, it's always better to teach people to fish than to take them to Long John Silver's Seafood Shop. Users who come in with new and challenging problems keep the staff on their toes. Promotions based mainly on seniority give the staff assurance of progress in their careers. Personnel who function mainly on their own authority have the assurance and satisfaction of doing jobs the way they think they ought to be done. This approach is not without its problems, however. As computer users bring more complex problems in, the likelihood of quick solutions decreases, adding to user frustration. Staff who perceive themselves as more technically skilled that their colleagues may be frustrated if this counts for little in their advancement. A flat organizational structure may offer too large a span of control for one manager to supervise adequately. Allowing staff to select their own projects may mean that some projects never get addressed. Some people don't work well with little supervision. They get lazy or confused and require frequent prodding or direction. The committee approach to problem solving is notoriously inefficient. These drawbacks encourage us to examine the model at the opposite end of the spectrum, the one based on the commercial data processing shop. The purpose of a commercial data processing shop is to provide data processing services to customers. The customers are interested in getting results, and are not generally concerned with how the results are achieved. Good service will generate repeat customers who will get the same services over and over. Customers are differentiated from each other by the kinds of problems they have and services they require, not by the level of sophistication of their demands. An academic computing department that followed this model would be primarily concerned with providing computing results to users. The training function would be secondary, or even omitted. A successful academic computing department under this model would be one with lots of satisfied repeat customers. Developing an efficient routine to process their requests would be critical to the functioning of the department. DP shops are typically organized hierarchically, with teams of programmers reporting to programmer/analyst team leaders, who report to managers reporting to a senior manager or director. Team leaders or managers have often been around longer than the personnel they supervise, but they have achieved their positions mainly through their expertise, not their seniority. Programmers are distinguished from each other by the tasks on which they're working. Entry level employees may have fewer years of education and lack some of the credentials of more senior personnel. Academic computing departments in state universities may be organized along these lines because state merit systems based on commercial models encourage it. Departments which work well following this model will have a staff of versatile programmers who are switch hitters and have experience in diverse applications. Staff will see clear paths of advancement through the organization. Advanced degrees and certificates may be required of higher level employees. In the commercial environment, programmers' work is highly directed. They are assigned projects with strict objectives and goals, and adhering to timetables and getting products and services out by the deadline is critical. Programmers apply a stable set of tools to problems within strict methodological limits set by management. Documentation and programming standards exist and are followed. An academic computing department which follows this model will deliver its services on time and reliably. It will develop and observe standards in its own work, and may seek to provide standards for the rest of the college or university. Its work will be distinguished by the efficient use of subroutine libraries, fourth generation languages and other tools. Project assignments will flow down the organization from the top. The DP shop model is, of course, not without its own set of problems. Although the successful academic computing unit which follows this model may have a large core of satisfied customers, there may be another large group of potential users whose needs are not addressed. The department may grow to be excessively reliant on established routines and procedures, and have difficulty addressing new or advanced problems. Although many employees find a hierarchical arrangement appealing because of the clear paths of advancement, entrenched senior managers may force promising subordinates out of the organization because they are blocking the upward route. In a highly demanding environment, the list of potential projects demanding academic computing quickly escalates. Those for which no team is available sit in the queue, causing customer frustration. This frustration may, in turn, lead the customers to seek other solutions to their problems. Likewise, the problems which fall outside the normal range of experience may not be addressed. Many academic computing centers were slow to join the personal computer revolution because they were not flexible enough to see the advantages of these tools. Many college and university computer users chose personal computers because academic computing centers were unable to address their needs. Obviously, neither of these models is the total solution to the problems of academic computing. No university or college, to my knowledge, follows either of these models, strictly speaking. On the other hand, I believe that almost all academic computing departments can be located somewhere on the continuum that runs between these two models. In the fall of 1987, we were given the task of combining the Academic Computing Center, which provided central VAX computing, and Microcomputer Services, which supported academic and administrative microcomputing, into a new department, Academic Computing Services (ACS). Our new organization leaned heavily toward the faculty department model. We placed a great deal of emphasis on training, offering over 60 different workshops to faculty, staff and students, and purchasing video and computer based training packages. Everyone on the staff was responsible for teaching or developing at least one workshop. We developed a very flat organizational structure, with over half the staff reporting straight to the director. ACS staff worked autonomously and chose their own areas of concentration. Large projects, such as the evaluation of categories of software, were accomplished through ad hoc committees. A little over a year later, we reorganized again, this time in response to a campus-wide restructuring of data processing and communications functions. The new organizational structure, implemented in January, is much more hierarchical. Most of the staff report to the director through two senior managers. This change was undertaken mainly in response to demands by senior staff for more supervisory responsibility. We thus moved the department along the continuum toward the DP shop model. In other respects, however, we have stuck with the faculty department model. The location of any particular academic computing unit between the faculty department and DP shop models will be due to many factors. Large departments may require more hierarchical structure. Departments with both academic and administrative responsibilities may prefer the project team approach to administrative systems development and maintenance, or the customer service orientation of the DP shop model for generating routine administrative services. Departments in research institutions may find that faculty and researchers demand little beyond consulting and training, providing most other academic computing functions on their own using workstations or departmental systems. I contend, however, that using this dimension to describe academic computing helps to focus our attention on what we are doing, how we are organized to do it, and what approach we take to getting the job done. Paying attention to these questions is important, and is something we need to make time for on a regular basis.