Ryerson ITSDC: Labs and Infrastructure

This is not policy. It is a target to focus discussion on the issue.

Policies regarding the access to and use of Information Technology at Ryerson would need to address a number of issues regarding labs and infrastructure. The assumptions made in identifying these include the expectation that financial resources will never be abundant, that there will be competition among spending options and that there will be uncertainty regarding which expenditures provide the optimal return to the Ryerson community. Many, but by no means all, of the concerns centre on the differentiation of departmental and centralized facilities and responsibilities. That finances and campus-culture may come into conflict is a likely outcome of any policies in this area. Different departments have differing degrees of commitment to and dependency upon computing, with very different traditions for system acquisition and maintenance. Users of software for instance have very different needs from developers of software; established users have more outside contacts upon which to rely for advice or other support.

1. An initial issue is that of the facilities-planning process. With approximately 1100 microcomputers currently on campus (see attached inventory) and a useful lifespan of only about 3 years, there is a need for ongoing planning of machine replacements. Policies should be developed regarding priorities, platform architectures, timing, expediting etc. That machines and other hard and soft infrastructure meet campus-wide standards, and that acquisitions are coordinated to take advantage of comprehensive purchasing are seen as justifications for a centralized planning process. In order to facilitate this, a mechanism for planning that recognizes the various constituencies across the campus must be put in place, perhaps including committees to validate orders, set technical specifications and manage RFP's.
2. Among the responses to financial constraints is the quest to keep per unit prices as low as possible. Since the "economy-of-scale" principle seems to set a significant component of the price for equipment and licenses, efforts should be directed at fewer larger purchases. Not all acquisitions will benefit from this, however. Policies on whether low-end users' needs or high-end users' needs or both are provided should take into consideration the opportunities for bulk orders.
3. It will need to be established what the responsibilities are for departments and a centralized authority, such as CCS. Who does what with respect to all aspects of labs and infrastructure. What should be addressed, could consist of servers, routers, cabling, peripherals and other hardware, backing up and restoring, accounts administration, software and operating systems installation, upgrading and support, helpdesk management, software licensing, data licensing etc. Targeting of centralized support to user departments (along the lines of the LRC's organization) for some of these functions could be undertaken to facilitate the invoking of standards (including the identification and phase-out of archaic systems) and implementation of an efficient service with a customer focus.
4. The apparently natural tendency for departments to prefer autonomous labs acts counter in some respects to the financial and other arguments for centralized facilities. Among the issues presented for this are the specialized computing needs of individual programs, licensing agreements for software and data, maintenance and control of a discipline-specific computing environment, and accessibility to students. Policies to maximize access to computers should be adopted, with both remote and on-campus perspectives taken into account. If carefully planned so that available facilities match demand, then lineups and conflicts over scarce facilities should be minimized. On-campus accessibility would seem to be maximized if departmental labs were nearby other departmental facilities -- offices and classrooms. Centralized labs with more campus-wide generic appeal could be centrally located.
5. Policies should be established supporting partnership initiatives that result in reduced overall costs for labs and infrastructure. Release from other responsibilities to permit acquisitions and maintenance could result in the upgrading of all campus facilities, though an initiative to upgrade underserviced departments or programs could be a priority.
6. Although the focus of another initiative, policies that assure appropriate classroom technology should be developed. Each room (including labs, lecture halls and faculty offices) should probably have a network connection at least. Other rooms should be designated as requiring current technology, backing up this designation with a commitment of continued resources as necessary to ensure that the highest standard for the specified purposes has been maintained. This would require that specific facilities would be linked to specific student competency expectations. Centralized labs for instance would attend to word-processing, spreadsheet, database, graphics and networking capabilities, whereas more specialized labs would serve the various specialties.

The highest priority for attaining labs and infrastructure to facilitate the published statement of our Vision would seem to be a high-level policy and financial commitment to the best undergraduate computing facilities in Canada.

INFRASTRUCTURE:

CURRENT: - 16 Mbps Token-Ring RIN

- 10 Mbps to workstations/servers

UPGRADING: - completed by spring 1998:

- 155 Mbps ATM RIN - 2 FORE ATM switches + numerous Xylan pizza switches

- 10 Mbps to workstations/servers

- 100 Mbps to specific servers (central W71 servers only)

FUTURE: - 100 Mbps to MOST servers

- 155 Mpbs to specific servers/workstations

- all rooms (labs, classrooms, offices) connected to RIN

- access to Ryerson for all students, faculty and staff - on and off campus

LABS:

CURRENT:

1. Approximately 1,100 microcomputers in labs (this does not include SUN workstation labs.



2. Central Labs -- overseen by CCS:

W71C, MM, Comp Graph & CAD lab - 20 - IBM 75

- 2 - IBM 133

E130, X terminal lab - 36 - IBM Xterms

E135, microcomputer lab - 23 - IBM 20 Mhz

B405, microcomputer lab - 23 - IBM 20 Mhz

L393, microcomputer lab - 44 - IBM 25 Mhz

148 in total

W71, drop-in - 87 - Xterms/20,25,33 Mhz

L386, drop-in - 23 - 20 Mhz

110 in total

1. Private Labs -- THROUGH APG, chairs must submit current status.

FACTS:

1. Most labs are obsolete, both hardware and software -- majority 386/486 -- 20/25/33 Mhz.



2. Due to obsolete labs, pressure for access to current/high-end labs is beyond what can be satisfied.



3. Each year the demand of access, both for teaching and to complete assignments is growing within the schools that have COMPUTING in their curriculum as well as schools introducing COMPUTING into their curriculum.



4. Demand is for access to general purpose computers (word processing, databases, spreadsheets) and graphics/high-end processing (multimedia, CAD, GIS, statistics, etc.)

History:

Twenty years ago: Mainframe, totally supported by CCS.

Today: De-centralized servers and UNIX processors, central equipment supported by CCS, private support by school.

Tomorrow: Private, support by school for lower level, day-to-day support. CCS supports operating systems, RIN, backups and restores.

1. STANDARDS / ECONOMY OF SCALE

For hardware, software, when approproriate, acquire site licenses, bulk purchases through RFP.

Hardware would be three levels/vintages (e.g. 3rd -166 2nd -233 1st -266). Levels 1 & 2 labs and servers would be upgraded yearly. Level 3 labs would be replaced after 3 years.

Software would be two levels/vintages (e.g.. 2nd - current version, 1st - 1 version old).

Investigate using Super Servers versus server per lab. Super Servers would reduce human resource requirements. All Super Servers would access the RIN at 100 Mbps.

1. YEARLY PLANNING

Yearly (October/November) schools would submit the next years computing needs -- software and hours for teaching. Requests would be reviewed by a committee. As funds permit, sufficient labs would be build to satisfy committees recommendations.

Steps: validate requests & funds / technical needs to satisfy requests / RFP process to acquire

1. OUTLINE "WHO DOES WHAT"

a) server operating system

b) server backups & restores

