The bridge

I'm going to break one of my personal rules today, and talk for a bit about what I do for a living. I've tried not to do this in the past, not so much out of a concern about being dooced, but more out of a general separation I have always tried to keep between my personal and professional lives. But I'm starting to feel like there are some things that I want to talk about that could actually help some of the communities I've been involved with both personally and professionally. 

As I mentioned in a previous blog entry, I've been at a few crossroads in my career. At various points over my career, I've stepped back to look at where I've been, where I am now, and where I'm going. Over the past few months, I've started standing back once again.  I've come to realize that there has been a constant in my career that has stuck around, despite the slight shifts in focus, that has only been highlighted at my current position: the bridge. I realize that I've been building my career on a very specific ability: standing amongst different communities, listening to them, and helping them communicate with one another. 

Communities are funny things. Inside a community, communication can work exceptionally well.  Get a group of literature scholars together and, while they may not agree on the use and application of specific literary theories or models, they certainly know and understand what those models and theories are.1 The jargon, as it were, doesn't stand in the way of the conversation. However, place that same group of literary scholars in a room with a group of web developers, and this is no longer the case; shared communication goes out the window.  In order to communicate effectively, they need a mediator.2

I feel like I've been building my career on that very specific ability: bridging communities. My current job has been as much about facilitation as it was web development and project management. CS and faculty had really strained relations because they couldn't understand one another.  it's unfortunate, because neither party was really in the wrong, nor did either have unreasonable requests. They just didn't understand one another and didn't possess the ability to express their wants and needs in language that the other could understand, and got frustrated as a result.

This is poison in any environment, but it can be especially troubling in an academic one.  When I started working here, I overheard one of the faculty quipping in response to a particulary nasty department meeting, "Never have so few fought so hard about so little." I've learned that this is eerily true; academics become academics because they are passionate about their field of study.  It takes pure passion to study the fellatory habits of fruit bats, masochism in Ulysses3, or the bending of spacetime around our planet. Academics are in the strange position of having the freedom to research while having to constantly defend the results of that research.

Of course, IT folk share that same level of passion for and knowledge of their field of study: information technology, web development, or systems administration.  It takes keen dedication to learn a new programming language, operating system, or technology.  In addition, these technologies are often built around constantly reinforced sets of rules and logic. Standardization is the norm in an academic computing environment, because you need to be able to manage all your services on a nearly skeletal resource budget. 

This passion and specialized knowledge gets both groups into trouble when they come together, however. Because they are highly knowledgeable in their respective fields, they often feel like that knowledge bleeds over into the others' area. 

A typical IT-academic exchange tends to go like this:4

Academic: "I need to be able to run this piece of software I found a link to in a sociology forum as part of my class."
IT: "We don't support that software."
Academic: "I installed it on my desktop, can't you just install it on one of your servers?"
IT: "No, we can't just do that.  Besides, this isn't on our list of supported software."
Academic: "I need to be able to have the freedom to do my research. I need you to install this on our server."
IT: "We can't support it, sorry.  Have a nice day."
Academic (usually thinks, sometimes responds): "Well, what use are you then, if you can't help me do my work? You're always standing in the way of what I want to be able to do like the bunch of control freaks you obviously are.  I'll just find a place outside of the university to host this."
IT (usually thinks, sometimes responds): "What flaky thing are you going to ask us to do next?  Don't you understand that we're trying our hardest just to keep things running smoothly without your crazy one-off project taking down our network?"

It often becomes just another battle in the artificial war between academic research and IT, where researchers are fighting for their right to conduct research using university systems, and IT personnel are fighting for a stable, reliable set of university systems that they can maintain based on the amount of resources they have available to them. 

Because both are passionate about, and focused on, their own work they are often a bit blind to the needs of the other party.  The researcher just wants to be able to do their research. They have a question they need answered, and need a way to be able to find that answer. They may have found this tool that helps them do it, but the tool itself often isn't nearly as important as the answer to their question.

IT needs to take some time to understand the request and where it originates, and find a way to provide academics with a solution they can actually use, rather than a half-baked kludge based on an entirely unrelated piece of supported software, just because it happens to offer functionality that, if you squint at it in just the right light, might provide similar functionality.5 

