You are on page 1of 18

Administrative and Academic Information Systems: LAN Management Task Force Final Report CAUSE INFORMATION RESOURCES LIBRARY

The attached document is provided through the CAUSE Information Resources Library. As part of the CAUSE Information Resources Program, the Library provides CAUSE members access to a collection of information related to the development, use, management, and evaluation of information resources- technology, services, and information- in higher education. Most of the documents have not been formally published and thus are not in general distribution. Statements of fact or opinion in the attached document are made on the responsibility of the author(s) alone and do not imply an opinion on the part of the CAUSE Board of Directors, officers, staff, or membership. This document was contributed by the named organization to the CAUSE Information Resources Library. It is the intellectual property of the author(s). Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the title and organization that submitted the document appear, and that notice is given that this document was obtained from the CAUSE Information Resources Library. To copy or disseminate otherwise, or to republish in any form, requires written permission from the contributing organization. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303449-4430; e-mail To order a hard copy of this document contact CAUSE or send e-mail to

Administrative Information Services (AIS) Academic Information Systems (AcIS) LAN MANAGEMENT TASK FORCE: FINAL REPORT 28 May 1992 INTRODUCTION For about 30 years, Columbia University has provided centralized computing services in the form of batch processing or timesharing based on large central computers. In the 1970s, minicomputers began to show up in the departments, largely because of the incentives given by government grants for grantees to purchase their own computers rather than using central services. With the appearance of low-cost personal computers in the 1980s, decentralization became the dominant theme of computing at Columbia. The 1980s also saw the appearance and rapid growth of computer networking technology, which allowed for varying degrees

of connectivity among the University's many distributed computing sites. With the installation of the Rolm CBX wiring plant in 1988, universal connectivity (at least on the Morningside campus and nearby buildings) became feasible. The computers are there and so are the wires. As departmental computing facilities grow by adding desktop computers, soon there is a need to share resources such as printers and files, and with this the need for a local area network (LAN). Once installed, the local area network eventually needs to be connected to the University's backbone network so the department's users can communicate with users in other departments, access central services, and reach the outside world through Columbia's wide area networks. Until now the University has lacked a coordinated approach to LAN support. This report is a first step: - Preliminary standards are recommended for servers, desktop systems, network configuration, and applications, along with a committee to review them. - A central, University-wide software licensing office is proposed. - A central LAN service is proposed to achieve consistency and University-wide cost savings. 1. RECOMMENDED HARDWARE PLATFORMS AND CONFIGURATIONS Given the variety and volatility of the computer and networking marketplace, University-wide standards and procedures are required to provide guidance to Columbia's users and departments to promote consistency, interoperability, and connectivity. The three popular types of desktop computer systems are IBM PCs (and compatibles), the Macintosh, and UNIX workstations, in approximately that order. This is true for the US marketplace as a whole, and for Columbia University in particular. Other types of desktop computers are also found at Columbia. Our recommendations address only the three major types. Note that the recommended items are based on current technologies rather than predictions. If we were to base our recommendations on pure standards to encourage an open and homogeneous computing environment at the University, UNIX-based systems and applications would be considered much more strongly. All recommendations in this document are subject to revision or change, especially in view of rapidly changing technology, pricing, and market trends. It is recognized that lists of recommended configurations and applications imply some degree of support from our central computing and networking organizations. In practice, our organizations are not adequately funded or staffed to provide the required level of support to the University as a whole. However, the publication of standards and recommendations makes our job potentially easier by promoting consistency and reliability. 1.1. LAN SERVERS

The server of choice is a high-end PC (80486 or above). No particular manufacturer is recommended. The recommended network operating system is Novell NetWare 3.11 (or later). This is the industry leader, and provides most (but not all) the required services. A Novell server offers file and print services to both PCs and Macintoshes, and with the TCP/IP Network File System option, it can also provide transparent access to files and printers on the central UNIX, VM/CMS, MVS, and VAX/VMS systems, and vice versa. The server can also provide LANbased electronic mail, which eliminates the requirement for users to cope with central host-based mail systems like MM. For access to the outside world from the desktop, TCP/IP software is recommended. This bypasses the server and allows the user to connect directly from the desktop workstation to our central services and to any resource on the Internet. Thus, no particular gateways (other than mail) are required for the server, such as TCP/IP, 3270, or SNA gateways. Servers based on other technologies (such as UNIX-based Novell, AFS, or NFS servers) are left open for further study. 1.2. IBM PCs AND COMPATIBLES Minimum configuration for client (desktop) PCs. These apply to existing systems. They are the minimum requirements for connection to the campus network for basic network service including Novell file server access, e-mail, and terminal connection to our central hosts and servers. Minimally configured PCs will not necessarily be able to run Windows, OS/2, or large PC applications, even when they are available on the network. There are no specific recommendations as to manufacturer or distributor of IBM compatible computers. 80286 CPU, PC/AT, PS/2-50, or compatible, or higher AT or Microchannel bus EGA or VGA video adapter and compatible monitor 640K memory 20MB hard disk At least one 5.25-inch or 3.5-inch (preferably 1.4MB) diskette drive At least one standard serial communication port Parallel interface for local printer (if required) At least one standard AT or Microchannel expansion slot available for network adapter, or (for laptops) a parallel port that can be used with a "pocket network adapter" MS-DOS or PC-DOS 3.30 or 5.0

