Centralized and Distributed Support

January 2004Chuck Powell

Charles.Powell@Yale.Edu

Philosophically

• We think we’re fundamentally in the business of providing certain services centrally “better” (value, quality of service, etc.) than units can do on their own.

• The challenges are; which services, and how to convince the units we “really” can.

• “Desktop support” is one type of service where we think we can add real value, and we generally agree with units that the staff are ideally:– positioned in a distributed fashion– specific to the local environment

Centralized(ing) Services

• Network (including DHCP)• Credentials (netid)• Centralized authentication (Kerberos, Windows

Forest, & CAS)• Directory• Email• Web serving

Support at Yale is distributed

1-5 FTE staff 5-20 FTE staff 20-50 FTE staff

50-150 FTE staff

>150 FTE staff

>25 units (for example Architecture, Art, Divinity, Drama, Music, Nursing, some departments within FAS and Medicine)

2 units - Law & Forestry and Environmental Studies

School of Management

ITS-Med ITS (Central)

Carrots, Coaxing, and Collapses

• Although not exactly something to plan for, we get a lot of “business” when non centrally maintained services collapse or bad things happen with security.

• We never really try to win folks over with nothing but a stick.

• Our most common carrot is a trade for something else the school or department wants…

• Conversations (many) and growing confidence in our services are key.

Support in Arts and Sciences (www.yale.edu/fsp)

• Administrative Support is handled separately• Program is run at a departmental level and tailored to

each department• Program attempts to account for HW, SW, general

desktop support and instructional needs • Strong preference to “place” a local support person or

connect their person into our system• Annual formal conversations offer the opportunity for

adjustment and further customization• Faculty Support Program is the gateway to all our

other services.

3 Examples

• English – “Classic Model”, HW replaced on a four year cycle, local support person (50% grad student) and backfill from core professional FSP staff

• Computer Science – “Science Model”, they buy all their own hardware, we use all their allocation in support which in their case translates to an FTE who reports to us but “belongs” to them!

• MCDB – “Mixed Model”, changes every year but allocation is split between defraying their local person, buying HW & SW and piling on additional support they might need