By: Anya Schiffrin

In the decades I have been at Columbia one thing has gotten worse: the number of software and platforms we use to do our business, communicate with each other and with students. Off the top of my head: SSOL online for submitting grades, Slate reader for admissions applications, Stellic to approve course choices, Org Sync which got acquired and was replaced by CampusGroups, Courseworks which became Canvas, Facebook, Linkedin, Whatsapp to communicate with  students, Bedework to make calendar announcements which then have to be supplemented by endless emails to different departments because it’s not clear that anyone looks at Bedework. Eventbrite and other sites to book tickets and for a while Splash too. Now we’ve got Zoom and Microsoft Teams and the Google products. Recently the University moved to Concur for travel reimbursements.

A sign of how bad things are is that when the pandemic hit, no one turned to the ed-tech platforms to help us, NYU’s Vice Provost for Educational Technologies, the famous writer and thinker Clay Shirky, notes. Rather we all went straight to Zoom and Google.

“After all the hundreds of millions of dollars we have spent on ed-tech, when we had five days to pivot not one person in my shop tried to call the ed-tech vendors to ask for help,” Shirky said in an interview for this article.

Having been at SIPA for more than 15 years, I’ve often wondered why we have so many different sites that don’t work together. Would it not be possible to have one end-to-end system that we can use for registration/courses/faculty approvals? Turns out there’s a lot of reasons why there are no easy fixes for our travails.

For starters, there isn’t a vast amount of growth in this sector, experts say. According to one IT administrator there are only about 70 Universities that can afford to buy the top-end software. These include New York University and Columbia University who spend tens of millions a year on the products but it’s not a fast-growing market. “It’s more like an annuity,” Shirky said.  “Thus, we don’t get the best companies competing to sell us really comprehensive solutions.”

Nor is there much competition in this fragmented market. Rather, each area has one or two companies that dominate and so have little incentive to improve their products. As well, much of the software was designed decades ago so instead of blowing it up and starting again, it gets tinkered with around the edges. For Universities the problem is even worse because the platforms are used constantly and there is no way to take them offline for six weeks so they can be replaced. The average contracts are 5-10 years so in the beginning, the sales people seem accommodating and willing to customize but later they stop returning phone calls. “Academics buying software are sitting ducks,” Shirky said.” The companies sell to people with almost no perception of what users need.”

The lack of interoperability is a common problem in the medical sector too, where companies have made it a point to try and hold on to data and raise switching costs. These firms also make it impossible for systems to talk to each other. Indeed, author Paul Ford, CEO of New York based firm Postlight and Wired magazine columnist who has written about bad software, told me in an email interview that both sectors have terrible software platforms:

“The situation is sort of the classic procurement problem: Buyers strongly favor customizable platforms over building anything themselves. These platforms are sold to university IT with ten-year contracts. The up-front costs are low and the risk is also pretty low, because UPenn or Ohio State is already using it, etc., etc. Over time the vendors refuse to do anything too novel and more of the university's data gets stored on their servers; the lock-in effect is real and there's assumed to be no escape. Since the system won't expand to meet the needs of the organization, a new system has to get layered on. Now you have to log in everywhere so we'll add a THIRD system to manage your logins. Except it doesn't always work. Etc. The IT department, battered by decades of relentless complaining, has learned not to really consult their customers but to just deliver things and run.

The awful part is that all that horrible software is not really a risk to the university; your suffering and annoyance ultimately will not lead to a reduction in enrollment and no one will get fired from IT because you hate Canvas or Blackboard or CourseWorks. However, now that everyone is remote everything is far, far more acute-feeling and the ability to do things informally or get someone to help you when it breaks is gone. So it's just worse for everyone,” Ford said.

Emily Tavoulareas, who teaches TMaC’s course on Human-Centered Design and who was a founding member of the U.S. Digital Service at the Department of Veterans Affairs during the Obama administration, agrees that procurement is a difficult problem for Universities.    

“Modern digital technology (or software) is designed and developed in a way that is fundamentally incompatible with traditional procurement. Procurement processes were largely created for a world in which the entity procuring something knows exactly what they want built, and can define it in ways that can be verified. Modern software is not developed like that. It is virtually impossible to know exactly what the final product will look like, because the details are dependent on variables that are typically unknown at the start of a project. Trying to procure modern software through a traditional approach is trying to fit a square peg into a round hole, and that does not set projects up for success," Tavoulareas said.  

Universities are also a special case because they are so decentralized. Different departments or programs or schools buy what they need to address one particular problem, without thinking of the burden on users, or how it fits in with the rest of the school. So we end up with a patchwork system. A couple of examples from SIPA: the Dean who wanted us to start using Orgsync left soon after we signed the contract and then her replacement decided to replace it with CampusGroups-- an independent company that signed  a five year contract with SIPA in 2019 and  bills us approximately $20,000 a year depending on our usage. This is typical of the ed-tech admin market: lots of small companies, that do one or two things and charge about $20,000 a  year.

These companies come and go but no one phases out their software even after it becomes outdated. Administrators buy the programs they need for the activity they do without thinking about the larger implications for the users. Administrators at Columbia University note that the University spends tens of millions of dollars a year on software. “We could reduce the overspends a lot if we didn’t keep buying whatever feels good from whatever vendor,” one said recently.  

So one solution for Columbia could be to give the central IT office far more control over the individual schools’ purchasing decisions. Currently, communication is done through two governing bodies: the Academic Technology Leadership Group and a leadership council. However, the administrators at the schools blame the central leadership for not consulting and not taking the school’s needs into account.

 Should Universities band together and create a common platform? Some analysts say yes but note that the coordination problems seem insurmountable, as each institution is has its own  idiosyncrasies.

“Academics think we are special but the only way we are special is that we are worse off. We are special because we are worse off.” Shirky said.

The Columbia IT office declined to speak on the record. Columbia procurement managers have also, in the past, declined to say what particular contracts cost including the contract with Concur which is being used instead of the old TBER forms. They note that there are no available figures for the overall spending on educational software by the University as each school has its own spending habits.

—

Anya Schiffrin is the director of the Technology, Media and Communications specialization at SIPA. This article is  part of a series on software platforms at Columbia.