At first, this post started out as commentary about the challenges that schools of about the same size as Santa Clara University face re: technology, infrastructure, and other needs in relation to the available resources. That, in turn, would lead to some discussion on how to best address such opposing forces. This was fundamentally about how Santa Clara was just big enough to need enterprise-level services but not quite big enough to have the staff to maintain such systems, especially over time.
However, I found myself having a terrible time writing because I eventually realized that this isn’t about the size of school. Whether your institution is a research or small liberal arts one, state or private, funded primarily by endowment or tuition, what fundamentally matters is operational dollars per capita. (DPC)
In other words – for any one (relatively large) project, the issue of size vs. resources is about how much money is available per student/faculty/staff/overall user group.
On the one hand, this sounds really obvious. Sure, if one has less dollars, then it must be less dollars per person. But if the project is small with, say, 100 users, then it’s possible that even a small school could get a research grant that yields high DPC. Which means resources are likely going to be sufficient. Also, universities of roughly the same size could have wildly different ratios, leading to completely different environments. Santa Clara University and Stanford, for instance, differ by only 1000 or so undergraduates (SCU being about 5400, Stanford 6500). Yet Stanford’s huge endowment, research funding, plus incoming tuition make for a much higher DPC figure, on average, than is the case at SCU.
Both SCU and Stanford are “big enough” to need a large scale ERP like Peoplesoft. Stanford has probably 25 systems administrators in their overall group, not counting the database administrators and storage administrators that help round out the PS operations. SCU has far fewer. Peoplesoft itself is scalable – there is likely little difference between managing 5500 students and 2000 or so faculty and staff at SCU vs. 6500 students at 8000 faculty and staff at Stanford, in terms of the software. But management is not scaleable in the same way. It might take 10 admins – systems, database, and storage – plus a handful of others (security, data center managers, etc) just to get PS up and running. At Stanford, because of a much higher DPC figure, will always have that number available, plus more to make the process more and more efficient. SCU might have just barely that number of staff to begin with and once other projects are considered then, in reality, staffing is insufficient.
Dollars per capita. That is the problem, and the “resource shortages” that it produces in institutions with low DPC go much further than simply having enough staff for a particular project. The shortages in one department lead to decisions to cut back here, eliminate a service there, etc, that another department (perhaps one in the same overall organization) actually needs for its constituents. So now low DPC has created a spiraling, self-reinforcing interdependency of inadequacy that is no one’s fault, but must be arrested at some point.
Case in point:
- Novell Groupwise e-mail system is managed by Networking and Telecommunications Group BU
- due to staff shortages, NTG has decided that the feature that allows standard ActiveSync connectivity (Mobility Pack) for devices will not be installed.
- Service Center BU has identified that providing connectivity for devices such as iPhones and Android phones is a needed part of their portfolio
- The devices support ActiveSync natively, but of course Groupwise does not. Service Center BU has to purchase and manage a third-party product that acts as middleware and is close to but not quite perfect ActiveSync functionality.
The result: most features work on iOS, Android is hit or miss if it’s anything other than stock, original versions of applications (AOSP), and on both users find certain features missing, or mishandling of events or contact details. I personally have had to basically hack both of the Android phones I’ve had so far in order to get them to work (even though the first one I had is specifically mentioned on the third-party vendor’s site as being “certified”). One of my staff that uses an iPhone who eagerly agreed to be the iOS support person has learned that there are, in fact, a few quirks that he has to help users with.
In this case, because of DPC being low for both groups, neither is able to take advantage of scalability or other options and work together to provide an identified, needed service via tools that are actually already built into Groupwise.
Let me make this disclaimer now – this is not a criticism of SCU Central IT. It is indeed very tempting to point fingers when I have a faculty member doing just that at me because the mail app on the iPhone isn’t working “as expected” or because that professor cannot buy that Android phone he or she wants because it is not compatible. But I don’t think it is right to blame either group, or anyone in those groups, in Central IT.