Recommended configuration for client (desktop) PCs. New systems should meet these requirements. - 80386 or higher CPU, IBM compatible - AT or Microchannel bus - VGA video adapter and compatible color monitor, preferably with large screen - At least 4MB memory - 60MB hard disk - At least one 5.25-inch or 3.5-inch (preferably 1.4MB) diskette drive - At least one standard serial communication port

- Parallel interface for local printer (if required) - At least one standard AT or Microchannel expansion slot available for network adapter, or (for laptops) a parallel port that can be used with a "pocket network adapter" - MS-DOS or PC-DOS 5.0 - QEMM, DOS 5.0, or Microsoft Windows memory management - Mouse (on mouse port) if required for applications - Microsoft Windows 3.0 or higher, if desired The following items are not recommended for the reasons noted: - Internal modems. They are often incompatible with generalpurpose PC communication software. Modems are generally not useful on the Morningside campus, which is served by digital Rolmphones that cannot be used with modems. When modems are required, external modems should be used in conjunction with a standard PC serial port. - Serial printers, because DOS does not provide flow control with serial printers. - Serial mice, because they tend to cause interrupt conflicts. - DOS versions prior to 3.30 because they lack services that most applications expect. - DOS 4.x because it is buggy. - TSR programs that might interfere with network operation or applications. PC operating systems for future consideration: - OS/2 2.0 - Windows NT - Alternative DOS environments such as DR DOS Note: Various versions of UNIX are available for PC platforms. In that case, the PC is considered a UNIX workstation (see section 1.4). 1.3. APPLE MACINTOSH Minimum configuration: Macintosh Plus, Mac SE, Mac II, Classic, or above. 68000 CPU 1MB memory (2MB for System 7) 20MB hard disk 3.5-inch diskette System 6.0 or higher SCSI port or a free slot for a network adapter

Recommended configuration: - Macintosh Classic II, SE/30, LC, Mac II, Powerbook, Quadra, or above. - 68030 or higher CPU (except Powerbook 100) - 4MB memory or more - 60MB hard disk - 3.5-inch diskette - Localtalk connector - System 6.0 or higher with MultiFinder and HyperCard - SCSI port or a free slot for a network adapter

Macintoshes should not be overloaded with INITs and extensions, as these tend to cause conflicts. Internal modems are not recommended. 1.4. UNIX WORKSTATIONS There is great variation among UNIX workstation models, so our recommendations cannot be as specific as for PCs and Macs. The following apply to private desktop workstations. The requirements for shared UNIX workstations (e.g. in public laboratory) or workstations used as servers may differ. - Manufacturer: SUN, NeXT, DEC, and IBM have the high market share at Columbia - Memory: the more the better. 8MB (minimum), 16MB or more (recommended) - 300MB hard disk - 5.25-inch or 3.5-inch diskette, or quarter-inch tape cartridge - Large color monitor recommended for window applications - Standard serial port - Ethernet interface - UNIX operating system based on 4.2BSD or higher or System V R4 or higher - TCP/IP networking - C compiler and libraries 2. RECOMMENDED NETWORK CONFIGURATIONS These recommendations are intended to allow desktop workstations to connect with each other through the Rolm wiring and to connect to the University backbone network, and through it to other departments, central services, and the outside world. 2.1. NETWORK ARCHITECTURE Workstations are connected by telephone wire to the Rolm jack, which is, in turn, connected to a Cabletron building hub. Building hubs are interconnected by our campus backbone network, generally through Cisco routers. The primary backbone network protocols are TCP/IP and Novell IPX. Appletalk in some form can be supported on the backbone, but should generally be avoided except in localized areas (for example, for shared LaserWriters). Remote networks are connected to the backbone network via Cisco router. The connection to the remote network can be a leased 56Kbps or T1 serial line, microwave, or other connection method supported by the Cisco router. Cisco is our current vendor of choice for routers, subject to change. 2.2. NETWORK TECHNOLOGY Ethernet is recommended. Token Ring is supported but discouraged for reasons of cost, complexity, memory consumption, and performance. Appletalk is discouraged because of the complexity and expense of integrating it with the backbone network. Ethernet adapters are readily available for PCs, Macintoshes, and UNIX workstations.

