Hi Barr,
From Reinhard's excellent discussion you may well realize
that your best option is to prevent your computer service
from being shut down, any other option is likely to be second best.
A well run local service integrated with national facilities can
offer unbeatable computational support, as has been argued previously [1].
Thus you may like to mobilize political support at your institution
to prevent closure of your service. Take your case to the
relevant professors and get them onside. Get the user molecular
biologists together and make a joint front to support
your computer service.
SOME POINTS FOR YOUR CASE:
Your service is only running at a loss in the narrowest
of cost-accounting terms. A service with a seamless
comprehensive package at its core is the most efficient to both run,
and support the research of your institution. Efficiency falls by
the wayside if you and other molecular biologists have to assemble
bits and pieces to do it yourselves.
The major benefit and cost in running a local service is in support,
both for software maintenance and front-line user-support personnel.
Both software and hardware can now be obtained at fractional costs of
peoples' salaries, as befits the crucial importance of support personnel in
the provision of efficient computing services. I assume that you are
in danger of losing your support personnel, as well as the software.
Thus your arguments can include:
(1) On-site computing support is necessary.
facilities for computational molecular biology are essential
for research at your institution, if it is to compete well
internationally. The best support for research is provided
with a local service, that is integrated with national
facilities [1]. So you need a local service. The main reason
for this is that optimal front-line user-support requires a
local on-site component.
(2) Time is money.
Expert computer support staff in doing their
job save research staff much invaluable time. Imagine the
alternative to your efficient local service of putting
together bits and pieces yourselves:
experienced users -
would lose significant amounts of paid research time
*each* time a different piece of software was set up, in;
(i) finding the software,
(ii) installing it,
(iii) learning how to use it: in contrast, with the
GCG package each program works in a similar way
so most learning time occurs with the first one or two
programs you use, proficiency with these cuts learning
time for *all* other programs in the package,
(iv) explaining to novices how to use it,
(v) writing software to put input data in the right format.
Moreover, a molecular biologist may not be able to carry out
computer support tasks very efficiently, compared to trained
support staff.
Much user expertize resides in molecular biologists
who are on short-term contracts. Thus existing expertize
is quickly lost as contracts expire, and new staff
must learn how to do things. Thus labs would continually
be losing time for staff to learn computing support,
thereby increasing the inefficiency of doing it yourself.
novice users-
could be lucky to find an experienced user to help them.
They may well be left floundering without any proper
front-line user-support, and so not perform their research
as well as they should, and as well as the institution needs.
(3) People must perform the job they are paid to do.
This puts point (2) from another angle, in terms of
efficient management of research and computing support;
(i) it is generally not optimal for research staff
untrained in computer support to attempt their own computer
support. The staff of the computer service are best placed
to efficiently perform their tasks, as they are trained to do
that, just as the molecular biologist is best placed to
perform research.
(ii) it is difficult to provide efficient management
of resources if people are performimg jobs they are not
meant to. Good computer support requires a considerably
different management regime from scientific research.
So, an attempt to manage computer support by research
management, i.e. if molecular biologists perform this
task, may well be inefficient, for example resulting
in suboptimal planning, provision of resources,
support staff training, and user training.
(4) Money is money.
Rich labs can set up their own in-lab facility (though
this may also be a second best option in the absence of
a local site-wide service [1]), but what of the rest of the
institution? As Reinhard said, they may still need to purchase
commercial software for their PCs and Macs, and pay for hardware
upgrades to run the software. Less well-endowed labs
may lose out, again deleteriously affecting the status of the
institution as a whole.
Also, as Reinhard says, remote services may still have to
be paid for, but even if they they are cheap you will not
be able to get optimal user support, which requires an
on-site element [1].
In conclusion:
Beat the cost-accountants at their own game, and keep
your local computing service.
Reference:
[1] D. Rouch & T. Littlejohn (1993)
What Makes a Successful Biocomputing Service, Binary 5: 50-53
also, Bio-soft (March, 1993)
Duncan Rouch
Molecular Biology Computing User Group, Birmingham, UK.
SEQNET/CCP11 User Documentation Group, UK.
