Requirements

In 1994 Green calculated that the average American University made available 3.5 hours of workstation access to each university student per week (http://ericir.syr.edu/Projects/Campus_computing/). By this standard Ryerson, with roughly 12,800 full-time and 1,822 part-time students (ignoring C.E. ) may, depending on one's calculation, already have enough campus workstations. Ignoring the fact that there is contention for systems during peak periods:

14,622 students * 3.5 hours/week = 51,177 hours of workstation access/week

With Ryerson's labs open from 8 A.M. to 12 midnight at roughly 50% drop-in (vs day and evening class use):

6 days * 8 drop-in hrs/day = 48 hours available drop-in access per week per machine

so that we should only require:

51,177/48 = 1066 machines on campus.

On the other hand if you only take 50% of the time available from 8 A.M. till 6 P.M. (30hrs/week/machine)

51,177/30 = 1706 machines required on campus.

To meet the American University average for 1994 Ryerson would need a total of something (depending on how the machines were scheduled and expectations for student usage) between 1066 and 1706 machines. In the 1997 national Survey of Information Technology in Higher Education Green shows that 33% of all US University courses require E-mail access. This is up four times from the 1994 figure of 8 percent. Internet access required by courses is at 25% up 1.45 times from the previous year. Multimedia resources required for courses has grown 1.67 times from 8 to 13.4 percent from 1994 to 1997.

Estimates of the number of computers per student required by universities vary considerably and usually do not include departmental and program labs. Central Michigan University (http://www.cmich.edu/~infotech/feemodel.html) estimates a publicly accessible workstations per 15 students are required. On the other hand, the University of Montana set a target of a workstation for every 40 students in 1992. At Ryerson this would translate into 975 and 365 publicly accessible machines respectively. With the tremendous increase in E-mail (for example Ryerson has over 11,000 active student E-mail accounts) and Web usage by students an extremely conservative estimate would be that we should offer at least twice the workstation capacity than the US average in 1994. In this case, including all "public" and "private" labs Ryerson would have to provide between 2,132 and 3,412 student workstations.

In 1997 Ryerson had roughly 1100 student accessible machines on campus. Line ups in the lab, student complaints, and Track and ACAC requests all demonstrate that these do not meet the current demand. Other sections of this document describe the dual problem of exploding usage and pent up demand by faculty who would like to use E-mail and other computing resources but will not do so until reasonable access for their students is available. Of the 1100 machines Ryerson makes available roughly 230 are general purpose systems available from CCS. No requirements analysis has been done on campus to determine:

• the number of workstation hours the average student requires;
• the number of workstation hours available by program for each Ryerson student;
• the number of specialized (usually higher-end) program-specific workstations hours are required for students in every program;
• the number of specialized hours actually available to each student.

In light of this it is very difficult to define a set of reasonable requirements for access to Ryerson workstations and other related resources. However, it is possible to demonstrate that the University cannot afford to provide for the computing needs of all students out of its own budget. Considering the intense use of computing in certain areas in Ryerson, and the demand in our labs, taking a value of 6 workstation hours per week is clearly not unreasonable. In fact it is almost certainly too low and would only represent about 15% on average of an academic 40 hour work week.

14,622 students * 6 hours/week = 87,732 hours/week

At best we have:
6 days * 8 drop-in hrs/day = 48 hours per week per machine

87,000/48 = 1827 machines required on campus.

According to figures from UNC-Chapel Hill (Departmental Budgeting for Information Technology: A Life-cycle Approach by John L. Oberlin at http://www.cause.org/information-resources/ir-library/text/cem9424.txt ) it costs $3,257(Cdn dollars) to maintain and operate each networked computer per year. If Ryerson were to maintain another 700 machines with a three year replacement cycle it would cost the University an additional $2,279,900 per year. This ignores the fact that Ryerson is not spending $3,257/year per machine in its existing labs and so the vast majority of the machines on campus today have exceeded their useful lifetime and must be replaced as soon as possible.

Funding Formulas

Like so many universities, Ryerson has seen declining funding and exploding information technology demands. In the past, the University has not established base budgets for computer labs. Instead, Ryerson has built labs, such as the major purchases following the recommendations of the New Systems Committee in 1992, without establishing budgets to keep those labs current or to replace them. This is not unusual for universities. In Green's 1997 survey only 30% of universities had base IT renewal budgets (up from 16% in 1990). Consequently, the percent of universities requiring mandatory IT student fees have risen to 57% in 1997 demanding an average fee of $140. Unlike other capital items such as buildings or purely mechanical infrastructure where it is possible to use the equipment until it is too difficult to maintain or breaks, computer life-cycles are not entirely determined by the physical longevity of the device.

The end of the life cycle of a computer occurs:

• when a machine can no longer run the software it must run. Examples include:
  • systems that cannot run recent versions of application software required by users;
  • systems that cannot run the operating system required by these applications;
  • systems that cannot run the current network hardware and software required by Ryerson's wider network infrastructure;
• when user expectations of performance are no longer being met. When the computing industry (hardware and software) produce more capable computing equipment, faculty and students normally ask for more capable computers with newer capabilities or enhancements. While there is the "it must still be good for something" syndrome with old computers, faculty and students always demand newer more capable systems. ACAC bookings over the last two years reflect this dramatically as does the fact ACAC members have uniformly requested upgraded systems and not more of what we have.
• maintenance and support problems have grown to such an extent that the equipment cannot be kept operating reliably. Maintenance in CCS's labs is at this point. Many systems have been used on average 18 hours per day for 4 to 5 years - well beyond the manufacturer's design goals. Items such as monitors and hard drives that should last 4 to 5 years do not under the punishing conditions of our drop-in and teaching labs.

Three Year Workstation Life Cycles

The average lifetime for a computer workstation is roughly three years. That is the machine should be completely replaced three years after purchase. Other scenarios are imaginable but they are not financially better. For example a machine that costs $2600 can be replaced in three years giving a simple yearly capital cost of 2600/3 = $867. To extend its useful life the same system could be upgraded in its second and third year. A typical example might be an additional memory or disk purchase in the second year and a processor upgrade in the third. Either of these may run in the $400 to $500 range. This may extend the life of the machine to 4 years so that the yearly cost in this example is: ($2600 + $400 +$500)/4years = $875. In other words the useful life of a computer is roughly 3 years and mid life upgrades do not decrease the yearly capital cost of the equipment.

Three Year Server Life Cycles

Central servers experience the same short life cycles. At Ryerson for example, the Malthus statistics server is in its fifth year with only one upgrade and is still adequate for the needs of its users. Malthus may have an effective life cycle of 4 or even 5 years. But this is only because significant new work is being done on local workstations. In this case we are receiving demands for increased performance and new features for statistics software on both the workstations and on central servers. On the other hand, the campus E-mail server Hopper, has seen explosive demands necessitating tremendous expenditures. The system has gone from a single processor system to a six processor system. CCS is attempting to manage further E-mail growth by forcing users (for example in CCS and School of Business student labs) to use E-mail client software that uses the resources of the workstation instead of the server to write and read mail. Hopper's effective life cycle is difficult to calculate, but it has certainly been within the two year range. Last year CCS purchased new lab servers to support 270 of its machines. As CCS was installing the new servers this year, one of the old servers became unusable, and crashes on the others became almost routine until the old systems were taken off line. Again these systems had an effective life cycle of three to four years.

Four~Five Year Network Hardware Life Cycles

An exception to the three year cycle has been the network hardware such as token ring and Ethernet adapters, routers and hubs. Even these need replacement however and a life cycle of four to five years is more appropriate as user demands for network bandwidth increase.

But Computers are Supposed to be Getting Cheaper!

The price/performance ratio for computing devices is declining rapidly. This does not mean that workstations are falling in price at the same rate. Given a choice, the computer industry and consumers produce and purchase more powerful systems before producing less expensive equally capable ones. The following table, taken from the March 1997 issue of PC Magazine illustrates this nicely. One of the most popular yearly issues of this magazine is the "Perfect PC" issue where the ideal best performance for the dollar system is described for that year. The following table shows that while these systems have improved dramatically in processing power, the system cost has not declined at the same rate:

In the 14 years covered by this table the processing power of the CPU has increased by a factor of at least 100. During the same time the price of these systems declined only 30%. In fact, a case can be made that someone who might have felt compelled to spend $4000 to get a usable system in 1988 might only feel compelled to purchase a $2500 system in 1997. This would represent a somewhat better decline in price of 38% over a nine year period. In either case, the falling price of a particular system component does not translate into a similar fall in real system prices. Nor do they translate into longer life cycles or reduced cost of ownership. In fact the opposite is the case!

More Complexity means Greater Expense!

While there is a gradual decline in the sticker price of new workstations, the total cost of owning a workstation has been steadily increasing. As these systems become more complex, running larger operating systems and larger and greater numbers of applications, they become more difficult to configure, integrate, maintain and support in a networked multiuser environment. According to the Gartner group the total cost of system ownership doubled between 1987 and 1993. This has been apparent at Ryerson where CCS has gone from managing a mainframe with terminals to 300 workstations connected to ten CCS servers. CCS maintains systems running Novell Netware, the AIX and Solaris UNIX variants, Windows NT, Windows 95, and Windows 3.1/DOS. CCS workstations run 21 DOS applications, 34 Windows applications and 23 UNIX applications. These systems have been reasonably supported but there has been no resources available for development and better integration of these systems. The result is that they are often difficult to use, and have not been customized or integrated into Ryerson's network resources to better facilitate the work practices of Ryerson's students. One simple example of this is how hard it is for students to move files between department and CCS workstations and servers. Another is the multiplicity of accounts students and faculty must deal with in order to work in different environments.

Hidden Costs and Lost Opportunities

CCS is not the only organization that has experienced an increased support load and an inability to develop better ways for students to work with networked systems. Faculty, who have been volunteering their time to build and maintain lab systems are in the same situation. Key faculty in many departments spend countless hours researching the best systems to buy, installing them themselves, and maintaining department systems. The dollar cost of this to the University may appear to be very low. However, the real cost is in the lost opportunity represented by thousands of hours of faculty volunteer work. And while faculty management and hands on participation is absolutely critical, the degree of work done by some faculty who must make their own labs work is often well beyond what is reasonable. These faculty pay the price in lost preparation time, lost research opportunities, lost time keeping abreast of their discipline and in lost sleep. Gradually, more departments are being forced to hire more technology support staff across campus. In every case the lab systems Ryerson builds may be adequately supported but rarely fully leverage the opportunity they represent because of the lack of development and integration support available across the campus.

Recommendations

The strategic and financial planning required to utilize information technology for the academic enterprise is fundamentally different than the planning and financial realities of other capital and operating expenses in the University. A different approach to funding IT must be established that includes budgets that account for the short life cycle of computing equipment and software. IT dollars must be focused in such a way as to control support costs, develop and implement systems that make sense for our students, and that enable universal access to rich central resources for our students. We cannot keep spending money on emerging IT needs only as they arise. These are already well beyond Ryerson's ability to fund IT. Instead, we must focus on:

1. providing a set of academically useful, secure, well maintained and supported central networked services including E-mail, academic databases, Web, media, and compute servers developed and tailored to Ryerson's academic needs;
2. encourage wherever possible the move to student ownership of workstations;
3. develop systems that connect and integrate Ryerson's central resources (including labs) with student owned workstations - and therefore add significant value to student systems.

Student Purchase of Computers

Desktops

When a student buys a desktop system they relieve some of the pressure on Ryerson's overcrowded student labs. Currently, the University is doing little to facilitate better use of student owned desktop systems. Students who work at home often connect to Ryerson through an Internet Service Provider (ISP). Students who do this currently get little assistance in learning how to do this or how to configure the wide variety of systems and software they purchase to access Ryerson's IT services. The student labs are also not configured to allow students who do the bulk of their work at home to use the labs for quick printing, file transfer, or to just check E-mail or the Web. To encourage the use of desktop systems in programs that are not moving to a laptop model, Ryerson needs to:

1. offer software, help, and a server and network infrastructure to simplify accessing the University remotely;
2. enrich the services available to students accessing the campus remotely:
   • provide file transfer space on Ryerson's servers;
   • remote printing services;
   • Web proxy services where required;
   • datasets;
   • push technology to student home systems (to replace log in messages and storage consuming broadcast Email messages);
3. restructure the labs to facilitate usage by students who do most of their work at home:
   • provide drop-in Web and E-mail only clients for quick access to basic services;
   • provide printing stations for reformatting and printing work;
4. develop 2 to 4 standard desktop system packages for sale to students that are preloaded and configured to connect to the campus with bundled software suites appropriate to a range of academic programs.

Life Cycle Considerations

A desktop system purchased in first year will be obsolete in fourth year. Where programs require student purchases of desktop systems these systems must be selected so that mid-life upgrades are possible (and likely a requirement of the program). Furthermore these systems should be selected based on criteria developed by the program requiring the purchase in consultation with CCS. Arrangements to have Ryerson standard communications software loaded on the machines will also have to be made.

Infrastructure Costs

If desktop systems become a requirement for programs or departments the University can be expected to provide funds for:

1. faculty workstations of comparable power with budgeting to renew these every three years;
2. customized central services to maximize the value of the student's investment;
3. staff time to develop and integrate central and remote services.

In every case where a department or program requires the purchase of student desktop systems a life-cycle budget will have to be developed to calculate the program costs based on the items already mentioned. For example a simple per student estimate might look like:

or roughly $143 per student per year.

Laptops

While laptops provide many advantages they also place an increased demand on the University for network and server infrastructure. This makes it financially difficult for the University to do anything but keep up with supporting the campus infrastructure and support that a laptop program requires. A division of costs must be established that makes laptop programs financially possible for the University. The worst case scenario would be to pretend that the University could sustain a subsidy for large numbers or a significant percentage of the cost of laptop for any but the smallest programs. If the costs appear too high for students in a particular program, then the program should not embark on a laptop program.

Life Cycle Considerations

Unlike desktop systems, most laptops are not upgraded to extend their life by another year. This is why most Universities who have embarked on laptop programs are leasing systems on three year leases as is Ryerson's LINK program.

Division of Expenditures

Where laptop purchases are required, the minimum students will be expected to pay is:

1. the full cost of leasing a system (including modem and Ethernet) while at Ryerson;
2. theft and other insurance;
3. software required by their program, including upgrades;
4. Internet Service Provider access where Internet access is required or to connect to the campus;
5. Ryerson developed software and documentation. (Development, Media, and Printing)

If a technology fee were permissible in Ontario the University would also have to consider charging for help desk assistance and service.

Any laptop program would require fixing on one system configuration per year. In some cases the system selected would be more expensive than in others. For a single case scenario the Ryerson Link program chose a $3000.00 system that is leased for 3 years and returned to the leasor. With Internet access, software, and taxes, students must pay $1400 per academic year for each of their four years in the program. It is unlikely that this cost can be reduced significantly. With less capable machines, less software, less Internet access it might be possible in the next year (in a different program scenario) to come down to $1300 per academic year.

Steady State Laptop Program Infrastructure and Support Costs

Warning: These values are based on projections to a steady-state from the current LINK program. Any program costing would have to consider:

1. one time start up costs;
2. size of the program; (smaller programs may be more expensive per student)
3. the number of courses that require connected rooms;
4. the student/faculty class ratio;
5. cost of the systems;
6. existing office network connections.

These values should be used to calculate large program steady state funding only.

Total Yearly Cost per Student: $197 * 14,622 students = $2,880,534/year after reaching stead state for the entire University to go laptop. Note: these costs do not include drop-in network connections around campus.

Funding Computer Labs at Ryerson

General Purpose Teaching and Drop-In Labs

With the exception of 24 Pentium 100 systems in W71 all the 230 general purpose systems operated by CCS are past their life cycle. The systems do not run Windows 95 in 1997, do not have the software students are using at home and in department labs (mostly Microsoft Office and later versions of Corel's suite ) have little graphics or presentation facility and no audio. The Web browsers are a major release out of date and the systems cannot execute Java applets due to lack of memory. The systems have no sound, making streaming audio on the Web irrelevant and no CDs to play back course materials available in various departments (Nursing and Architecture are two examples).

The answer to this problem is not to take out a loan and purchase 200 new systems. A much better and fiscally viable solution is to establish a budget to replace one third of these systems every year and begin the process this coming September. This avoids the cost of a loan, avoids the purchase of too many machines that will all be out of date in 3 years and gives CCS a more flexible approach to maintaining and upgrading the central labs.

Based on the fact that CCS already has maintenance and some support staff the following is a life cycle based budget for 236 general teaching and drop in systems. In fact there are 232 systems but the assumption is that an additional 4 systems should be placed in B405 and E135 to go from 23 to 25 seats in those two rooms.

*Based on requests at ACAC for full multimedia playback and current and requested software in the lab as well as the following:

• Current mid-level Intel processor
• 32 MB RAM
• 100 ~ 120MB removable storage drive (Zip, LS120, or Sony)
• DMI 2 compliance for remote maintenance and administration
• ATX form factor
• 3GB HD
• 16 bit sound
• CD-ROM
• Accelerated graphics
• Windows NT

Higher End Computing

Higher-end computing is a requirement for many core "production" courses where students must work with highly specialized applications that require specific computing resources. These systems are almost always more expensive to purchase and operate. Over the last three years Ryerson has purchased workstations at prices ranging from $4500 to $12,000. Other universities have spent much more on a per seat basis.

Computing and Communications Services operates three higher-end workstation labs. These are the:

• W71A Multimedia Lab built this year;
• W71B Distributed Computing Network (Sun Lab) built three years ago;
• W71C CAD/Publishing/Multimedia lab rebuilt three years ago.

Together these labs offer the University 66 "higher-end" workstations ranging from 85 MHz MicroSPARC and Pentium 75MHz systems to the newer 300MHz Pentium II MMX multimedia systems in W71A. Taking the average cost of these systems ($8,250) and ignoring the development, integration, and research support aspects of higher-end computing, a yearly budget for central higher-end computing at Ryerson is calculated below. In the figures below it is assumed that these facilities would be expanded to accomodate current section sizes with 24 seats in 71A and C and 30 seats in 71B for a total of 78 seats.

*includes snapper, angel, and an NT server.

Lower End Computing

A common complaint in almost every CCS and departmental lab is that students spend a great deal of time simply surfing the Web or reading and writing E-mail. It seems wasteful to allow machines capable of doing so much to be used primarily for such basic tasks. An alternative to the general purpose lab would be to build additional areas with "thin-client" or "NetPC" types of systems. These systems must still run an operating system capable of supporting the latest communications tools such as browser and E-mail clients. The systems must also permit remote management and administration. The costs to place 100 of these systems on campus would be:

Total Lab Costs

Without the additional CCS efforts in development and systems integration, discussed later, this amounts to yearly expenditures of :

Funding Private Department/Faculty Labs

Department labs are in much the same situation CCS labs are in. Allocations for these facilities are almost always done as single year special funding initiatives. New funding requests for departmental and program labs should require complete life-cycle cost estimates. Regardless of the evaluation/reporting structure of the approvals process, before a new lab is funded or rebuilt the University should have in hand a reasonable estimate of the total yearly cost of the lab including hardware upgrades, maintenance, software renewal, and systems support. Funding computing resources without these is like taking a long term loan without thinking about the interest costs. Ryerson should view the purchase of every new computer as budgetary promise to provide further funds every year for support, software upgrades, maintenance, and renewal.

Funding other Central Computing Resources

Servers

There would be little point in contemplating large capital allocations for workstations if they had nothing to connect to. E-mail, academic data sets and databases, Web sites, streaming media, scientific and technical applications, and other specialized computing resources all require a range of central server systems to run on with appropriate compute and storage resources. Leaving aside the development and support costs for these systems, the University should allocate funds to keep these systems current.

The following server costs assumes much of the cost for specialized software is born by departments and that CCS provides the technical support - no funds are allocated here for development and integration.

Total Ryerson budget required for central academic servers every year: $60,000

Internet Access

Ryerson currently pays $50,000/year for our ONET connection to the Internet. The current arrangement provides a 2 MB ATM connection. Any significant increase in the number of systems on campus accessing or regularly providing information to the Web/Internet will lead increased ONET costs for more bandwidth. The current yearly fee could easily double or triple.

Funding Development, Integration, and Maintenance

Ryerson's academic computing systems are poorly integrated. Students who must move between CCS and department labs are constantly frustrated by how difficult this is. There is next to no level of customization in how generic server and client software works. There is little or no resources to do forward systems development, planning, and testing in order to leverage Ryerson's infrastructure and introduce new client-server systems to the campus. The state of Ryerson's E-mail system is one example. The system is hard to use, largely still based on server-side text processing, and insecure (fake E-mail is a large problem). The slow development of Web and database server resources is a second. The lack of client and server side programming is another. Faculty who request a small Java applet or who ask for an enhanced service such as multiple choice tests (with more than one valid answer) must wait years before the simplest enhancement comes into production.

Truly leveraging the potential of student owned networked workstations will require significant new development and integration capabilities at Ryerson. Implementing course site generation systems and customizing them to faculty and student needs is only one requirement. Customizing existing simulations, developing academic databases, and dealing with the larger scale capture and distribution of digital media assets are all requirements for a modern digital university. Ryerson has almost no resources to begin noticeable work in these areas. In every case what is needed is a new "whole product" approach to problems that address the academic needs of faculty and students and they way they need to work.

Electronic Mail at Ryerson - An Example

The E-mail system at Ryerson suffers from a number of problems. The following describes these and how a systems development and integration effort could resolve them.

Security

Open Internet E-mail standards were not developed primarily with security in mind. It is a simple matter to create and send E-mail that is either anonymous or appears to be from someone else using university E-mail servers. With the introduction of the Netscape browser and its free E-mail client this problem has gotten much worse. Some of the most frustrating and time-consuming E-mail abuses that CCS and the Office of Equity, Harrasement, and Safety have had to deal with involve anonymous and fake E-mail messages that are received by people at and outside Ryerson. Recently ACS introduced a customized version of Netscape in its labs that cannot send fake E-mail. This produced what appears to be a marginal improvement in the situation. There is therefore no single answer to this problem. Seriously reducing it will require a number of efforts that force authentication of some type for every piece of mail sent or relayed from Ryerson's E-mail server and that make it more difficult to send fake Email. In one case user accountability is enforced and in the other ease of sending E-mail without your name on it is reduced. This is a common problem that many universities are working on. For example at the Pennsylvania State University (http://www.cause.org/information-resources/ir-library/pdf/cnc9721.pdf) a system was developed that used:

1. central Kerberos authentication servers;
2. regular export and encryption/decryption of student records to the authentication servers;
3. custom audit/tracking system;
4. an IP filtering fire-wall system to control laptop connections;
5. a custom secure Web server system for laptop authentication and fire wall programming.

This system does not make it impossible to send fake E-mail but at least makes it possible to trace it to an account.

Ease of Use, Flexibility, and Richness

Ryerson's E-mail server is capable of supporting modern easier to use graphical E-mail client programs such as Netscape's Messenger, Qualcomm's Eudora, Microsoft's Outlook Express, and other products. Typically, these programs provide improved ease of use and a variety of useful features. These include:

• the ability to look up Internet E-mail addresses (via LDAP);
• encrypted E-mail (via S/MIME);
• mail may be left on the server and remotely managed via IMAP 4 (and offline deletion will later delete the server copy automatically if desired);
• rich E-mail formatting via HTML and embedding graphics and applets;
• convenient mail attachements using the native OS/Windowing system dialog boxes.

Resource Requirements

Ryerson's "Pine" E-mail system was built in 1992/93. At that time it was normal practice to log into an E-mail server and use a program like Pine and Pico to compose and read E-mail. The implications of this were that the E-mail server had to support numerous log in sessions and the word processing functions of reading and writing E-mail. This method of working affected both the hardware requirements for the server (Hopper) and the network and dial in resources required to access it. In particular modem pool users must log in and stay on the line in order to read and write E-mail and the server has had to be continually upgraded to support more than 400 simultaneous log ins. A lot has changed in the last five or six years outside the campus. E-mail programs are available for workstations that allow quick downloading of mail for off line reading and off line composition of mail. If this technology were widely implemented at Ryerson a roughly four times improvement in E-mail usage of the modem pool could be achieved and the dramatic upgrade costs for the E-mail server could be better controlled.

Progress to Date

CCS has implemented much of the server-side software required to improve the E-mail system. IMAP4 and POP3 E-mail servers are available on Hopper. CCS has also discontinued Pine access in the School of Business and CCS labs and replaced it with PC-Pine access. PC-Pine if an unsophisticated IMAP E-mail client. Its use has reduced the number of log ins on Hopper.

CCS has not had the resources to develop an integrated and more secure system based on using properly configured and advanced client E-mail programs nor has it had the resources to provide anything beyond the generic E-mail server software to improve the security of the E-mail system.

Required Improvements

At the least, CCS needs to develop a stratedgy for authenticating who sends E-mail through Ryerson's servers and in the longer term needs to implement a system that makes it extremely difficult to send fake E-mail and extremely difficult to send it without it being traced back to an account. In the context of the requirement to develop a more secure E-mail system CCS needs the resources to develop and support the use of more modern E-mail clients as a standard at Ryerson.

A Distributed Support Model

CCS and "private" department/faculty labs suffer from many of the same problems. Rarely is anyone available to do anything beyond the most rudimentary systems development and integration in these facilities. Hours of maintenance and band-aid solutions that frustrate students is usually the result. In the past when the demands on CCS were less, Network Services and ACS were able to provide some development and support for non CCS labs. Today they still supply some (basic configuration and maintenance) support for departmental servers and labs but do not have the resources to send anyone to remote labs and are trying to get out of the buisness.

In the past CCS has requested funding to build a group with ACS to do all the necessary support of remote labs. Funds were not available for this and the result over the last five years has been a natural movement toward distributing basic support functions to departments that own and operate their own facilities. Reductions in CCS staff over the last five years have made this inevitable. This phenomena is not unique to Ryerson. A landmark paper The Crisis in Information Technology Support: Has Our Current Model Reached Its Limit? by Polley A. McClure, John W. Smith, and Toby D. Sitko. (http://www.cause.org/information-resources/ir-library/html/pub3016/16index.html) discusses the move to distributed support and its history as a general phenomena in North American Universities.

In fact, distributed support is a reality at almost every university and can have a number of important advantages:

1. Ownership of support resources. Faculty and departments who are responsible for running their own facilities naturally take ownership of them and how they operate. There is therefore a relatively simple relationship between student program-specific computing needs and the department/faculty who decide on how labs are built and run.
2. Dedicated staff and faculty can focus on the problems of a single department's resources.
3. The budget for support of these facilities is clearly tied to them and cannot be cut without immediate and obvious implications.
4. Staff and faculty can leverage the existing Ryerson wide infrastructure such as the newtork and servers to provide complete systems solutions without reinventing everything.

Distributed support can have a number of dissadvantages:

1. Where funds are not available for support staff, faculty end up volunteering countless hourse to build and maintain systems;
2. Where the department does not have sufficient faculty computer expertise available, they are at the mercy of the quality and predilections of the support staff they hire. Technology planning, management, and supervision of support staff may not be adequate.
3. A single support technician in a department usually cannot do everything. Asking one person to keep abreast of all relevant computer and network technologies, planning and rebuilding systems strategies and developing, integrating, and maintaining actual networked systems is unreasonable.
4. The department may not be able to afford someone with requisite higher level computer science background to do all the development and integration work required to optimize the academic value of the facility.

Making Distributed Support Work

Simply saying that departments and programs must support their own system does not mean that those systems will be well supported or that they will be optimally designed and used. Distributed support also does not mean that the small independant resources available to departments are adequate to do everything. For distributed support to work there must be a series of development, integration, and support resources available in the central IT organization for the distributed support staff and faculty to draw on. Implemented correctly, this results in an important two way exchange of ideas and solutions. Working with distributed support personell, the central group will be well aware of the diverse computing requirements of the university and the solutions the departments are investing in. Similarly, department support staff will have available a richer set of reliable networked solutions on which they can draw without having to reinvent everything.

Distributed support policies and procedures should be developed by the University that:

1. provide a framework for dividing the responsibilities for systems between CCS and academic departments, programs, and centres;
2. describe how CCS and the academic departments and centres should work together to provide campus-wide and department/centre/program specific solutions;
3. describe how campus-wide policies may be created when they are truly necessary. These may include requirements for a single authentication service across the campus or the development of a networked student file and backup store.

Core Development and Integration Recommendations

CCS should provide:

1. improved networked systems security including:
   • campus-wide authentication services for all academic users;
   • improved protection against network intrusion. Using DHCP, MAC address allocation, fire-walls and/or other tools as required to control and validate IP usage;
   • improved E-mail security and authentication where ever possible;
2. improved E-mail resources including:
   • support for at least one IMAP 4 compliant E-mail client to be widely distributed and supported;
   • richly formatted (including graphics, sound, video, applets) E-mail;
   • easy to use E-mail client software (modern GUI interface);
   • support for offline E-mail use.
3. Electronic Teaching/Web enhancement services including:
   • selecting an automated course development and management tool such as Learning Space, ILN, or WebCT with the assistance of the DMP and faculty and then provide it as a core academic computing service campus-wide.
   • CGI programming to enhance Web sites, especially course delivery sites;
   • programming assistance in the area of simulations and interactive media programming.
4. research computing development and support services including:
   • scientific, technical, visualization, and dataset/database management application and systems integration services and support especially as it pertains to the interoperability of distributed systems spread around the campus that reside in several different departments or centres;
   • enhanced assistance for researchers working on smaller SSHRC or NSERC funded projects;

Restructuring Academic Computing

Academic Computing Sevices (ACS) is restructuring to meet some of these needs. ACS is in the process of reclassifying three open microcomputer support positions to build a small systems development and integration group within ACS. At this time ACS is planning to hire one software engineer and two distributed systems developers. This will not be enough. Looking at the resources required to support basic systems development and integration at other universities ACS will still need at least:

1. one more systems developer/integrator; ($55,000)
2. one developer/consultant to work directly with distributed support staff; ($55,000)
3. programmer; ($55,000)
4. research programmer/support specialist to support SRC and facets of graduate programs as they develop;($65,000)

for a total of $230,000/year additional ACS staff.