2.3. NETWORK ADAPTER For computers with free slots, an Unshielded Twisted Pair (UTP) 10BaseT network adapter, for direct connection to the Rolm jack via modular RJ-45 phone cord. The current vendor of choice is Cabletron, for compatibility with our hubs and network management software. The choice of vendor is subject to change. The following Cabletron boards are recommended: E1110-X Ethernet for PC/XT, PC/AT, or PS/2-30 (8-bit XT or AT bus) E2110-X Ethernet for PC/AT, or PS/2-30 (16-bit AT bus) E3110-X Ethernet for PS/2 with Microchannel bus E4010-X Ethernet for Mac SE E5010-X Ethernet for Mac SE/30 E6110-X Ethernet for Mac II E9119-X Ethernet for Mac LC EA419-X SCSI to Ethernet adapter (Note: all Macs have a SCSI port) T1015-4 4Mbps Token Ring for PC/XT, PC/AT, or PS/2-30 (8-bit XT or AT bus) T2015 4/16Mbps Token Ring for PC/AT, or PS/2-30 (8-bit XT or AT bus) T3015 4/16Mbps Token Ring for PS/2 with Microchannel bus T6015 4/16Mbps Token Ring for Macintosh II For PCs with no free slots, but with a free parallel port: Cabletron E1312 Ethernet adapter, or Xircom Pocket Ethernet or Token Ring adapter. For computers that already have other types of Ethernet boards installed, the following devices convert to Unshielded Twisted Pair for Rolm wiring: Cabletron TPT or TPT-4 to convert to AUI (thick coax) Cabletron CTP100-T to convert to Thinwire Ethernet 2.4. NETWORK ADAPTER DEVICE DRIVER FOR PCs Packet Driver, such as the ones supplied by Cabletron with their boards, and which are available from most other board vendors, and which are also available as free (but copyright) software in the Crynwyr Packet Driver collection (distributed by Columbia University). Packet drivers are preferred over dedicated perapplication device drivers because: - They allow multiple applications to share the same network adapter. - Rebooting is not necessary between network applications. - Packet drivers use very little memory. - A great deal of network and application software is "packetdriver ready." - Packet drivers are available for both DOS and Windows use. For future study: ODI and NDIS network drivers. 2.5. NETWORK OPERATING SYSTEM FOR PCs Novell NetWare 3.11 or above. Client PCs run a packet driver, IPX.COM, and NETX.COM (or some variation), configured to allow operation over packet drivers. For PCs on Token Ring networks, additional software is necessary:

IBM's LAN Support Program, plus the special packet driver, IBMTOKEN.COM. When network software is to be used within Windows, an additional component, WINPKT.COM, is also required. For TCP/IP access to central services and the outside world, MS-DOS Kermit and tn3270 are recommended. 2.6. NETWORK HARDWARE FOR MACINTOSHES Localtalk connections are not recommended. Ethertalk, either through an internal Ethernet adapter or through the Mac's SCSI port connected to a SCSI Ethernet adaptor, is preferred, both for performance and to avoid the complexities and expense of protocol conversion. 2.7. NETWORK OPERATING SYSTEM FOR MACINTOSHES Appleshare or Novell NetWare 3.11 or above. For TCP/IP access to the central services and the outside world, Mac TCP is recommended (for which Columbia University has a site license). 2.8. Network Hardware and Software for UNIX Workstations Unshielded Twisted Pair, AUI (thick coax), or thinwire Ethernet adapter with Cabletron converter. TCP/IP software. 2.9. SHARED PRINTERS Printers may be shared via the Novell sharing methods, the Apple sharing methods, and the TCP/IP spooling method (LPR/LPD). In most cases, shared printers using one method can also be accessible from the other methods via TCP/IP when spoolers are installed for them on our central UNIX systems and/or IBM mainframes. 2.10. PROTOCOL FOR ACCESS TO CENTRAL SERVICES AND WIDE AREA NETWORKS TCP/IP and associated protocols including TELNET, TN3270, FTP, NFS, SMTP, NNTP, IMAP, etc. Presentation protocol: VT300-series terminal or 3270 emulation. For further study: X Windows, Motif, etc. (Presentation Task Force). 3. RECOMMENDED APPLICATIONS For the PC, both DOS and Microsoft Windows 3.x must be considered. Other PC "environments," such as DesqView, are not recommended. The table lists the recommended applications. Only the most general-purpose and high market-share applications are included. An important objective in the selection is to achieve the greatest interoperability among applications (perhaps via built-in export/import procedures or conversion utilities), which has not necessarily been demonstrated. These applications are for the recommended hardware configurations and will not necessarily run on minimally configured desktop systems. -----------------------------------------------------------------------DOS Windows Macintosh UNIX -----------------------------------------------------------------------Word Microsoft Word Microsoft Word Microsoft Word EMACS Processors WordPerfect WordPerfect MacWrite II (see note)

