VADMS and Other Horses

Tue May 18 15:34:00 EST 1993

VADMS and Other Horses

>Message-ID: <INFO-GCG%93051213283788 at UTORONTO.BITNET>
>Date:         Wed, 12 May 1993 10:27:00 PST
>From:         "Steve Thompson: VADMS genetics" <THOMPSON at WSUVMS1.BITNET>
>Subject:      Not to beat a dead horse, but, more VADMS ...

The proposed change to the VADMS biocomputing service is a complex local
problem but involves clear general issues about how a biocomputing service 
should be run, as Steve pointed out previously.  VADMS seems to fit the 
view that "if it ain't broken then don't fix it", but the budget blues 
and some institutional logic demand otherwise.

I present selected sections of the administration response included
in Steve's posting, and comment on the proposed action.  I look here 
at three major issues that are relevant to many computing services: 

	(1) whether the service or an education/research department
	should teach the science involved in the computing methods; 

	(2) whether an important front-line user support position should
	be eliminated to help with reducing the institution's budget, and
	the role of institutional politics in this;

	(3) charging for services.

>In response to the onslaught of support letters Central Administration sent the
>following political no-speak announcement out to all whom sent letters in:
>        From: WSUCSC PROFS Administrator
>        SUBJECT: VADMS Reconfiguration All PROFS News Announcement


>    Thus, it became apparent that the original mission
>    developed for the VADMS Center, one of research and service, had now
>    shifted to service and teaching. 

That is a typical piece of institutional logic, which argues for 
at least a change in funding source, and in addition apparently justifies
hiving off the education function of VADMS.

>                                       And since ORU's do not have the
>    academic oversight appropriate for teaching functions, it was our
>    judgment that the Center's teaching function be shifted to an academic
>    unit such as the Department of Biochemistry and Biophysics.

Who should perform the teaching?  This is a central efficiency/budget issue.  
First we must define the two types of teaching involved:

	(1) Training molecular biologists in how to use the complex array
	of programs and services offered by the computing facility;

	(2) Educating molecular biologists in the science relating to the 
	programs, to help them set appropriate input parameters and interpret 
	the results; in other words, to integrate biocomputing methods
	into the scientific research these people are carrying out.

The computing service must be responsible for training molecular biologists 
to use the facilities, since this is where the relevant expertise is centred
and where feedback must return for maintaining the service as responsive to 
user needs [1].   

For the second type of teaching, educating in the science involved, there
are related efficiency and budgetary reasons why this is usually best 
performed by the research/education departments of an institution, and not 
the computing service:

	(1) Departments have facilities and support for educating.
	An education need requires proper recognition and support for
	it to be properly dealt with.  Further, the collective educating
	skills of a department can be called on and centralized
	education brings economies of scale.  Department-based
	biocomputing education may also be better integrated into the
	general education of molecular biologists than that from an
	interdepartmental computing service. 

	(2) Departments may get funds directly for educating, perhaps
	in proportion to the number of students. In contrast an 
	interdepartmental computing service normally does NOT bring in 
	education funds.  

So, for an institution that has both research and education functions, 
training for how to run programs is usually most efficiently performed by 
the computing service and educating in the science of the computing methods 
by the departments.  'Most efficiently' can be defined as doing the best 
job given the available resources.  Thus when there is a squeeze on 
budgets it may be even more desirable than normal that the two types of 
teaching are divided as suggested.

For a site where the two teaching types are not yet in place they would 
likely be best divided.  In contrast, the decision is not all that clear cut 
if the computing service, such as VADMS, has a successful past history of 
teaching in both areas, due to favourable local factors: "if it ain't broke 
then don't fix it".  

It is unclear from the administrative response about VADMS whether they 
understand the difference between the two types of teaching.  Assuming 
they only plan to transfer the science education type of teaching from 
VADMS to an academic department then this appears to be not an unreasonable
decision.  An underlying consequence of transferring some functions from 
VADMS to an academic department is that it renders less drastic the affect 
on computing facilities of eliminating one of the staff positions at VADMS. 

