Tony Dale

November 20, 2001

Computer infrastructure and the support of computing for Computer Science departments

Introduction

• From June-Oct, I visited four NZ and 27 overseas universities to survey the staff and snoop around.
• Attended a couple of conferences and a briefing at Sun Micro.
• Focus of the visits was on infrastructure (desktop and server machines, network, tech support), esp for CS Depts.
• Looking for trends, new ways of doing things and $$$.
• Summarize results for interested parties (including those surveyed). Here I give a synopsis of my survey results.
• UoC is not as bad as some might think - in fact we're quite representative of the better institutions.

Unix operating systems

• Freeware unixes such as Linux or NetBSD were the desktop OS for most CS depts.
• Main drivers for this are the cheap hardware platform, the wish to use a unix OS and lots of current research and software using Linux.
• Linux expertise in IT service depts was thin on the ground - mostly the setups were maintained by CS support or academic staff.
• Many CS and IT depts still use Sun/Solaris servers, esp. E250/450 machines.
• Many CS depts used to use lots of Solaris for the desktop, but moved away from it - still a popular server OS, though.

PC operating systems

• MS Windows is the OS of choice for Commerce and IT service depts, and is usually found in CS depts.
• Windows installations included W95, W98 and lots of NT4. W2K in a few places.
• Three CS depts were nearly 100% Windows-based. Two because it was the OS supported by the IT services dept, one because the academic staff wanted it.
• Many depts had moved away from Macintosh over the last three or so years. Some were looking at Macintoshes again, though, for specialist labs (eg: Multimedia).

System installation & admin

• Individual workstations are the rule. Only a couple of CS Depts were using X-terminals (and reaping the benefits of this). No large winterm labs.
• Linux: quite a spread between interactive CDROM install, disc image copy, vanilla install plus copying customized files, or kickstart.
• Windows: Often a ghost image copy, sometimes an interactive install. Windows unattended install not much used.
• Mac: Mostly an interactive install, or occasionally net booting.
• Most (but not all) depts had quite centralized user file storage, with a good and reliable backup system.
• A few depts maintained large ``software farms'', but many relied on software locally installed on the workstations.

Name services

• Linux services tended to use DNS, NIS (YP) and NFS.
• Windows networks frequently used NT4 domains. A number of institutions had considered Active Directory, or had tried to use it and couldn't make it work. Novell Directory Services was still well entrenched at a few places.
• Macintosh labs may or may not use authentication.
• One or two institutions had quite seamless integration between unix and windows authentication, typically with password-change propogation between the naming services and NFS plus Samba for filesharing.
• Some depts are moving to LDAP-based naming services, including using W2K AD LDAP (is this wise?).
• Most depts are not using a public-key infrastructure. Generally a relaxed approach to security.

Networks

• LANs are usually CAT5 ethernet to the desktop (frequently 100 Mbit).
• Backbone may be copper or fibre using ethernet, ATM or FDDI, at 100 Mbit-1000+ Mbit.
• A number of geographically dispersed campuses used MANs and/or wireless links.
• Almost always the IT service dept ran the internet connection and campus backbone. The CS dept ran the dept LAN about half the time.
• Frequently network security was low: the LAN might be open to the internet (ie: no firewall or internet proxy), with lots of hacker attacks. Especially so in the USA.

Web

• A few universities had quite strictly-controlled webs, with strict guidelines on page construction and access to change pages.
• Many more webs were more-or-less completely devolved to depts/individuals to maintain.
• Some depts had a few web servers, some had lots!
• Lack of page maintenance, lack of backups, etc, was often a problem.
• No-one had a perfect approach.

Helpdesks

• Usually the IT services Dept runs a very good helpdesk (eg: take-a-number desk plus Email/web plus phone).
• A good arrangement is a specialist helpdesk dept which can deal with normal problems and escalate bigger problems to the support staff. Less good is a roster of support staff (although then everyone keeps in touch with the users), and worse still is leaving the users to find someone.
• CS dept helpdesks range from IT-dept standard to none at all, but were frequently quite informal arrangements: Email your favourite support person, etc.
• Helpdesks are part of a University ``culture''. There may be other traditional ways of providing help, such as mentoring from fellow students.

MIS

• MIS was almost always maintained by a special department.
• Often a group of campuses would form a consortium to commission custom administration software.
• Peoplesoft seems to be the most popular campus package. A bit expensive, though.
• Oracle was popular, too, especially the financials app.
• Student systems were frequently custom-written for the campus.
• Some huge MIS disasters in the making.

Support staff characteristics

• High quality staff were universally recognized and sought after.
• Qualifications were usually a higher degree in CS. Depts would ``shoulder-tap'' recent graduates.
• Experience not necessary but an ability to learn is.
• Training is left up to the staff concerned to organize. No induction programs, etc. Some depts relied on a high staff turnover (of recent graduates) to keep tech staff up-to-date.
• In CS there were no professional managers - all managers were support staff who had come up through the ranks.

Support staff conditions & training

• The best university to work at is in San Sebastion.
• Some universities had lots of centrally-funded, permanent staff. Others could only use part-time PhDs or staff funded by grants.
• All universities paid less than the commercial sector.
• Working conditions made up for it, though: an interesting environment, 9-5 workdays, part-time or teleworking.
• A few universities (actually certain individuals at the universities) paid lots of attention to staff conditions and training to retain staff.
• Some universities relied on a frequent and regular staff turnover to provide new, freshly-trained graduates.
• High salaries in the private sector could overturn both the above approaches.

The Golden Ratio - 5:1

• This ratio (5 academics per local tech support) seems sufficient to keep a CS Dept ``happy''. There is enough tech support for teaching and administration, but not for research.
• With better ratios, some tech staff could (and did) assist with research.
• Tech support staff have a low enough workload that:
  • There is time for major infrastructure projects and planning, not just firefighting.
  • There is some time for training and the occasional conference (1-2 per year).
  • Stress levels were low enough not to contribute to staff turnover.
• With very low (or zero) numbers of support staff, academic staff might step into the breach, rather than use central IT services.

Management & task allocation

• Management of tech staff was frequently low-key, in fact, sometimes downright amateurish.
• OTOH, heavily managed IT support sections were frequently not happy places (eg: from imposition of a new structure).
• Generally, management is team-based and relies on good staff and co-operation.
• Not many trouble-ticket systems in use, although some very good systems, such as the freeware RT system, are available.
• Task allocation is often by job description (the ``Windows person''), or to least-loaded staff.
• Projects (even big ones) were usually not formally managed with, eg: milestones.

Planning

• Most CS depts had to cope with annually increasing student numbers.
• Only a few institutions had well-defined plans for their infrastructure. Most had a good idea of what needs to be done next year. A few did not plan.
• Funding drives planning. Transparent funding leads to good plans. Inconsistent or no funding leads to poor planning.
• Good planning leads to good infrastructure, mostly.
• A surprising number of institutions had some very old PC hardware (32 Mb machines, 486 machines, etc) still in use.
• Some quite well-funded American universities had trouble with the infrastructure because most funding is attached to academics and there was little money set aside for dept-wide infrastructure.