Spreadsheets Microsoft Excel Microsoft Excel Microsoft Excel (see note) Lotus 1-2-3 Desktop Publishing E-Mail (none) Pegasus Aldus Pagemaker Pegasus Aldus Pagemaker Pegasus Mailstrom Scribe TeX MM Pine

Connectivity MS-DOS Kermit MS-DOS Kermit telnet, tn3270 C-Kermit telnet, tn3270, telnet, tn3270, ftp, Mac Kermit telnet ftp ftp tn3270, ftp -----------------------------------------------------------------------Note: UNIX-based versions of Lotus and WordPerfect are available, but we do not have them. Other more specialized applications such as databases, statistics, graphics, computer-aided design, and so forth, are likely to differ among different disciplines or departments and are presently be recommended on a University-wide basis. 4. LAN STANDARDS COMMITTEE The guidelines listed in the previous sections reflect current usage at Columbia and the computer, networking, and software marketplace, and are therefore fluid. It is recommended that a LAN standards committee be established to review and update these guidelines periodically. This committee should be composed of representatives from AIS, AcIS, and the departmental liaisons. Departments that do not currently have liaisons may appoint them. This committee would periodically revise the standards, and it would also consider requests for connection of nonstandard LANs to the Columbia network. 5. CENTRAL SOFTWARE LICENSING Licensing of desktop applications is a major area of concern. We recommend a centralized licensing office at the University to eliminate the enormous duplication of effort, waste of money, variation in the software products (and versions) in use in different parts of the University, and very likely widespread software piracy. By speaking with the authority of the University as a whole, a central software licensing authority would have considerable clout in dealing with software vendors, resulting in much more advantageous deals than individual users or departments could make by themselves. It could relieve countless individuals of the timeconsuming task of negotiating with vendors and finding the best price. It could enforce or encourage standards, keep software versions consistent and up to date, reduce the risk of virus infection, and protect the University from license infringement lawsuits. Recommendations for centrally licensed software should come from

the LAN standards committee. Software should not be licensed simply because it is a "good deal." Computer professionals must evaluate software for its fit into Columbia's computing and networking environment before it is centrally licensed. The items for which standards and site-licensing are important include not only applications, but also computer operating systems and environments--MS-DOS, Mac OS, Windows, OS/2, UNIX, etc--and network operating systems and their components, such as Novell NetWare and its many optional add-ons. The central licensing authority should handle the business aspects of licensing: license negotiation, negotiation of favorable upgrade and documentation policies, license administration, reports, software distribution, etc. Ideally, site-wide licenses would be negotiated to relieve us of the burden of detailed software metering and usage accounting. 6. CENTRAL LAN SERVICES The trend in computing over the past decades has been toward decentralization. When users and departments own their equipment they have control, they can build a customized environment, they don't have to share central resources that, when overpopular, become bogged down and sluggish. But as the number of computer users at Columbia continues to grow, the computer user community has become increasingly less technical. Where once the typical computer user was an engineering professor or student, today's typical user has no computer training at all and is just as likely to be an administrator, librarian, clerk, or AA as an engineer or scientist. Meanwhile, desktop computers are growing increasingly sophisticated. All claims of ease of use to the contrary, PC users require ever-increasing amounts of help in configuring and operating their PCs and using their applications. Networked PCs require even greater amounts of care and feeding, and ordinary users are even less likely to cope. Consequently, every department, possibly every office, in the University has its homegrown "computer guru" -- usually a person who was hired for some other purpose: a faculty member, an administrator, a graduate student. Each department develops its own unique environment, and often chaos ensues. The guidelines presented in this document, when published, might bring some order to the chaos, but they will result in little decrease in the duplication of effort and expense. Where once all computing was handled centrally in a consistent way, we now have thousands of people making their own way, and dozens (possibly hundreds) of others devoting considerable effort to computers and networks. In our view, this results in a degradation of the primary mission of the University: instruction and research. Significant economies of scale and efficiencies could be achieved by centralizing these efforts, freeing teachers to teach, researchers to research, students to study, and administrators to administer.

