Providing Access for the Scholars Work Environment (SWE) Copyright CAUSE 1994. This paper was presented at the 1994 CAUSE Annual Conference held in Orlando, FL, November 29- December 2, and is part of the conference proceedings published by CAUSE. 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 CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303-449-4430; e-mail info@cause.colorado.edu PROVIDING ACCESS FOR THE SCHOLARS WORK ENVIRONMENT (SWE) Donald Carder and James Penrod California State University, Los Angeles California Abstract California State University, Los Angeles provides a common interface for all academic PCs, MACs, Clones, Workstations, etc. connected to the campus backbone. This encompasses all full time faculty, many academic staff (approximately 1400 user nodes), and 34 academic labs. This fully distributed system has some 27 network servers, 18 subnets, and supports nine different operating systems. The SWE interface appears on any desktop machine when it is booted and provides icon and pull down menu access to the many digital resources (Information Resources: reference, text, numeric, image and relational databases; Computing Resources: application, print, file, timeshare and client/server services; Communication Resources: mail, bulletin boards, electronic conferences, network news and list servers.) available through the campus, CSU, regional, and national networks. This paper will discuss the longer term goals, conceptual objectives, primary technical barriers that had to be overcome, the network design, an incremental development plan, and the academic utilization of the releases of SWE. INTRODUCTION In 1985 California State University, Los Angeles (CSLA) created an information resources management (IRM) division headed by a vice president as chief information officer (CIO) for the institution. The resulting organization encompassed all computing, communication and network units and policy responsibility for all information technology on campus. The CIO was initially charged to plan, develop and implement (1) a campus-wide communication system and network, (2) an academic computing environment, and (3) an integrated administrative system that would meet the needs and help prepare the university for the educational challenges of the twenty-first century. By the early 1990's the basic infrastructure for the accomplishment of these broad based goals had been built. A digital telephone system and fiber optic network had been installed. A fully distributed academic support system with 34 computing laboratories, 27 network servers, and 18 subnets supporting nine different operating systems was in place. And, integrated administrative systems developed in DB2 were operational. One very important contributing aspect to this progress was the adaptation of a strategic planning and management methodology to the decision making processes of the institution. In early 1986 CSLA selected the Shirley Strategic Planning Model [1] as the best alternative for implementing a strategic planning process campus-wide. In addition to the university strategic plan, some nine institutional tactical (action) plans, including an IRM plan, were designated to be developed and directly coupled to the budgeting process of the campus. GOALS FOR SCHOLARS WORK ENVIRONMENT The Shirley methodology was specifically modified to accommodate information technology planning [2] and the first draft of a Strategic Plan for Information Resources Management at California State University, Los Angeles was issued in July 1986. The following quotation from that initial planning document pointed to the eventual development of a scholars work environment (SWE) for the academic community at CSLA.[3] Planning for student and faculty access to information resource technologies at Cal State LA is inexorably linked to curriculum planning and development. Curriculum methodologies must be appropriate to the desired educational objectives; namely, literacy in content and literacy in discipline specific tools and techniques. Information resources technologies, essential tools and techniques required in all professional fields, must be learned concomitantly with the content of one's own field. ... Timely and adequate access to these appropriate "educational tools" are becoming a standard expectation of both students and faculty alike in all academic disciplines. Areas which formerly depended solely on access to large mainframe systems are now committed to the selection of computing power and software appropriate to the instruction and learning of each course. By January 1988 the IRM plan endorsed a California State University (CSU) System needs assessment declaring that faculty needs for desktop computers uses included: (1) facilitating the development and updating of lecture, laboratory, and self-instructional materials, (2) enhancing the management of courses, (3) promoting the effective integration of computing into courses (by facilitating the preparation and pretesting of computer-based materials and student assignments, allowing students and faculty to interact as the students work on those assignments, and making easier the development and sharing of data bases and innovative courseware), (4) enhancing student advising, (5) providing means for instructional and scholarly activities such as data acquisition and analysis and bibliographic searches, and (6) facilitating the deliberations of university committees.[4] The full design model for SWE was completed and set forth in the 1991 IRM plan. It had seven primary goals. Human Factors Design. The organization of the system interface (what you see on the screen and how the resources of the network are presented) is based on the way people work and the intellectual tools being applied. Client-centered Work Environment. The network resources are to be organized around the work environment and the logical center of the work environment is the individual. Each individual can organize the available resources to construct a unique work environment and the logical system of the network will recognize the individual and reconstruct the "virtual" work environment at each session. Heterogeneous Network. The network resources are to be supplied by multiple vendors and the adoption of "open systems" standards is to allow for procurements to be based upon price/performance criteria. Hierarchical Compute Platforms. A range of computer resources are to be available across the network. This allows network clients to assign compute and file service tasks to the class of machine appropriate to the job(s). Distributed Network. The resources necessary for the session are localized. The resources of the network are distributed throughout the system on the basis of utilization. The unique resources are available across the system. Fully Integrated System. The information technologies for support of academic programs are integrated into a campus- wide network which appears and functions as a unified resource. Transition Strategy. The aim is to move from the existing environment to the target environment without loss of system functionality or a devaluation of client (faculty or student) expertise.[5] The primary objectives then in developing a SWE were to make information resources available to the entire academic community, to lesson the learning curve to negotiate a complex network, to provide an easy way for scholars to know about available resources, and to economically provide a wide range of instructional and research applications to an extensive and varied academic audience. NETWORK DESIGN AND TECHNICAL CHALLENGES The majority of computing resources used for instruction and research at Cal State LA are part of a campus wide, distributed network known as the Instructional Support Information System (ISIS). The ISIS network includes public access facilities with desktop machines for academic computing; data communications systems providing access to local, regional, and national networks; large computers and servers providing shared computational, storage and printing services; and digital messaging services for student/faculty and peer communications. In the framework used for the design of SWE, the computing, information and communications resources (see Figure 1) of the system are known as the resource schema and the purpose of SWE is to provide a map of those resources. [FIGURE 1 NOT AVAILABLE IN ASCII TEXT VERSION] The backbone for the ISIS network is a FDDI ring. Each of the academic buildings is connected to the backbone via a router which can support up to 12 Ethernet subnets and two FDDI subnets. The ISIS servers are UNIX systems, ranging in size from a mini supercomputer to Intel based systems. The majority of servers are SunServers. The primary servers used for the student and faculty /home accounts are large SunServers and are being attached directly to the FDDI ring via the FDDI subnets. Approximately 10 percent of the desktop workstations are UNIX machines, 20 percent are Macintoshes, 30 percent are Intel machines running MS-DOS, and the balance or about 40 per cent of the academic desktop workstations are MS-Windows based machines. Virtually all of the 1400 workstations are connected to the network via an Ethernet subnet. Some 600 of the workstations are in faculty offices (all full time tenure track faculty) and the balance are in open access labs and computer classrooms. In addressing the design of the SWE, the primary objectives for SWE (previously listed) had to be balanced with the need to make the operation and management of the ISIS system as efficient and economical as possible, from the perspective of the system administrators. The critical factor in accomplishing both the objectives for SWE and the management of the ISIS is to achieve coherency i.e., to ensure that the ISIS system as a whole has logical integrity and consistent behavior. For both the end user and the systems administrator the structure of the system has to make sense and the way tasks are to be accomplished has to be consistent and predictable. However, the perspectives of the end users and the systems administrators as to what would give the system coherency were initially very different. From the systems administrators perspective, the ISIS was made up of a set of distributed systems hosting heterogeneous resources. This view of the system derived from the functional definitions of and relationships between the ISIS system components. To achieve coherency, in this view of the system, the implementation of the enabling technologies used to deliver network services has to be rational and the operation of the system as a whole has to be predictable. The systems administrators view of the system (or the way the system is defined and operated at the network and operating systems level) is known as the logical schema. From the perspective of the end users, the ISIS system was a complex array of distributed computing, information and communications resources accessible through an even more complex and often baffling network technology. Frequently, users had no idea nor did they care what system they were on or how they got there. To achieve coherency and make the resources of the ISIS useful from this perspective, resources must be presented in such a way as to make them readily accessible and applicable to the pursuit of academic activities. The end-user's view of the system, or the way the ISIS is presented to the end-user is known the systems architecture. Together, these three views, resource schema, logical schema, and systems architecture provide the model for the design of SWE.[6] The technology used to implement the logical schema is Sun Microsystems' Domain Name Service (DNS) and the Open Network Computing (ONC) suite of service and protocols. The network services elements which make up the ONC suite are; (1) the Network File System (NFS) which provides access to remote file systems; (2) the Network Information Service (NIS) provides authorization and authentication services and the ability to automatically mount and unmount resources for network computing; (3) the Network Lock Manager which allows users to coordinate access to common information by providing file and record locking across the network, and (4) REX (Remote Execution) which allows users to execute commands or programs on remote systems. The ONC technologies enable a microcomputer on the network to operate as a "virtual workstation," (see Figure 2) attaching to resources such as printers, disk drives, and CD-ROMs as though they are part of the local machine. One early problem was that the systems architecture provided by the ONC services was inadequate for a complex information environment and required a level of expertise beyond that of most users. For those who could master the network technology, there was the additional hurdle of knowing and keeping track of what resources were available. The task, then, was to develop an additional layer for the logical schema which would make the resources readily accessible and map the resource schema to a systems architecture which would be meaningful to the scholar. [FIGURE 2 NOT AVAILABLE IN ASCII TEXT VERSION] Since the desk top computers of the ISIS have heterogeneous operating and presentation environments, client/server technologies were chosen to present the resource schema in the metaphor of each native environment. In this model, the client software is the systems architecture or SWE, presenting all of the resources available to the "virtual workstation" as a coherent whole. The server technology maintains the intelligence about where and how to access the resources of the ISIS (see Figure 3). The server software is known as the Campus Network Operating System (CNOS). In the design framework, CNOS is an additional layer of the logical schema. CNOS resides on the UNIX servers. SWE applications have been developed for MS-DOS, MS-Windows, UNIX and a Macintosh version is currently in development. To accommodate the different needs of the end user and the systems administrator, and to ensure coherency and logical integrity for the logical schema and the systems architecture, the design responsibilities were divided. The SWE team focused on the needs of the user and the CNOS team focused on the "backend" or the enabling technologies. The objective for the SWE design team was to create an electronic work environment which facilitates the integration of SWE resources into the information handling processes of the teacher, learner, and researcher. The organizing principle of the design was to be the practices of scholarship. The design had to accommodate the way scholars work, supporting the flow of scholarly activities as a unified process. It should reflect the following: * scholars acquire new skills based on existing skills; * scholars identify and seek out diverse pieces of information (documents, data sets, sounds, and images) on the basis of commonly known and meaningful attributes; * scholars organize their work, materials, and information around their own knowledge; * scholars seek and find information in the larger universe (all available sources) of information and move it into a personal collection which is relevant to their work. The flow of information into the work environment is complimented by the flow of analysis, commentaries, new theories and ideas back out to the community at large (see Figure 4). Accommodating the flow of information into and out of the scholar's work space is a critical function which must be supported by SWE. [FIGURES 3 and 4 NOT AVAILABLE IN ASCII TEXT VERSION] The principle challenge to the CNOS design team was to make the system dynamic. There were four fundamental conditions in the academic computing environment which could only be addressed with a dynamic system. First, the relationship between the resource schema and the presentation technologies had to be dynamic. One of the critical problems which had to be addressed was the broadcasting of meta information. SWE had to pick up information about new resources available via the network dynamically. Second, the system had to be user sensitive. Students do not have personal workstations on campus. If the goal for a "client-centered" work environment was to be met, the system had to support the dynamic configuration of virtual workstation based on the unique needs of an individual at any desktop workstation accessible to students in any laboratory. Third, the system had to be workstation sensitive. The desktop environment was heterogeneous. The system had to match the capabilities of specific machine to software versions and devices. And fourth, the design had to be location sensitive. To reduce network traffic and optimize performance, the system had to connect workstations to the closest appropriate server and avoid unnecessary routing over the backbone. In summary, the academic computing environment at CSLA must include all of the computing, information, and communications resources relevant to scholarship. The system should be established as a distributed, fully integrated work environment. Access to the distributed resources should be possible from all environments in which scholarly activities take place. The distributed resources available through the network should be presented to the individual scholar as a coherent whole. The presentation of the whole system at the scholars work station should be done in such a way as to make it possible for the system to become an integral part of the teaching, learning, and research processes. The electronic work environment and the scholar's workstation should facilitate the free flow of information and ideas between teachers and learner and their peers. Finally, the system should operate efficiently and economically. IMPLEMENTATION STRATEGIES To initiate the SWE/CNOS project, it was decided to develop prototypes for the subsystems software. The intent was to address the most critical service needs and to validate the feasibility of the foundation technologies. A fairly simple methodology was adopted for the first prototypes. A set of preliminary design goals were developed for the whole fully featured system. Implementation objectives were established, and analyzed in terms of their order of dependencies and based on those dependencies a schedule for development was established. This established a preliminary implementation plan for a series of subsystem prototypes. Over the course of the project, progressively more complex prototypes (prerelease's to the fully featured product) were developed, tested, and installed as operational modules. A more complex methodology became necessary to maintain progress on the project. There were several serious tactical problems in the design and implementation of the SWE and CNOS which had to be accommodated in the methodology and management practices. First, the size and scope of the project relative to the limited availability of human resources made it necessary to have a prolonged life cycle; for all intent and purpose it was open ended. It took two years to deliver a product which met the initial design goals and implementation objectives. Second, the ISIS system at both the resource and the logical level was constructed using "off the shelf" proprietary technologies which were evolving and changing over time. The detailed specifications of the subsystems technologies could not be known until the final phases of each implementation cycle And third, many of the service problems this system was intended to solve were critical and had to be addressed as quickly as possible. It was necessary to deliver functional modules over the course of the project to address the most critical service problems. And, these modules had to be incorporated into the long term design. In summary, this was a large, complex, and long range project targeted to solve pressing problems using technologies which were not fully known. The length of the project life cycle combined with continued changes in the enabling technologies was a threat to the logical integrity for the logical schema and systems architecture. Several techniques were used to address this problem. First, "open systems" standards were adopted. These standards were incorporated into the IRM plan in 1987. Second, the analysis and design process was done iteratively, key to the release of prototypes. Each iteration included: a re-assessment of the service needs and priorities, an analysis of the enabling technologies, testing compatibility for integration in the ISIS, and review and modification of design goals and implementation objectives for CNOS and SWE. And finally, responsibility for the systems software on all workstations attached to the network was assumed by the Academic Technology Support (ATS) unit. This included the operating systems, presentation management packages such as MS-Windows and X.Windows, network software, and SWE. These packages were bundled into a product known as the System Software Suite and distributed in releases which had been tested for compatibility. ACADEMIC UTILIZATION OF SWE The academic utilization of SWE has two perspectives. The first is institutional. It is imperative that the academic community understand how to operate in a complex distributed network to find and use the numerous available resources. Therefore the training that is provided from Academic Technology Support focuses on acquiring the basic skills needed to comprehend and utilize the SWE (which enables easy identification and utilization of desired resources). This is supplemented by the Library which has chosen to use the Environment section of SWE as the organizing principle for the training they offer to faculty and students. They also provide discipline specific training focusing on specific network resources appropriate to different sectors of the university. The second perspective is individual. Some faculty use SWE to organize and specifically identify network resources for student usage. For example, to create an icon for a particular class which directly connects to resources required in that class, e.g., databases, a bulletin board, etc. Others may wish to focus the use of SWE as an access tool to the various databases and information repositories available on campus and off. One professor has eliminated the use of a readings text altogether in a graduate seminar that explores current issues in the field. FUTURE RELEASES OF SWE The most recent release of SWE (just being implemented) includes Explore, a facility allowing a scholar to "click" on a pick or an icon and pull down one page of information describing the resources available. It will also provide direct access to World Wide Web (WWW) and other significant search elements on the Internet. Future releases will move to an object-oriented interface for the workspace, introduce Near Information which will integrate personal information management tools with annotation, note taking, and theme development tools, enable frequently used picks and icons to be dragged from the Environment into personal workspaces, and introduce the ability to automatically publish resource locations in the Environment. CNOS will be expanded to keep track of each scholars unique configuration and to provide it wherever that individual signs on the system. MATCHING THE ORGANIZATION TO THE SYSTEM The organization primarily responsible for the development, administration, and support of the ISIS system, including SWE and CNOS, is the Academic Technology Support unit. ATS has been reorganized six times since its creation in 1986. Part of this was due to growth; the organization has grown from one manager and two full time staff with approximately 20 student and graduate assistants to two managers and over 30 full time staff with some 50 student and graduate assistants. But the primary reason for the reorganizations (and the growth) has been the need to adapt to the entity being created and supported. Currently, there are six work groups. * The Administrative Office Group which is made up of two clerical and two managers and is responsible for fiscal, personnel, and user support. * The Instructional Technology Group which is made up of nine facilities managers, trainers, and consultants and is responsible for user support. * The Network and Distributed Systems Group which is made up of five network and systems administrators and is responsible for the UNIX servers, network management, and the development and maintenance of CNOS. * The Network Information Services Group which is made up of four analysts and software specialists and is responsible for the development and support of information services, the systems software for workstations, network applications and administration of SWE. * The Systems Development Group which is made up of five systems analysts and programmers and is responsible for procurements, product and project management. * The Technical Services Group which is made up of five equipment technicians and is responsible for the wiring plant, facilities installations, and workstation maintenance. A continuing challenge for ATS is organizational integration reflective of and comparable to the integration attempting to be achieved with the systems being installed. During the initial growth period, when the focus of the organization was development, the primary instrument for organizational integration was project management. The Systems Development Group drew upon the personnel resources of all the work groups to put together project teams to bring up new systems and to develop the administrative procedures to support those systems. On completion of a project, ongoing support and administration was turned over to the work groups. The ATS organization is flat and the management of the work groups is dependent upon informal communications systems such as Email and a BBS, but the management tools are fairly traditional. The creation and growth of the other groups were driven by development and support issues. As the system matured, however, projects have ceased to be the driving force for integration and adaptation. It is the responses demanded by increased systems utilization and user input regarding the effectiveness and efficiency of the systems architecture which are driving the refinement of systems and services. The project managers are involved in changes to the system much less frequently and the group supervisors tend to have a much more vertical perspective of the system and lack the understanding or sensitivity to the whole system to ensure true systems integration and coherency in the systems architecture. A solution for this problem is not offered, and it is believed that the current method for managing operations is not as effective as it needs to be. A decision has been made to experiment with the techniques of total quality management. The emphasis on crucial processes and service outcomes, which translates into coherency for CNOS and SWE, are very intriguing. CONCLUDING OBSERVATIONS During the course of development, implementation, operation, and evolution of this system some lessons have been learned that are seen as important and worth sharing. "Whole Systems" View. The system must be viewed as a whole. This was anticipated in the early stages of the project which was dominated by design and development. The system had to be viewed as a whole to achieve logical integrity in the design. As the project matures, it has been learned that maintaining a "whole systems" view is equally important for administration. In the first three weeks of the 1994 fall quarter there was at least a 50 percent increase in utilization for the system as a whole and a 100 to 150 percent increase in load for some of the larger servers in the system. This demanded treating ISIS as a dynamic, fluid system. It was necessary to begin "floating" or redistributing services on a daily basis to balance the load across the whole system. This was possible because the system is viewed by the user as a whole, vis a vis the SWE interface, and is viewed by the systems administrators as a whole by virtue of the fact that they could match the complete inventory of services to all resources within the system with minimal interruption of services. A Single Solution Strategy. The development of the Scholar's Work Environment and the Campus Network Operating System have become the organizing principle to all of the ATS organization's attempts at offering technology solutions to the university. Initially, the use of SWE as the avenue for offering services to the campus came from the ATS organization. Increasingly, however, the use of SWE as the organizing principle for the definition of needs has come from the academic community. Faculty, librarians, and student organizations have all asked to contribute to the extension of SWE services. In fact, SWE is a wrapper for a fully integrated, heterogeneous, distributed computing system. But faculty and academic planners do not think in terms of "fully integrated, heterogeneous, distributed computing systems." SWE has become a metaphor for describing the information, computing, and communications resources needed to carry out scholarly activities in a complex information environment. It is much easier for students and faculty to define their needs in terms of new services they would like to see as picks from the SWE menus. As a consequence, the focus of all of the ATS work groups is increasingly being driven by extensions to and enhancements of SWE. "... [T]he real power of technology is not that it can make the old processes work better, but that it enables organizations to break old rules and create new ways of working..."[7] It is believed that the SWE is creating new ways of working for researchers, educators, and students at CSLA. Although quite promising, it is too soon to declare a breakthrough; however, the hope is that this technological enabler will soon contribute to far more efficient and effective outcomes for the community of scholars who are utilizing it. 1 Robert C. Shirley, "Strategic Planning: An Overview," Successful Strategic Planning: Case Studies, New Directions for Higher Education, No. 64 (San Francisco: Jossey-Bass, 1988), pp. 11-12. 2 James Penrod and Thomas W. West, "Strategic Planning for Computing and Communications," Organizing and Managing Information Resources on Campus. (McKinney, TX: Academic Computing Publications, Inc., 1989) pp. 117-137. 3 Strategic Plan for Information Resources Management, California State University, Los Angeles, July 1986, p. 29. 4 Donald Carder, "Faculty Access Requirements," Strategic Plan for Information Resources Management, California State University, Los Angeles, CA, January 1988, pp. 38-39. 5 Donald Carder, "Design Strategy," Strategic Plan for Information Resources Management, California State University, Los Angeles, CA, July 1991, pp. 25-26. 6 Frederick P. Brooks, Jr., The Mythical Man-Month (Reading, MA: Addison-Wesley, 1975) p. 45. 7 Michael Hammer and James Champy, Reengineering the Corporation (New York: Harper Business, 1993) p.90.