Discipline-Specific Humanities Computing: Whose Job Is It?

paper
Authorship
  1. 1. Andrea Austin

    Queen's University

Work text
This plain text was ingested for the purpose of full-text search, not to preserve original formatting or readability. For the most complete copy, refer to the original conference program.

Discipline-Specific Humanities Computing: Whose Job Is It?
Andrea Austin
With higher education institutions experiencing unprecedented growth in distributed computing, pressures to support the needs of students, faculty, administrators and staff using these systems in various and diverse ways have also increased substantially. In particular, there has been an increasing awareness that if faculty are going to integrate IT into teaching and students to benefit from the full potential of IT in their individual programs, support for discipline-specific computing must be implemented and maintained. The big question for most institutions has been "who is to provide this support?" This paper presents several models that have been adopted for providing computing support to humanities faculty, and focuses on the following key issues as spelling the success or failure of these models: ability to provide adequate support at the departmental level, at present and in the future; demand on faculty time and energy; credentials and range of responsibilities of professionals providing the support. Examples of models in use at specific universities are offered where appropriate (in the interest of brevity, reference to these examples has been omitted from the abstract). Ultimately, the paper ends with an endorsement of decentralized support models.

While budget restraints have driven a trend towards centralization in the administration of computing services, an equally influential trend towards decentralization has been driven by the complexity of resources required to meet the needs of diverse users. In providing humanities computing support, many institutions have opted for what has been called an "intermediary solution" ("Integrating Information Services in an Academic Setting: The Organizational and Technical Challenge," _CAUSE/EFFECT_ 17:3, 1994), either establishing a humanities computing center or delegating to certain computing center personnel the specific task of responding to the needs of humanities faculty. These support personnel work more closely with humanities faculty than has traditionally been the case with generalized computing services personnel, taking on the responsibilities of helping faculty to upgrade computing skills, making faculty aware of computing resources that might be of specific interest to them, and working with faculty in designing course materials that take advantage of such resources.

Administrators cite the numerous advantages of such models. They do more towards getting IT staff out of the office and into the work environment where the services are actually being used, increasing the support professional's ability to understand the computing goals of humanities faculty and interpret requests for help from them. This semi- centralized support system is also often seen as more cost effective than allowing each department to establish and maintain its own computing services system. Hiring only a few professionals can meet the needs of several departments at once, both avoiding duplication of services and resources expenditures and having the likelihood of avoiding expensive interoperability problems down the road. The combination of enhanced ability to respond to increasingly complex user demand and at the same time stay within budget, or even save money, make these models especially attractive.

There are some disadvantages to the semi-centralized approach, however, most of which stem precisely from its status as an intermediary solution. In practice, these models often do not go far enough towards providing the level of discipline-specific support that enables faculty to develop exciting and innovative use of IT resources. Similar tendencies as those at work in general computing services centers exist, primarily a factor of there still being too few people to meet too large a number of demands. More time is often spent on basic upgrading of faculty computing skills and on introducing faculty to resources than it is in developing discipline-specific applications. At the same time, such models often tend to draw almost as heavily on un(der)paid student labour as general computing services centers, with the professional humanities computing support staff acting as administrators and coordinators, rather than interacting with faculty at the individual level. As a result of this still-inadequate human resources supply, faculty wishing to move beyond more basic applications are frequently left to muddle along by themselves, shifting the load back again to also already-overworked faculty. An additional problem is that currently few departments have developed a defined system for evaluating and rewarding the activities of faculty who decide to devote time and energy to such tasks, having the effect of already-overworked faculty taking on what is therefore tantamount to extra, unpaid labour. Add to this the suspicion among faculty in many departments that "real" jobs are somehow being lost to computers or "techies" ( "Reengineering Teaching and Learning in Higher Education: Sheltered Groves, Camelot, Windmills, and Malls," R. Heterick, Jr., ed., _CAUSE Professional Paper Series #10_) and it is easy to see how, though a cost-effective solution, the semi-centralized approach can be less strategically effective than it might seem.

A more thoroughly decentralized approach, and currently the less common approach, is that of hiring a faculty member who specializes in humanities computing into each department. Responsibilities could range from teaching humanties computing courses specifically focussed for that discipline, to developing discipline-specific applications and courseware, to maintaining departmental servers and administrating departmental IT resources; responsiblities could also involve peer support and encouragement in adopting IT for teaching. Advantages of this model include the obvious gain of truly discipline-specific support, putting the needed service as close to the end user as possible. Economically, the hiring of humanities computing faculty members for each department may not be as wasteful as it sounds. When faculty are told that there is not enough money for both additional IT resources and another faculty member, if given the choice, they will usually opt for the faculty member ("Using Information Technology to Enhance Academic Productivity," W. Massy and R. Zemsky, Educom Conference, June, 1995). Indeed, these "in-house" humanities computing specialists could--and at some institutions, do--also teach courses in the department's main discipline. For the price of one professor, an English department could, for example, gain both a humanities computing specialist and an eighteenth-century literature specialist. With both sets of duties being officially defined as part of the faculty member's position, professional rewards for work done and a more equitable workload may be more likely to be achieved.

Disadvantages of this model consist primarily of interoperability problems and duplication of services, two of the issues that the semi-centralized model does address well. These disadvantages are not inevitable, however; coordinated efforts on the part of departments, schools or divisions, and computing services, occuring in the context of an institution-wide general IT strategy, can eliminate most of these problems. Well-defined roles for each level of support would then become a crucial issue; computing services providing skills upgrading and general connectivity support, for instance, with departments providing the bulk of discipline-specific support and application development and schools or divisions running introductory humanities computing courses, possibly team-taught or taught alternately by faculty members from different departments who would also teach more discipline-specific computing courses aimed at upper-year students would be an example of an effective work arrangement between the different levels. A more serious disadvantage, at this point in time, is the lack of candidates for such a position; as department heads have pointed out, finding Ph.D-ed potential faculty members who are also sufficiently qualified in humanities computing can be a daunting task ("Jobs for Computing Humanists," E. Johnson, _Computers and the Humanities_, 27.2,1993). I believe, however, that this is a problem in the process of righting itself, as more and more faculty and graduate students become involved--and credentialed, either by way of degree program or publication--in humanities computing.

Higher education institutions are currently at a crossroads in balancing what services they can afford with what services they really do need. One thing is clear: more and more faculty are going to move beyond basic computing abilities, and more and more students thoroughly conversant with information technologies are going to enroll. Humanities computing support models are going to have to keep pace with these changes.

If this content appears in violation of your intellectual property rights, or you see errors or omissions, please reach out to Scott B. Weingart to discuss removing or amending the materials.

Conference Info

In review

ACH/ALLC / ACH/ICCH / ALLC/EADH - 1997

Hosted at Queen's University

Kingston, Ontario, Canada

June 3, 1997 - June 7, 1997

76 works by 119 authors indexed

Series: ACH/ALLC (9), ACH/ICCH (17), ALLC/EADH (24)

Organizers: ACH, ALLC

Tags
  • Keywords: None
  • Language: English
  • Topics: None