Main Nav

A Systemic Model for IT Economic Sustainability

Tuesday, January 12, 2010


This ECAR research bulletin explores the options available to IT leaders in higher education to reduce costs associated with technology expenditures at their institutions. It lays out a framework for addressing cost reductions in ways that lead to recurring savings and strengthening some core capabilities while minimizing the use of temporary measures that reduce service, weaken morale, and borrow from the future.

Citation for this work: Voloudakis, John. “A Systemic Model for IT Economic Sustainability” (Research Bulletin 1, 2010). Boulder, CO: EDUCAUSE Center for Analysis and Research, available from

Download This Resource


I reference Upton Sinclair's pithy quote:

It is difficult to make a man understand something when his salary depends upon his not understanding it

and follow with Einstein's definition of insanity: 

Doing the same thing over and over again and expecting different results.

These quotes fall uncomfortably close to some of the items suggested here:  Do the same things better, do them more efficiently, charge for them, organize them better, communicate about them better, but actually changing anything...?

I see very much the same swirl of activity locally, where we are consumed by great hurricanes of centralization, organization, consolidation, and groupthink. 

I'd suggest a few things that weren't mentioned in this report, which goes to some length not to mention any specifics.

- Consider Open Source Software (OSS) applications, especially for anything with server in the name.  Consider shifting services not to virtualized Windows servers, but to Linux servers if possible.  Feel free to virtualize them. Desktops are much trickier - see the Thin Client stanza below.  There are many OSS applications which are not only free, but arguably equal or superior to proprietary implementations.  Evaluate OSS apps based on what you /need/, not on a feature list.  Do you really need a wiki and calendar  on your ticketing system?  Maybe you do.  Maybe not.

- Consolidation and standardization is great if it works in the long term, but consider what happens when you consolidate on a proprietary  backup product for the institution, only to be shocked (SHOCKED!)  when the price suddenly increases tremendously after a few years of integrating it across campus.

- Standardization works well when it works well.  Other times, it can be a black hole that many hours are wasted in trying to sidestep.  If you're going to consolidate and standardize, the decision to do so had better be well & publicly rationalized so that the decision doesn't come back dragging chains.

- Hire people who have a deep understanding of how IT works and who aren't afraid to Do IT themselves.  The extra $ will go a long way to making things run more smoothly and cheaper in the long run.  Maybe the short run.

- Analyze your depts and classrooms and see if any can be converted to using Thin Clients (especially using Open Source software) on robust servers.  It should save on energy support, security, and upgrade costs, IF there's a technical feasibility.  there may not be.  Thin Client Computing is the other side of Cloud Computing, so if you're enthusiastic about one, you might consider the other.

- Publish once, distribute electronically.  We're STILL putting paper mail in mailboxes!  Seriously, is it worth $10K to your university to have the Chancellor's Holiday greeting printed & placed in every mailbox?  He may be a nice guy/gal, but I'd rather have that $ go to keeping a janitor working.

- Hire database programmers who can tame and integrate the spagetti DBs that tie your IT into knots.  Even a small DB consolidation can save hundreds of hours. of clerical work  and then 10s of hours editing the mistakes out of that clerical work.

- Insist on documenting everything electronically.  If it isn't doc'ed, it didn't happen.  Put those docs into a wiki or revision system so older versions can be tracked.  Yes, there are very good OSS revision systems. Reward people who do doc. Dock those who don't doc.

- Profile  your ticketing system logs and assign people to address the things that cause the most reports.

- Re-use code. Use already validated code if possible.  Learn how to search code repositories. Only if necessary, write it yourself. And if you do, write once, use many times. And you can't do that if the code isn't doc'ed and made available via a search engine.