6.1. CENTRALIZED SUPPORT FOR DECENTRALIZED COMPUTING There are thousands of PCs, Macs, and UNIX workstations on Columbia desktops today. Their users prefer to work in their own familiar computing environments, but that doesn't mean that they also have to be computer system managers, operators, consultants, network specialists, software procurers, and technicians. A central organization can provide these and other services, freeing desktop computer users to concentrate on their real work. A centralized LAN service would consist of powerful, centrally located servers connected to the backbone network, reachable from any Columbia office or residence that is on the backbone network (which is presently being extended to interconnect most Morningside buildings). The benefits of this service would include: - Universal connectivity to central services, e-mail, and the world at large - Up-to-date, licensed, standard, consistent, interoperable applications software - Shared common resources: printers, disks, communications, etc. - Economies of scale in server hardware, software applications, and support personnel - Virus protection - Reliable service: * * * * * Redundant components File backups Hardware service contracts Extended coverage Round-the-clock network management and troubleshooting

- Enforcement of security and confidentiality - A centrally administered university-wide user ID system with authentication and security, hooked into the central personnel and student databases - Timely hardware and software upgrades - A consistent, supported, working environment for the whole University - Integration with central academic and administrative services - Education, training, support, troubleshooting - Operation and management by full-time dedicated computer professionals New services can be added simply by installing them centrally, and the whole University benefits at once. For example, PC- or Macbased Fax transmission and reception. Or a dialout modem server to eliminate the need for Rolm data phones. Centralized LAN service can bring a degree of consistency, reliability, and support to Columbia's computing environment that it has not enjoyed in nearly 20 years. This service is not meant to replace or compete with the services already offered in the Schools of Law, Business, and Medicine, but to bring LAN services to the rest of Columbia, particularly the small offices, departments, and residence halls. 6.2. THE COST OF A CENTRALIZED LAN SERVICE

Central LAN services have a cost: hardware, software, network, and supporting staff. We have estimated that to fully recover our costs for providing central LAN service, we would have to charge each user between $30 and $120 per month (see Appendix I). This is mostly for salaries; the servers themselves are relatively cheap, and the network is already in place (or soon will be). No academic user would pay this kind of money for central LAN service. Instead, they can buy cheap or used equipment, install their own wiring, copy software illegally, forego the service contracts, and shanghai a faculty member, graduate student, or AA to take care of it all. The result? Low-quality, unreliable service at a very high--but hidden--cost to the University, multiplied over hundreds of offices and departments: - The potential for software piracy lawsuits - The diversion of faculty, students, or staff members from their primary responsibilities - Unnecessary duplication of server hardware and server-based software - The time and work lost when files that have not been backed up are destroyed (See, for example, Columbia Magazine, Spring 1992, p.16, column 1.) - The inevitable havoc when the departmental guru leaves the scene - Obsolete unreliable equipment - Equipment that is never fixed once it breaks, or else costly time-and-materials service calls - Inconsistent, incompatible computing environments that do not promote communication or sharing of data, collaboration among different offices or departments. Our contention is that the University is already paying the costs. The aim of this proposal is to reduce the University's overall costs by achieving economies of scale and increasing everybody's productivity. 6.2.1. ADMINISTRATIVE USERS Eventually, administrative data will be made available to the properly connected LAN user -- i.e. the user who follows the recommendations in this report. Those who currently access this information via the 3270 network or Rolm data connection to the central administrative mainframe will be able to run distributed applications in windows on their desktop workstations, move the information to their spreadsheets for budget work, or to their word processors for proposals and reports. All within the consistent and familiar framework of their own desktop operating environment. Under the current decentralized, full responsibility budgeting model, centralized LAN services are possible only for administrative users, who have always paid a rather high cost ($200 per month) for access to administrative data. With income of this magnitude, AIS is positioned to switch these users from 3270 terminals or Rolmphone data connections to networked PCs, although a price adjustment might be required since the $200 fee also covers other components of the cost of administrative computing.

