You are on page 1of 10

A New Way of Establishing Campuswide Standards and Recommended Solutions

This paper was presented at the 1996 CAUSE annual conference. It is part of the proceedings of that conference, "Broadening Our Horizons: Information, Services, Technology -Proceedings of the 1996 CAUSE Annual Conference," page 1-81+. 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. To copy or disseminate otherwise, or to republish in any form, requires written permission from the author and CAUSE. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303-449-4430; e-mail

A NEW WAY OF ESTABLISHING CAMPUSWIDE STANDARDS AND RECOMMENDED SOLUTIONS Joan Gargano Director, Distributed Computing Analysis and Support Information Technology University of California, Davis Davis, California

ABSTRACT The decentralization of computing, equipment purchases and the choice of software tools, fosters timely, innovative uses of technology and the development of departmental technical expertise, while leaving the institution with a wide variety of hardware and software and a need for some level of uniformity to minimize costs. Central information technology organizations are struggling with ways to define standards and common computing environments which are acceptable to more informed departmental staff, accommodates departmental solutions and benefits from departmental experience and technical expertise. The Technology Support Program (TSP) at UC Davis was launched in July 1995 to form closer alliances between the central information technology organization and individual departments on campus. As part of this effort, the TSP oversight group looked for ways to involve departmental support staff in the definition of campuswide standards. A process for creating, evaluating and publishing campuswide standards which relies heavily on the use of mailing lists and the World Wide Web, was derived from the Internet Engineering Task Force "Request for Comments" process and modified to fit the University environment. This revised process was used to create five "Recommended Solutions" which were well received by the campus community. An overview of the process, the first set of Recommended Solutions, and our experience to date is presented.

THE NEED FOR STANDARDS AND RECOMMENDED SOLUTIONS Much has been written about the difficulties encountered in supporting a distributed computing environment. The decentralization of computing increases the number of people empowered to make choices in technology purchases and moves the choice of equipment and software tools from central IS organizations to departments. While this fosters timely, innovative uses of technology and the development of departmental technical expertise, it leaves the institution with a wide variety of hardware and software to support and a need for some level of uniformity to minimize costs. Most organizations have come to the conclusion that the traditional methods of centrally supporting technology do not work in this new environment. There is a need to draw upon and support local technical experts to build a network of technical support staff. The Technology Support Program (TSP) at UC Davis was launched in July 1995 to form closer alliances between the central information technology organization and individual departments on campus. As part of this effort, the TSP oversight group looked for ways to involve departmental support staff in the definition of campuswide standards. The group looked for examples of successful, collaborative, standards processes to provide a framework for campuswide standards development. It chose the standards process used by the Internet Engineering Task Force which has developed the protocols and standards for the Internet. A BRIEF OVERVIEW OF THE INTERNET ENGINEERING TASK FORCE STANDARDS PROCESS The Internet Engineering Task Force (IETF) is the protocol engineering, development, and standardization arm of the Internet Architecture Board (IAB), a technical advisory group of the Internet Society. The IETF is a large, open, international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet protocol architecture and the smooth operation of the Internet. The InterNIC maintains several archives that contain documents related to the Internet and the IETF activities[1]. The Internet Engineering Task Force is a loosely, selforganized group of people who make technical and other contributions to the engineering and evolution of the Internet and its technologies. It is the principal body engaged in the development of new Internet standard specifications. Its mission includes: * Identifying, and proposing solutions to, pressing operational and technical problems in the Internet; * Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for

