Computing Support Model Ideas

from July 1 CIT Directors' Meeting

This topic was discussed in some detail. Currently there are a variety of models for the deployment of distributed computing support at UVM, for example, those employed by Physical Plant, the UVM Store, CatCard Office, and Residential Life. Several other departmental computing initiatives are currently underway (e.g. Center for Health & Well Being and Sponsored Programs). It would be useful to have a model to decide which activities, in the interests of the University, would best be supported by CIT, which are best supported by distributed departmental personnel, and which are best supported by vendors (or other UVM service providers). This model would not necessarily prescribe a solution for every situation, but would provide guidelines and a common base of understanding for what CIT services might be expected (or not). Some of the determining factors that were discussed are:

Mission critical? In general mission-critical applications are best supported by a staff with the critical mass to handle ongoing operations in the event of staff turnover or other absences.

Cost? Frequently there are cost benefits to employing a shared support model (such as CIT provides) to avoid replication of services.

Coordination requirements? Often a local service provider is in a better position to coordinate IT activities within the department. On the other hand, a central service organization may be in a better position to coordinate activities among different departments and delivery of services to the campus community. Over-decentralization of IT service providers can cause fragmentation making coordination difficult and increasing institutional costs.

Control? In general control over the application and the information is best retained in the distributed operational unit since they are in the best position to understand its needs and functioning. Support of and control over the technology is typically best supported through a shared infrastructure (e.g. Client Services, Network Services, AIS, Telecommunications) from a consistency, depth, cross-coverage and critical-mass point of view. This does not mean that no technical knowledge will every be necessary in the department. (Analogs to the "telephone coordinators" and "chemical hygiene safety officers" were discussed.)

Budgeting, staff and other resources? Clearly these de facto issues will frequently determine whether a system is supported in the department, as a part of infrastructure or as a fee-for-service (internal or external). If the distributed department has the resources and the central organization does not (and fee-for-service or BCOs are not options), then the application will by default be implemented in the distributed unit regardless of other issues -- and vice versa. In general this is a matter that needs to be solved at a higher level. Once the other factors are considered and the optimum division of duties is determined, ideally the necessary resources (if they exist) should be allocated to the place where the application can best be supported.

Continuity? In general combining support staff in a single organization can provide better continuity of support during absences or staff turnover.

Checks & balances? There can be synergistic benefits to shared support (technology by CIT, application by distributed unit).

Expectations? It is essential that support capabilities and expectations be reconciled prior to undertaking a significant project.

Standards? Standards can be followed with any model, but are more likely to be followed when the application technology is supported by a central infrastructure.

Priorities? Like budgets and resources, priorities can result in an application being deployed and supported in the decentralized unit. Untenable bureaucratic delays can motivate the decentralized unit to find and allocate the necessary resources (with little regard for other issues) if their needs are not give equitable priority in the supporting unit.

Institutional liability? Where confidential or sensitive information is involved (e.g. grades, personnel or health records), there may be a reluctance to outsource these functions to an external service provider, or in some cases even an internal service provider.

"Core function"? The factors that make an application a "core function" tend to be the same ones (above) that make it amenable to shared (central infrastructure) support.

 

Edited by Roger Lawson