A few years ago I participated with Educause in writing about reviewing software and managing alternative sourcing at Oakland University. We marveled in that we looked at over 25 pieces of software in a year, and most were not coming through traditional project methods. We had to review our purchasing process. This past year the university community looked at over 325 pieces of software, that we know about. We've done pretty well at making sure we are part of the purchasing process so that we avoid redundant purchases and software installations and support aren't unexpectedly dropped in our laps. Some software applications are installed on campus, and some solutions are hosted. Some are desktop installs, some are server installs, and now we have the App family.
Nevertheless, there is an emerging issue about software support. Obviously, my staff of 33 IT professionals cannot be experts on supporting over 300 pieces of software. The university cannot hire a system administrator or application support specialist for each piece of software. Our traditional support expectations do not scale with that volume of purchases. We can't even be the sole-vendor contact. Yet I had an uncomfortable situation last week where a senior staff member told me that calling a vendor for support was "not a lean process."
In discussions with my staff, we've identified about a dozen key software systems that we've installed where we only offer hardware and operating system support. There may be a disconnect between the services we offer and the expectations of our community.
I'm trying to put together tiers of support for software, something like:
- Outsourced. Contacts go directly from client to vendor. Central IT gets involved for contract review and assists with resolution in technical disputes.
- Campus install in datacenter with full support.
- Campus install in datacenter with some support.
- Campus install in datacenter with only operating system and hardware support.
- Departmental server install.
- Local device install.
As I'm looking at this, there is a developing support matrix. In addition to location and local support resources, we also have to look at server, storage, operating system, web server applications, identity access management, database management applications, code management architectures, security applications, backup services, and the actual software application. Server and storage architectures are a lot more complicated to manage with the virtualized environments we now install.
In some cases our central IT operation provides and supports the entire list. The closest is our ERP implementation, even though we do push using the vendor support options (including mailing lists and online community) before contacting us. In other cases, we split the work with another unit; for example, for Moodle, we provide the server, storage, operating system, identity access management connection, security applications, and backup services. Our E-Learning operations does the rest. We jointly work on tuning.
In other cases, particularly for research, we are hosting hardware and really not doing much else.
The issue we see emerging is when a software package starts locally, in a department, and gains adoption. We then need some sort of escalation and approval process to move the software to a support model. A few years ago we looked at this from a server support model, with levels described on our web site. We really need to rethink this for tiers of software support, and the governance model that moves a software solution to a higher tier of support. This needs to be logical and rational. We need to include the staffing needed to provide support in the evaluation. That piece is really missing, as we've been resourced constrained so long.
We can't keep adding solutions to the VM architecture without analyzing the impact on staff resources, and we haven't fully identified the impact on staff. We can respond to a new server request with agility in the VM environment. When we do so, we need to be clear that it doesn't mean we can answer questions about the software internals or how the application really works. As we get a more and more complex virtual environment with expanded storage and complex disaster recovery scenarios, we need systems engineers and storage architects, but these additional staff will still not be able to answer the questions about how the application really works. Then we get a community disconnect; we got additional technical staff, but the client support expectations may still not be met. We aren't there yet, but we seem to see new challenges for communications, particularly communications needed to justify additional resources.
Our path is not yet clear, but we are thinking about it.