the Internet; * Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet; * Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community; and * Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors and network managers. The IETF is made up of volunteers who meet three times a year to fulfill the IETF mission. There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or working group mailing lists.[2] The primary activities of the IETF are performed by committees known as working groups which tend to have a narrow focus and a lifetime bounded by completion of a specific task. The goals of the IETF process is to produce an Internet Standard as a specification that is stable and wellunderstood, is technically competent, has multiple, independent, and interoperable implementations with operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. The IETF standardization process is intended to be as informal as possible, providing a framework to ensure the timely publication of standards, while continuing to avoid unnecessary bureaucracy. The procedures attempt to provide a great deal of flexibility to adapt to the wide variety of circumstances that occur in the standardization process. WORKING GROUP FORMATION IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended as standards or recommendations. A working group may be established at the initiative of an IETF Director (AD) or it may be initiated by an individual or group of individuals. A working group is typically created to address a specific problem or produce a deliverable (a guideline, standards specification, etc.) and is expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group as a unit is terminated. FORUMS FOR DISCUSSION Once the need for a working group has been determined, the group is formed with a charter and timeline. The IETF

requires open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus". The activities of the working group take place primarily through discussion and the exchange of working documents through electronic mail. Drafts are submitted to an online repository by the working group chair before each meeting . The Working Group Chair is concerned with making forward progress through a fair and open process, and is responsible for: * Managing the working group's process and content management * Moderation of the email list * Organizing working group sessions * Communicating the results of sessions * Distributing the work to volunteers * Document development * Document publication Working group participants meet three times a year to discuss the contents and status of the document in the standardization process. Once the group reaches consensus that a standard and its documentation is complete, the materials are submitted into the standardization process. AN OVERVIEW OF THE RECOMMENDED SOLUTIONS PROCESS Recommend Solutions documents are intended to provide the campus with timely information on hardware and software solutions for campus computing. These documents describe commonly used solutions and "best practices" in the campus environment. Unlike standards produced in the IETF, these solutions are optional and do not specify or mandate the use of specific protocols or software. The information is presented in a format to assist local department experts to assess the value of the recommendation and applicability to their environment. Recommended Solutions drafts are usually created as the result of an individual or workgroup tasked with solving a specific technical problem. The most successful documents are small focused recommendations rather than larger comprehensive ones and there is a preference for the presentation of a limited number of options. For example, rather than writing a draft that focuses on a basic configuration of a desktop computer including hardware and software, this problem should be subdivided into separate smaller efforts such as recommendations for hardware platforms and individual classes of software, i.e. word processors or spreadsheets. The options provided should not be a compilation of products available on the market but just the top contenders based upon careful evaluation of applicability or widespread use on campus.

Recommended Solutions can be created by an individual, a departmental working group or a campuswide working group. The process relies on suggestions, submissions and participation from technical staff within the central IS organization as well as departmental experts. The appropriateness and accuracy of the recommendation must be discussed, reviewed and by participants in the Recommended Solutions mailing list before officially gaining "Recommended Solution" status and being distributed campuswide. It is expected that recommendations will be consistent with the campuswide architecture for a distributed computing environment which is based upon open protocols in a TCP/IP based network environment. Campuswide applications should comply with such standards and localized applications, that are limited to a single LAN or department, should attempt to comply with these standards whenever possible. In all cases, recommendations must address the issues of scaling, interoperability and cross platform support. Recommended solutions documents are proposed on the recsol listserve by anyone who has something to contribute and continue under development if there is consensus that this topic warrants further effort. The person proposing the new Recommended Solution is responsible for creating, or working with other authors to create, the first draft as a starting point for discussion. The members of the recsol mailing list are all equally responsible for reviewing posted documents and ensuring forward progress through a fair and open process. THE RECOMMENDED SOLUTIONS LISTSERVE The Recommended Solutions listserve serves as a forum for: * the submission of FYI (described below) and Recommended Solutions documents * discussion and updating Recommended Solutions documents * votes to determine the status of Recommended Solutions documents Since many of the documents are improved by the use of tables and formatting, Microsoft Word format was chosen as the standard format of submissions. This requires list participants to ensure that their email system supports the receipt of uuencoded Microsoft Word documents. RECOMMENDED SOLUTIONS ETIQUETTE The recsol mailing list is an online forum for the discussion of technical solutions. As such, it is expected to generate the posting of a variety of opinions on the draft document and constructive criticism. This should result in the modification of the document for technical accuracy and to reflect the consensus of the recsol listserve participants. Consensus for this process is defined as, a general agreement, or the judgment arrived at by most of those