With a network connection, administrative users will have access not only to administrative data and services, but also to the entire array of central services: CLIO, ColumbiaNet, E-Mail, and the world at large. 6.2.2. ACADEMIC USERS Unfortunately, this approach leaves academic users out in the cold. Their budgets have never included this kind of money. Extensive discussions with departmental representatives have shown that a monthly network membership cost of $5 per user would be acceptable, $10 would be too high. Both of these figures are far lower than the actual cost of supporting a LAN user. $5 per month already gets them a Rolm data phone, with connection to central services including E-mail and ColumbiaNet. 6.3. FAIR TREATMENT Administrative data should be only one of the many central services available to the LAN user, and only one of many motivations for providing centralized LAN service. With the growth of Columbia's network, the potential for communication, sharing, and collaboration becomes vast, and the distinction between "administrative" and "academic" users increasingly blurred. For example, to which category does a researcher who must access grant account information belong? Or an instructor who needs to access student records? Or a University Vice President who needs to use CLIO and E-mail? We also feel that the manner in which central information services are presently delivered to administrative and academic users is inconsistent. It is in the best interest of the University to establish a consistent and affordable approach to network access from the University's departments, offices, and residence halls. This can be viewed as a purely business decision -- it saves the University money overall by achieving economies of scale, and it serves the University's mission by providing a high-quality and consistent environment promoting universal connectivity, freeing each office and department to concentrate on its designated role rather than on taking care of computers and networks. 7. PILOT PROJECTS In the interest of better determining the costs and benefits of providing centralized LAN service at Columbia, Academic Information Systems is presently engaged in several LAN-related pilot projects. AcIS is providing LAN access to PC, Macintosh, and UNIX workstation users in the Schapiro residence hall in Fall 1992, and to a lab in the Urban Planning department, as well as to PCs and Macs in AcIS computer labs. The Schapiro project will provide LAN connections to approximately 40 students, to extend our lab facilities into their rooms. Students furnish their own workstations. These will be connected to a central Novell server, and will also have TCP/IP access to our central services. A similar setup will be available in the Urban Planning and Gussman labs. These projects are being funded out of the current AcIS budget. Should they be expanded in the future, additional funding must be

found. As demonstrated in the Appendices, the fees required by direct cost recovery would be prohibitive. One way to offer LAN service to residence halls on a large scale would be to fund them in the same way as our current academic timesharing and laboratory operations are funded, in which the students pay (a small) part of the support cost, and the rest is furnished as part of the AcIS budget. In this case, the students would also pay for their network interface and cable. Appendix I. LAN Support Costs The Gartner Group, a computer technology market research firm, reports the appropriate level of LAN support staffing is one staff person to approximately 35 users (Determining LAN Staffing Levels, Local Area Communications, Gartner Group, July 10, 1990). This advice is reinforced by surveys in industry publications such as "PC Week." Using this ratio, the cost of LAN support, based on an FTE earning $30,000 plus 33.5% fringe, is $95 per user per month, or $1140 per year, per user. But, with a few exceptions such as the Law School, Business School, Lamont, and Health Sciences, we often find that the "computer gurus" within our departments are supporting fewer than 35 people. If they are supporting 20, the cost is $1995 per user per year. If they are supporting 10, it is $3990. To support five users, it is $7980. When the LAN support staff is concentrated centrally, economies of scale take effect. Now let's suppose we disagree with the Gartner Group estimate. Suppose we believe that the ratio is 1 staff to 100 users. That increases the economy of scale for central service, but it does not decrease the cost to small departments. If a department has some computer users, somebody (or part of somebody) in the department is supporting them. The following table itemizes the cost of supporting one user of a standalone PC (or Macintosh), and a single user on LANs of various sizes, with hardware and software costs spread over three years. These approximations are based on current prices for hardware and software, including typical educational promotions made by major software vendors, and include staff support as we have described it. -----------------------------------------------------------------------LAN Support Costs -----------------------------------------------------------------------Description Standalone Peer-to-Peer Dept Central LAN LAN -----------------------------------------------------------------------Users 5 10 20 250 3 Office Apps with Upgrade 200 60 45 44 Network Operating System 0 50 44 10 Server Hardware 0 0 125 30 Network Cabling and Hardware 0 30 50 50 Backups 20 20 40 13 LAN Support Staff 7980 3990 1995 1330 Total per user per year 8200 4150 2299 1477 Total per user per month 683 346 192 123 -----------------------------------------------------------------------LAN TYPES AND SUPPORT REQUIREMENTS