Thus we can conclude there are two reasons for shifting the science 
education function from VADMS to an academic department: (1) the notional
higher efficiency of education by an academic department; and (2) reduced 
effect on performance of the computing service by a potential staff cut.
Both reasons provide enhanced justification when the aim is to
reduce the budget.  Such reasoning may apply to other computer centres 
in a similar position.
In counterpoint, a non-teaching, research-only, institution would need a 
highly integrated service and education/training facility, as occurs for 
example with the biocomputing service of the Agricultural and Food 
Research Council (AFRC) in the UK.


Having argued that service/training and education functions may best be 
split where an institution has education facilities, however, VADMS shows 
the advantages of highly integrating these functions.  This supports the 
argument that when the education and service/training functions are 
split there must be a close liaison between the two.  This is not all 
that easy to do, and requires some imagination and commitment.  
One type of solution revolves around the education personnel spending 
time in both their home department and at the computing service.  Also,
appropriate course units can be jointly run by training and education
personnel.  (For a larger service than VADMS the converse can be useful, 
to place user support personnel from the service for part of their time 
in the academic education/research departments.)


>    In the meantime, we value your
>    ideas and counsel on a future course of action--one that will assist
>    the University with its budget shortfall without extraordinarily
>    depriving WSU faculty and students of needed services.

Unfortunately, but not surprisingly, the 11th commandment holds,
the budget is always the bottom line.  To negotiate with an
institutional administration you have to speak their language.
Since computer services in general receive no funds for education
or research it is difficult to negotiate directly.  Without
self-funding such services are dependant on institutional political 
support to gain funds from the institution.  So, maintaining an 
interdepartmental computer service requires interdepartmental political 
support. Mobilizing molecular biologist users on-site as well as their 
departmental heads to support the facility is important [1].

The dangers of underfunding a computer service, and in particular
eliminating front-line user support, have been pointed out previously [2].  
However, for VADMS the Systems and Computing unit fund Susan Johns'
molecular modelling support job, and they have suggested one of the 
two jobs should go.  It seems therefore that the modelling support might 
not survive without some good on-site political support.


>    ... VADMS has not been successful in attracting research funds or
>    in instituting a system for recovering partial costs through user fees,
>    despite encouragement from administration.

They have you here Steve :-( , even if it was impractical for VADMS
to introduce user fees. Apparent recalcitrance on the part of the 
organization being reviewed is a standard political tactic to justify 
making the changes the reviewers want.


>    To make up the difference between the $51,944 and $40,000, we
>    suggested a $100/year user fee for the >100 users on campus and
>    elsewhere. This fee might be assessed once yearly like a subscription
>    service fee ....

This is a reasonably mild charging strategy, given the five general ways
to obtain funds for a facility (with no direct research or teaching
derived income). These are listed in order of increasing effect on 
individual molecular biologist users:

	(1) Central subscription;
	(2) Departmental subscription;
	(3) User subscription;
	(4) User charged per service, but with free time (to promote learning)
	(5) User charged for all services.

$100/year for a molecular biologist is not a lot, more like an introductory 
offer to smooth the way.  Expect a significant increase next year.

Several comments in the discussion about VADMS have been made to the
effect that general charging for computer services is inevitable.  This
may be so, however, it is important to keep in mind there are different ways 
to charge user molecular biologists, and these alternatives have differing
affects on the efficiency of the scientific research being supported by the 
services.  Some strategies have more deleterious consequences for research 
efficiency than others [2].  We must be prepared to argue whether charging
is necessary, and if so, for the best choice of charging strategy.

Well, Steve, this may be not all to your liking but I hope it helps.

Duncan Rouch
Molecular Biology Computing Group, Birmingham UK.


1.  Duncan Rouch & Tim Littlejohn (Bio-Soft, March 1993;
	BINARY, 1993 5:50-53).  What Makes a Successful Biocomputing Service.

2.  Duncan Rouch & Tim Littlejohn (Bio-Soft, May 1993;
	BINARY, 1993 in press).  Future of Academic Biocomputing Services.

More information about the Info-gcg mailing list

Send comments to us at biosci-help [At] net.bio.net