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).


Comments on this page:

From 99.236.3.205 at 2010-01-10 14:17:50:

Just commenting to say that this model works well outside U of T as well. I spent nearly 6 years as one of the staff members assigned as a point of contact to roughly 1/3 of the School of Computer Science at Waterloo, and I think overall, the system has been well-received since implementation. There are sometimes issues, but I think generally faculty members and grad students feel like they're getting their money's worth, which wasn't the case with previous setups.

MikeP

From 128.32.141.6 at 2012-04-23 17:54:42:

I have worked for two Universities that employ similar models. In both cases I was brought in by the research groups, not by IT. This meant that I had very little connection to and knowledge of the Core IT group. This was exacerbated by a lack of knowledge of the inter-workings by those that paid/bossed/worked with me.

I have twice been surprised to find new IT groups that claim dominion over my researchers, to varying degrees of absurdity (in both cases this discovery was after years of employment). This is also after I have attempted to find them and failed.

How is your department ensuring your Point of Contact people do not get wholly disconnected from the Core? How do you advertise your existence and services to your users?

-Lost

By cks at 2012-04-23 20:45:52:

At the employee level, the Points of Contact and the Core people work together fairly closely (and we all report to the same manager). We know each other and since Core provides core services like networking, Points of Contact frequently wind up passing user requests (and sometimes problems) on to us. At the same time I know that there are graduate students and research associates and so on being tapped by professors to provide support to their own groups, and we have very little visibility into that (we have some, since Points of Contact are supposed to be aware of everything that is attached to their internal subnets, but).

At the level of professors and graduate students, I'm not sure that we have a good answer. To an extent it depends on how much they use core services like our fileservers and our login and compute servers; some groups use them a fair bit but others are significantly disconnected and autonomous. Advertising new services in particular is a perennial problem.

(Core has a support website, but I suspect most people don't read it and may not even know it exists.)

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, View Normal, Add Comment.
Search:
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.