c) accounts

d) software -- installation and support

e) hardware & peripherals

f) advising/HELP Desk

g) data

1. ACCESS

Convience of location.

1. - SERVER - operating systems and backups would be overseen by CCS

- Super Servers would be used to reduce human resource requirements

- access from RIN to servers would be 100 Mbps

- access from workstation to server would be 10 Mbps

- APPLICATIONS - applications would reside on server(s) and standards for access would be implemented.

- committee would determine applications - where possible standardization would occur.

- applications would be overseen by CCS

- WORKSTNS - repairs would be overseen by CCS

- ADVISING - overseen by CCS

USAGE - all labs would be timetabled, requirements would come from committee.

- committee would determine percentage used for teaching versus drop-in, some may be drop-in only.

PROS: - labs would be no more than 3 levels back in hardware and two levels back in software

- due to standardization for hardware and software -- costs will be lower

- due to using Super Servers and CCS overseeing back-ups -- a higher level of dependability will exist.

CONS: - schools with private labs may resent giving up funds and control over servers and applications.

OPTION 2 - CENTRAL/PRIVATE LABS

FUNDS - central labs - funded through CCS/VP Academic

- private labs - funded by schools

PLANNING - yearly (October/November) schools would submit the next years computing needs -- software and hours for teaching in central labs

- requests would be reviewed by committee

- sufficient labs would be build, within financial restraints, to satisfy committees recommendations

LEVELS - central labs - hardware would be three levels/vintages (e.g.. 3rd -166 2nd -233 1st -266)

- levels 1 & 2 labs and servers would be upgraded yearly

- level 3 labs would be replaced after 3 years

- central labs - software would be two levels/vintages (e.g.. 2nd - current version, 1st - version old)

- private labs - should try to stay as current as possible

SYSTEMS - central and private labs - computers would be purchased through RFP -- taking into consideration support issues.

SUPPORT

- SERVER - central and private - operating systems and backups would be overseen by CCS

- Super Servers would be used to reduce human resource requirements, cost to private labs would be prorated for server acquisition

- access from RIN to servers would be 100 Mbps

- access from workstation to server would be 10 Mbps

- APPLICATIONS - applications would reside on server(s) and standards for access would be implemented

- committee would determine applications - where possible standardization would occur.

- central - applications would be overseen by CCS

- private - applications would be overseen by schools

- WORKSTNS - repairs would be overseen by CCS

- ADVISING - central - overseen by CCS

- private - overseen by schools

- USAGE - central labs - would be timetabled, requirements would come from committee

- committee would determine percentage used for teaching versus drop-in, some may be drop-in only.

- private labs - would be encouraged to allow schools without private labs to use if unused time slots where available

PROS: - due to standardization for hardware and software -- costs will be lower.

- due to using Super Servers and CCS overseeing back-ups -- a higher level of dependability will exist.

CONS: - schools with private labs may resent giving up control over servers and applications.

- currency level of private labs depends on funds available.

- have and have nots continues to exist between faculties and schools.

- "poorer" schools will not be able to merge computing into their curriculums as they may wish due to limited funds.