concerned. This means that as part of the discussion, individuals must assess the points of contention that are most important to them and advocate the inclusion of that information. At the same time, individuals must be willing to concede minor points in the spirit of reaching agreement in a timely fashion. An author who is unwilling to modify a document to reflect the consensus of the group will be unable to get approval to move the document to "Recommended Solution" status. Therefore it is important for participants to approach the process with a willingness to debate, negotiate and modify drafts as appropriate. RESPONSIBILITIES OF THE PARTICIPANTS The Recommended Solutions process relies on the proactive participation of members of the recsol mailing list. Information will be posted to the list with deadlines for review. Silence implies consent. It is incumbent upon the participants to read recsol email, comment and vote in a timely fashion. Otherwise opinions and technical requirements of an individual may not be reflected in the final document. THE RECOMMENDED SOLUTIONS PROCESS The following process for discussion and decision making takes place on the Recommended Solutions mailing list. * A draft document must be submitted by an individual who will take ownership of the document. * Debate on the draft will continue for up to two weeks. * At the end of 2 weeks, the author can call for a vote of approval or post a revised draft. * Draft documents will expire within 2 weeks of the posting unless revised and reposted or approved by a vote. * A Recommended Solutions draft can be reposted 3 more times. * If a final draft is approved on the list prior to the expiration of any of the 4 postings, the document will be submitted to IT Publications for final editing and for posting on the World Wide Web. * If a final draft is not approved by consensus after the fourth posting, the document will expire. DOCUMENT STRUCTURE A Recommended Solution document should be submitted as a Microsoft Word format document with the following sections. A template is available from the UC Davis Recommended Solutions Web site[3].

[DATE] Document Status (drafts only) All draft documents must include the following statement: This document is a Recommended Solutions Draft. Recommended Solutions Drafts are draft documents, valid for a maximum of two weeks. Recommended Solutions Drafts may be updated, replaced, or made obsolete by other documents at any time. This document was submitted by (author(s)) on (date). Description The document should have an introductory section, containing a two-to-three paragraph description of the hardware or software solution. The description should briefly describe the type of hardware or software, its common use and any key issues for consideration. Recommended Solution This section can be formatted in any fashion, but it is recommended that it be succinctly presented in two to four pages and tabular formats used if possible. The information should include, as appropriate, how the solution applies to all commonly used computing platforms (i.e., MS-Windows, Macintosh, Unix), estimated lifetime for the recommendation and purchasing sources. Technical Support This section must address where technical support can be found for this product. If the central IS organization does not have staff to support this product, it must be explicitly stated. If expertise exists within departments, all listed departments and staff must approve their inclusion in this section. Technical support should include all relevant mailing lists, Usenet newsgroups, World Wide Web servers and user groups. Expiration Date This is the date that the document will expire or be reviewed next for renewal, usually one date from approval as a Recommended Solution. Document Owner This is the individual who will take responsibility for the document and ensure that it is resubmitted for renewal at least 2 months prior to the expiration date (4 rounds of review take up to 8 weeks). This will usually be the author, but can be assigned to another individual.

