This is a first draft at service descriptions including "who's responsible for what." To be edited liberally. It falls on this side of fascist in this version. It's better to under-promise, but we need to soften this up a bit.

Classes of Service

Service Description

Central Responsibilities

Personal Responsibilities

Centrally Managed

Software: IS&T's standard Linux distribution, configuration, and software suite as deployed in IS&T computing spaces. OS and software has central management enabled similar to public student lab deployments. Hardware: One of IS&T's standard hardware configurations as specified and tested, for which software integration has been completed and approved by IS&T; basically hardware identical to the recommended and deployed public student desktops. Hardware was purchased by IS&T or an MIT department, and is owned by MIT.

Hardware working with current Linux distribution, configuration, software suite as deployed in IS&T computing spaces
Machine centrally managed for updates, patches, application, and service updates Machine and software will function similar to deployed student lab computers; All key services will be available and tested; End-user support available through IS&T; Basic customization support through documented options and packages; Basic troubleshooting and support of system, software, and configuration problems; In the event of software and configuration problems not recoverable through basic troubleshooting, a wipe and reinstall of the system

Limiting hardware and software customization to documented options that basically retain standard "image"; Supervising use of system including responsibility for uses of system by third parties

Personally Managed

Any other hardware or software configuration. Any hardware not owned by MIT.

IS&T will maintain some information of known incompatibilities with specific hardware, and hardware that is known to be likely to work. IS&T will maintain basic MIT-specific configuration information for key services and a few common distributions; IS&T will provide basic assistance for key services including pointers to documentation, fielding questions, and escalating service-side issues to service owners (not including service configuration issues unique to interactions a specific client configuration); IS&T will not be able to resolve issues not addressed by standard configuration and documentation, beyond applying a minimal level of effort

Extended troubleshooting; Adding, removing, or reconfiguring packages; Problem resolution; Configuring software to work with available hardware; Exploring hardware or software alternatives

Custom Hardware Integration

Sometimes none of the standard hardware configurations meet the need of a particular MIT use for which the "Centrally Managed" class of service is needed. It may be possible to add a hardware configuration to the list of standard configurations thought testing, tuning the specifications, and executing and necessary integration work. This is available as service from IS&T, in three phases:

  1. Assessment: results in an assessment of whether integration is feasible, an estimate of the effort involved, and an assessment of whether the hardware configuration would be of general use to the Institute; requires access to an example of the desired hardware configuration or resources to procure; will be scheduled as resources become available
  2. Standard integration: the model used if the assessment concludes that integration is feasible and the hardware configuration is of general use to the Institute; requires 50% of estimated resources to be funded by the requesting departmentwith the remaining 50% of estimated resources funded by IS&T; results in a new standard hardware configuration which will be supported as a deployed system for a period of 4 years from certification for desktop or a period of 3 years from certification for laptops; if integration is not achievable, determined by either a technical assessment during the integration effort or after 150% of estimated resources have been expended, platform will be deemed not feasible and effort will be terminated
  3. Unique integration: the model used if the assessment concludes that integration is feasible but the hardware configuration is not of general use to the Institute; requires 100% of estimated resources to be funded by the requesting department; results in a new standard hardware configuration which will be supported as a deployed system for a period of 4 years from certification for desktop or a period of 3 years from certification for laptops; if integration is not achievable, determined by either a technical assessment during the integration effort or after 150% of estimated resources have been expended, platform will be deemed not feasible and effort will be terminated

 

 

Custom hardware integration could be a real value-add for the community, but could also be a significant resource burden on IS&T.

  • No labels