In short, IT departments need to remember that they are service providers, not gatekeepers. Without the academics, you quite literally do not have a purpose. You need to start asking yourself some questions when requests come in from academics that go against your established processes:

  • What is the academic's research problem, and what is the question they are trying to answer?
  • What tools do we have that the academic might not know about that give them the funcitonality they are looking for?  It's important when answering this question that you're not looking at it through the perspective of "Product X is really intended for Y, but has functionality that might be repurposed to do Z" but rather "Product X is really intended for Y, but also does Z well."  It's also important that an existing tool doesn't have a strong focus on an unrelated area.  For example, I wouldn't suggest Moodle for a dedicated blog site, but I might suggest using Drupal.
  • Is it possible to solve that problem with a more mainstream, stable, or easier to support piece of software?  Often, the requests that academics make for software are based on word of mouth or a quick Google search.  You, my friends, have a much better sense of Google Fu when it comes to software, so it's likely that you can find something more suitable to answer the academic's need. 
  • If you truly can't support the software, can you find an alternate solution for the academic? Is there an online service that they can use? Is there another way they can fulfil their need?  What are the risks of doing so, and how can you communicate that effectively back to the academic without sounding like a doomsayer?

In similar fashion, academics must be cognizant that in an institutional environment, there are very real limits to what can and can not be supported.  The IT department is concerned about having to manage yet another service on top of the several they already manage, and really wants to be able to do more with the tools they already have as a result. Although your request seems simple ("just put it on a server."), there are often several questions and issues that arise behind the scenes out of that request.

  • Can institutional systems even support the programming language and environment the tool was written for?  It's virtually impossible to run .NET/ASP applications within a linux/unix environment, for example.  Java-based web applications often come with unique requirements around Java Runtime version, which can often conflict with other services that have differing version requirements.  
  • What are the requirements to run this piece of software?  Can we meet those requirements with our current environments?  I came across a specific version requirement for PHP for one of the tools I wanted to make use of for the project I'm working on now. However, our environments only supported the version above and below that requirement, neither of which were supported by the software.
  • What other software is this piece of software dependent on.  As with the requirements, can we meet these with our current environments? Do those dependencies break other pieces of software on the system (this is especially important with Java-based applications)?
  • How much time is this going to add to your IT department's workload to do software updates and maintenance? IT is already looking after dozens of environments running dozens of different applications.  It takes time to stay on top of maintaining all those different elements, and ensuring that you are not exposing the instituion to breach, downtime, or loss of data.
  • If this software depends on modules for functionality, have the developers of those modules caught up to the latest version?

In my experience, when communicated clearly and without jargon, each group finds these questions eminently reasonable. It's just a matter of time to communicate effectively in the language they understand, and being willing to find alternate solutions to satisfy the request.

Sometimes it's useful to have a third party come in and act as that bridge, and translate for one another.  Over time, however, I think they can start to build a common language to discuss these questions and requests in a calm and reasonable way.

After all, we are all here to do the same thing: build our institution in exciting and innovative ways, which continuing to support the things that have worked well for us in the past, and continue to do so.

I'm curious about your experiences with this, both inside and outside academia, and both on the IT and consumer side of the fence.  Please register and leave a comment.

  • 1. Clay Shirky talks about this a bit in his articles, "Communities, Audiences, and Scale" (http://shirky.com/writings/community_scale.html) and "A group is its own worst enemy." (http://shirky.com/writings/group_enemy.html)
  • 2. I use this intentionally, because the person working to help these two communities communicate is equal parts translator and negotiator
  • 3. Do you think this was a user study?
  • 4. This is, obviously, an exaggeration. But only just.
  • 5. A very good example of this came when I was asked to provide a wiki for one research group. Because we didn't have an institutionally supported piece of wiki software, our CS department suggested installing Moodle, which had a wiki plugin. It wasn't understood that this added a very large, very obstructive set of additional features that were entirely unrelated to wikis, and was built to satisfy an entirely different set of requirements and workflows.