THE FIRST SET OF RECOMMENDED SOLUTIONS The first five Recommended Solutions documents all resulted from workgroups and produced a wide range in the specificity of the recommendation. Personal Computing Hardware - A Standard The Hardware Recommended Solution document is very specific in its recommendation of CPU type, memory, hard drive capacity, and monitor size. The document describes the lifecycle of desktop computing, the positioning of older computers in this cycle and recommendations for purchases. The first draft was produced by a single individual and revised with input from recsol participants. This recommendation is the closest Recommended Solution to a standard. Database Query Tools - Accommodating Solutions in Use The database query tools document describes the common uses for this type of software and the 5 most commonly used packages. The system requirements for each package and purchase information is summarized. This document summarizes the recommendations of earlier working groups with the inclusion of two software packages based upon knowledge of their pervasive use on campus. This recommendation is primarily informational. Electronic Mail - An Uneasy Compromise The campus electronic mail standard is based upon the POP and SMTP mail protocols. The University of California, Davis provides Eudora to all University affiliates through a site license. However, many departments have chosen to run their own LAN based email systems. This Recommended Solution required a compromise between the central IS department and departmental technical staff to acknowledge the benefits of both solutions and the decision factors for choosing one over another. Scheduling & Groupware - A Soft Recommendation Scheduling and groupware software suffers from the absence of accepted standards for interoperation and problems with scalability. None of the leading packages met the requirements for open standards or provide a campuswide solution. As a result, the leading packages are described and one package is recommended with the caveat that evolving standards may quickly alter the relative standings of the products. Document Imaging - Just One of Many Potential Solutions

This document resulted from the evaluation of document imaging solutions by the Library. This Recommended Solution focuses on evaluation criteria for document imaging solutions and describes the benefits of the package chosen by the Library. OUR EXPERIENCE TO DATE The response of the campus to the Recommended Solutions documents has been overwhelmingly positive. The first document on hardware configurations is routinely used by departments for planning equipment purchases and the ongoing budgeting for replacement costs. Once the Recommended Solutions process was in place, the group noticed a need to notify others of evaluation processes that bring interested parties together, but may not necessarily result in a recommended solutions document. These groups may be investigating very specific hardware or software products, i.e. video boards for high end multimedia development work, or performing a preliminary scan of products to determine the maturity of a potential solution. FYI documents were developed as a method for this type of notification. FYI (For Your Information) documents are documents that can be posted by anyone to notify the list participants of an activity to evaluate hardware and software solutions for any type of computing. These notices should include the following information: * Problem Statement * Current Technical Solution Under Investigation/Evaluation * How To Participate in the Investigation/Evaluation (Listserve lists, CAIT demonstrations, beta test programs, etc.) * Contact Person The notice is posted to the Recommended Solutions World Wide Web server for 6 months and must be renewed by the FYI author if the evaluation is not complete and the FYI should remain available. Subsequent to the first round of intense activity to develop Recommended Solutions as part of the Technology Program, three other documents have been proposed. Student Personal Computing Hardware A Recommended Solutions document for student personal computing hardware was developed to extend recommendations of the first hardware recommendation document to address the needs of students. It benefits from earlier work by using the same format which clearly lays out options in a tabular format. This document was drafted by a single individual who is also responsible for the earlier hardware document.

Internet Tools An ongoing workgroup which predated the Recommended Solutions process, volunteered to fold their work into the new process. This group was the first group to post an FYI document that announced their work to review the networking features of Windows 95. An Attempt To Define LAN Server Standards A small group of technical staff proposed a Recommended Solution document to recognize Windows NT as the network server operating system standard for the campus. Several participants objected to such a narrow definition of options, noting a number of large Novell server installations. Participants suggested a modification of the first proposal to recognize both LAN server operating systems as viable options. The document was not updated to reflect a broader set of options and it expired without approval. All of the original five Recommended Solutions documents have passed their renewal date Three required updates which were unanimously approved on the recsol mailing list. Two did not need revision and remain posted with their original recommendations. CONCLUSIONS The Recommended Solutions process has been successful in providing a way to define standards and common computing environments which are acceptable to more informed departmental staff, accommodates departmental solutions and benefits from departmental experience and technical expertise. This informal group includes many staff members in departments and the central IS organization who participate because it provides a way to gain consensus on technical standards and guidelines and helps to provide a common sense of technical direction. Recommendations are produced with equal success via workgroups or email-only discussions and the results are enthusiastically received by the campus at large. ============================================================= ENDNOTES [1] [2] Malkin, G., "The Tao of IETF -- A Guide for New Attendees of the Internet Engineering Task Force", Request for Comments: 1718, FYI: 17, October 1994. [3]