The department's model for providing computing support

January 6, 2010

In many university departments, there's a constant tension between working on the computing infrastructure that is used by the entire department, and working on things for individual professors and research groups. To put it more concretely, do you work on upgrading the departmental mailserver or do you set up Professor X's new cluster that just got dropped off at the loading dock?

(This tension is increased when Professor X's grant funding is helping pay for computing support, as it often is. Professor X may well feel that, well, she'd like some of what her money bought. Now.)

Locally, we (the Department of Computer Science) have evolved an interesting approach to deal with this problem that we call the 'Point of Contact' model. In this model, departmental computing support is split into two parts, Core and Points of Contact.

(There is a third and entirely separate group that supports undergraduate Computer Science students.)

The Core group is responsible for all of the common departmental infrastructure; we run the network, the firewalls, the general login servers and the fileservers, the general user webserver, the mailserver, and so on. It's funded from base budget funds, and does whatever the departmental computing committee thinks should be centrally provided.

By contrast, each Point of Contact works directly with specific research groups and researchers (and their grad students) to do, well, whatever those professors want them, whether this is setting up compute clusters, configuring Windows machines, or building custom programs for grad students. Points of Contact are paid for the grant funding of their professors and research groups and effectively work for them. While it's a departmental mandate that everyone has a Point of Contact (and helps pay for theirs), it's up to the research groups to decide things like how senior a person they need and how much time they can pay for and so on.

Points of Contact are called that partly because they are everyone's first level of contact for all computing support; the Core group is not supposed to deal directly with users. Instead, people go to their local person (most of the Points of Contact have office areas that are physically close to most of their professors and grad students), their Point of Contact does the initial troubleshooting and diagnosis, and only then is the distilled problem passed to the Core group if it turns out to be a problem involving Core stuff instead of a purely local issue.

(As you can imagine this works slightly better in theory than it does in practice, although it actually does mostly work in practice.)

From my perspective, I feel that this does two really useful things. First and obviously, it solves the 'what do we work on' problem; Core works on central things and Points of Contact work on whatever their professors want them to. As part of this, I think that it makes professors feel that they really do own and control what their grant money is buying; while they have to spend it, they get transparent and direct results for what they spend.

Second, it personalizes the computing environment as a whole. Computing and support doesn't come from some faceless or hard to remember revolving group of people that you deal with at a distance, mostly through email. Instead, it comes from a specific person that you know and that you deal with all of the time, frequently in person (and certainly it's expected that you can drop by their office and talk to them directly), and they're your agent (or at least your professor's agent) when something needs to get done beyond them. In a visceral way, they're your person.

Now, the necessary disclaimer: I had nothing to do with coming up with this model; it was developed before I came here. I'm just writing it up for WanderingThoughts because I think it's nifty (and a cool solution to the overall problem).

Written on 06 January 2010.
« Some thoughts on battery backup for RAID controller cards
A theory on why most browsers control their own list of CA roots »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jan 6 01:01:51 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.