The table compares the costs in four typical scenarios: 1. STANDALONE PC's. Costs, for comparison purposes, are indicated, where applicable, for a department in which workers on nonnetworked PC's would purchase individual copies of office applications (word processing, spreadsheet, etc.), at singlecopy, educational prices. It is assumed that a typical office or department has one full-time-equivalent (FTE) employee supporting five users. If you don't accept this assumption, then assume somebody is doing it half-time. That brings the monthly cost per user down to $351. Even if only one quarter of someone's time is spent on PC support, the monthly cost per user is still $185. If no one at all is helping the standalone PC users, then these users are wasting a lot of time supporting themselves. Suppose each user is earning $30,000 and spends one hour per day on PC configuration and backup, software installation, etc. That comes to $433 per user per month! 2. TEN-USER, PEER-TO-PEER, NETWORK. A peer-to-peer network is one that does not require a dedicated computer for a file server. This is a low-end configuration that is only appropriate in settings where there is minimal sharing of network resources, but it is included here because its comparatively low cost presently makes it an attractive solution for some departments. It is only suitable for a very small number of workstations. One FTE support person is assumed. 3. TWENTY-USER DEPARTMENTAL LAN RUNNING NOVELL NETWARE. This configuration assumes the installation of a dedicated file server running a 20-user version of Novell Netware, the most prevalent LAN operating system on campus. In this scenario, the department still assumes responsibility for all LAN services. One FTE support person is assumed. 4. CENTRAL SERVICES. The central services model assumes a 250-user version of Novell Netware, with LAN software, file servers, applications, and services provided centrally. One FTE is assumed for each 35 users. This model can be expanded to serve any number of users without significantly changing the cost per user. If 100, rather than 35, LAN users can be supported by one central staff member, the monthly cost per user goes down to $45. If one central staff member can support 200 LAN users, the cost becomes $29. Currently this is the (optimistic) best we can hope for through training and standardization. The more users per staff member, the lower the cost of the service, but also the less one-on-one help can be provided. By concentrating on training and documentation, we can use our support staff more efficiently and reduce the demand for detailed personal help. The remaining costs of LAN service, including software, hardware, and network equipment and cabling, are relatively minor and are summarized on the following pages. OFFICE APPLICATIONS AND UPGRADE EXPENSES

We assume users will purchase three office applications (e.g., word processing, spreadsheet), with two or three upgrades over the three year period, and that, given current price structures, standalone users would pay about $125 per application, while networked users in all scenarios would be able to take advantage of "work group" pricing at the lower rate of $30 per application. In addition, we assume that the Novell LANs will license the third application for fewer concurrent users. STANDALONE COMPUTING: 3 applications at $125 each $ 2 upgrades at $125 each $ Total . . . . . . . . . . . . . $ $200/year per user PEER-TO-PEER NETWORK: 3 work group licenses at $300 each $ 3 upgrades at $300 each $ Total . . . . . . . . . . . . . $ $60/year per user DEPARTMENTAL LAN: 2x2 work group licenses at $300 each 1 secondary app at $300 each 2x2 upgrades at $300 each Total . . . . . . . . . . . . . $45/year per user CENTRAL SERVICES: 25x2 work group licenses at $300 each 10x1 secondary app at 300 each 25x2 upgrades at $300 each Total . . . . . . . . . . . . . $44/year per user NETWORK OPERATING SYSTEM This item covers the initial cost of Novell Netware plus regular, anticipated upgrades -- or, in the case of the peer-to-peer LAN, the cost of a low-end operating system on a per-node basis. PEER-TO-PEER NETWORK: 10 users at $50 each $ 2 upgrades at $50 each $ Total . . . . . . . . . . . . . $ $50/year per user DEPARTMENTAL LAN: Novell Server $ Upgrades $ Total . . . . . . . . . . . . . $ $44/year per user CENTRAL SERVICES: Novell Server $ Upgrades $ Total . . . . . . . . . . . . . $ $10/year per user 500 1,000 1,500 $ $ $ $ 375 250 625

900 900 1,800

1,200 300 1,200 2,700

$ $ $ $

15,000 3,000 15,000 33,000

2,160 500 2,660

5,000 2,500 7,500

NETWORK SERVER HARDWARE Prices here reflect the cost of a dedicated file server, hardware maintenance costs of ten percent per year, and a hardware upgrade cost of twenty percent over the three years. DEPARTMENTAL LAN: System Unit Hardware Maintenance 1 Upgrade Total . . . . . . . . . . . . . $125/year per user CENTRAL SERVICES: System Unit Hardware Maintenance 1 Upgrade Total . . . . . . . . . . . . . $30/year per user NETWORK CABLING The following are all per-user costs and include Ethernet adapters and maintenance. It is also assumed that do-it-yourself cabling is roughly equivalent in cost to Rolm-based cabling: PEER-TO-PEER NETWORK: Network Hardware Maintenance Cabling Total . . . . . . . . . . . . . $30/year per user DEPARTMENTAL LAN: Network Hardware Maintenance Cabling Total . . . . . . . . . . . . . $50/year per user CENTRAL SERVICES: Network hardware Maintenance Cabling Total . . . . . . . . . . . . . $50/year per user BACKUP COSTS Standalone Computing: $20/year per user in diskette costs Peer-to-Peer Network: $20/year per user in diskette costs DEPARTMENTAL LAN: Tape Backup Unit 20 tapes at $30 each Maintenance Total . . . . . . . . . . . . . $40/year per user $ $ $ $ 1,500 600 300 2,500 $ $ $ $ 0 25 5 30 $ $ $ $ 5,000 1,500 1,000 7,500

$ $ $ $

15,000 4,500 3,000 22,500

$ $ $ $

20 25 5 50

$ $ $ $

20 25 5 50

Central Services: Tape Backup Unit 20 tapes at $30 each Maintenance Total . . . . . . . . . . . . . $13/year per user APPENDIX II. LAN SUPPORT FUNCTIONS

$ $ $ $

5,000 3,000 2,000 10,000

This appendix lists the specific tasks required for LAN support. A central LAN service must be concerned with desktop applications, server operation, the LAN operating system, network configuration and operation, network and server technology, and more. USER SUPPORT The most critical and expensive factor in any LAN service organization is user support. The typical LAN user is not a computer expert. The complexity of LAN software and the interdependence of its many components -- not to mention the evergrowing size and complexity of application software -- baffle the average user. A typical complaint, such as "I can't print my WordPerfect document" could be traced to problems at almost any level, and only a highly trained well-rounded expert could be expected to pinpoint the problem to user error, application software problem, PC configuration problem, server configuration problem, network problem, printer problem, network hardware problem, network software problem, PC hardware problem, or other. As the number of inexperienced computer users increases, so does the burden on the supporting staff, and therefore the need for additional supporting staff. The user support staff has other responsibilities too: - Acquisition of new releases of centrally supported software - Evaluation of new software packages for compatibility with Columbia's computing and networking environment - Installation, configuration, and testing of new software for LAN use - Announcements of new software and services - Close contact with users to determine their needs - Education and training, including classes, online tutorials, and printed documentation SYSTEM SUPPORT Just as we have systems support staff for our central timesharing systems, UNIX, VM/CMS, and MVS, we also need systems support for the LAN servers and their operating systems. The functions are approximately the same as for the timesharing systems: To To To To To To To To select and configure the server system and its components keep the system up and running detect and isolate faults arrange for hardware repairs when necessary configure the system for the network tune the system for efficient operation monitor system performance and network load monitor system resources and expand them as required

- To customize the user interface with Columbia-specific messages and menus - To install software patches and new versions of operating system or network software. - To install other types of system software including mail servers, printer drivers, network adapter drivers - To allocate, define, and establish controls for system resources such as print queues, disk partitions, and special devices - To develop special software required for local needs, for example user ID management and authentication software tied in to Columbia's records or backup software tied in to Columbia's central backup servers. - To establish access control mechanisms: authentication, which users are allowed access to which resources, software metering and copy protection, etc. - To protect the server and its users against viruses and other security threats - To evaluate new hardware technology and new operating system and network software. - To establish and document routine procedures and to train operations staff - To keep users informed of news, impending events, changes, etc. NETWORK SUPPORT The network support staff takes care of the communications infrastructure that connects Columbia's computers and servers to one another. The network staff: - Plans and implements Columbia's overall network architecture and enforces standards for interconnection - Establishes procedures for monitoring and troubleshooting network problems - Monitors network performance, identifies bottlenecks, and upgrades components when necessary - Stays abreast of developments in network technology, protocols, and the marketplace OPERATIONS Routine operation of the server is handled by operations staff. Operations tasks include: - Backups (when not fully automated) - Restoral of lost files from backups - Round-the-clock monitoring of operation and notification of systems or network staff when faults are observed or reported