ASURITE: How to Avoid Creating a Distributed Computing "Tower of Babel"! Copyright CAUSE 1994. This paper was presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10, 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 technology 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; 303449-4430; e-mail info@cause.colorado.edu ASURITE How to Avoid Creating a Distributed Computing "Tower of Babel"! Neil Armann, L. Dean Conrad, Darrel Huish Information Technology Arizona State University Tempe, AZ 85287-0101 ABSTRACT The entire computer industry is racing at breakneck speed to implement client/server applications and begin reaping the benefits of the new distributed computing paradigm. However, there are many ways to implement a client/server environment and institutions must plan their implementations to avoid technological anarchy and keep from creating a "Tower of Babel" in which the pieces do not communicate or cooperate. This paper discusses the distributed computing architecture Arizona State University has established to ensure all the new distributed pieces will actually work together. This architectural approach is called ASURITE, ASU Rational Information Technology Environment. We describe ASURITE and the impact this architecture will have on the academic and administrative computing communities. I. INTRODUCTION The Problem Computers are getting continually more powerful and consistently less expensive. This has encouraged the pervasive use of information technology throughout the University. Despite our historical reliance on mainframe computing, the majority of ASU's investment in technology now sits on the desktop. When viewed at the department level, this evolution toward distributed computing is a good thing. It allows the department to improve their operation without long delays waiting for external expertise. However, when technology is implemented in piecemeal fashion, units can find themselves unable to accomplish work that crosses organizational boundaries. This is usually because the various departments' computing environments have not been designed to work together. Computer people call this situation "Islands of Technology." For example, a faculty member may have a useful computing "island" for tracking records and grades of his students, yet find it impossible to send final grades to the University's student information system. When faced with the obstacles presented by these isolated islands of technology, many organizations attempt to centrally control or coordinate technology implementation. Some organizations try to settle on a single vendor to insure that all pieces of technology will operate together. This approach is not practical for ASU because we have a high degree of autonomy within our various units; we have already made a large investment in a de facto heterogeneous computing environment; and even if we could all agree on a homogeneous set of technical products, we lack the massive budget required to replace significant portions of our technology. So, we need a better strategy to address this problem. Departments need to answer three basic questions: If I'm buying technology and want to maximize my ability to work cooperatively with others, what should I buy? If I have limited budget but want to improve my technological situation incrementally, how can I evolve in the same direction as everyone else? If some functions are going to be handled centrally for efficiency's sake, what tasks will be done for me and what tasks should I prepare to do for myself? Approach In a simplistic sense, the way to guarantee that we can cooperatively share technology is to identify standards. This approach has worked well in the area of audio music. We can all buy cassettes and expect them to work on any cassette player made by any manufacturer. The same is true for compact disks. One can plug a Sony amplifier into a Technics receiver with Bose speakers and easily construct a viable audio system. This is because the manufacturers adhere to standards. Unfortunately, we don't yet have widely accepted standards for most aspects of computer technology. There are emerging standards that hold promise for improving our situation, but today there is no "plug and play" ability among all vendors. A significant obstacle to the ultimate success of any standard is the rapid pace of change among computer technologies. ASU's Rational Information Technology Environment (ASURITE) is an information technology architecture that positions the university to take advantage of emerging standards. It also recognizes the need to accommodate budget constraints, moderate the pace of change and preserve the autonomy of the individual departments. ASURITE describes a distributed style of computing that is constructed of modules. Each module performs a specific function and can be thought of as analogous to an audio component. The components are frequently called "servers." So, the computing environment at ASU will have several data servers which store and retrieve data. Several print servers will produce output at various locations. Mail servers will store and forward mail throughout the university, etc. Some modules lend themselves to being implemented and supported centrally. For example, security can be best maintained by allowing a single method to gain access to computing resources. Customers would typically identify themselves during their first interaction with any computing resource and then be granted authority to all valid and appropriate services. One server can be maintained centrally rather than have multiple security checks with multiple procedures and passwords. Departmental implementation and support is more appropriate for other modules, such as a database used only by a single department. But that departmental database may need to obtain some of its data from a central database, so the ability to interact with central services must be maintained. ASURITE is an architectural framework which describes how all supported components will interact within such an environment. The architecture encompasses various styles of computing including client/server, distributed computing, cooperative processing and object orientation. It is intended to help ASU achieve flexibility, adaptability and efficiency in information technology, by putting processes on the right platforms, in the right location, and in a consistent manner. ASURITE treats the individual as the focal point of a series of software "services" supporting the individual's dual role as both data producer and information consumer. In general, services can exist on any combination of hardware and physical locations deployed in an "intelligent" network. It is primarily the desktop which invokes the services where and when needed to satisfy an individual's need. The desktop will become the focal point of the individual's interaction with enterprise systems and data, as well as with collaborative groups, research data bases, etc. Data, voice/sound, graphics/images, and live video will converge on the desktop as the common denominator for synthesizing information from data. All applications will reside in a robust, intelligent network which presents the information consumer with a single system image. ASU systems and links to the external world will appear to be a single network composed of services and data, invoked by name regardless of the physical locations and technol ogy used to provide those services and data. The diagram in Appendix A provides an overview of the ASURITE as it will be implemented over time. II. GENERAL CHARACTERISTICS In order to achieve the overall ASURITE architectural objectives, the following qualitative characteristics are established: Adaptability - change as national & industry standards evolve, so we can enhance and incorporate new ways of doing essentially the same business function without major developmental impact. Manageability - centrally manage or coordinate and monitor, including the orderly planning for capacity changes of various essential services. Reliability - remain in continuous operation even if part of the system suffers failure, needs maintenance or upgrading, or is destroyed or damaged by a disaster. Securability - provide different access to individuals based on the classification of data and the user's business function. This will require that all basic ASURITE services use standard (ASURITE) authentication and authorization services. Extensibility - easily add new kinds of functionality to existing processes without major impact. Scalability - increase or decrease size or capability in cost- effective increments without software impact or "spikes" in the unit cost of operations due to step functions in procuring additional resources. Performance - fast response and high throughput. Connectability - communications access to a variety of area, national, and international networks. Consistency - relative stability of the person/machine interface over time. Accessibility - university community members should be able to access and use ASURITE services wherever they are, provided that they have a properly configured "client" workstation. III. CHARACTERISTICS OF INDIVIDUAL SERVICES The following qualitative objectives are established for each individual service offered within ASURITE: Like an extension to the desktop - how information is presented to, manipulated by, or provided by the user needs to be consistent across all applications no matter where the application is actually running -- on the desktop or on a network server. The user interface can be made more consistent by making it appear as if the information is completely under the control of the workstation software with which the individual user is already familiar. Just as the user can tailor the workstation software to satisfy her needs, so should she be able to tailor the interface for information from and to external systems. Interoperable - (1) any supported service is available to any supported client no matter the particular brand of server or client hardware and software and (2) the interaction between clients and servers is transparent to the client, e.g., the client does not need to know where the service is coming from. Incorruptible (virus-free) and as secure as practical - computer viruses are detected and prevented from spreading to servers and clients, and data and computer systems are protected from unauthorized use and tampering. Absolute guarantees, however, of virus prevention and security are not feasible. Fault-tolerant - reduce the impact of hardware and software failures. Highly critical servers might have redundant processors and databases so recovery from a failure would be immediate and transparent to the user; other, less critical servers could have backup servers that could be put into opera tion within a few hours. Disaster-tolerant - restore services in a timely manner when a disaster, such as a fire, destroys equipment. Expandable - additional capacity can be added to meet the demands of more users or increased functionality without modification to user procedures. Peer to the client - no master/slave relationship should exist between client and any server - the client is not controlled by the server. A client makes a request of a server and is prepared to receive a response (or a request to supply more data to the server) but is free to do other processes in the meantime. Restricted in access as needed - since all services are technically accessible to any user on the network, individual service providers may limit access to their services if necessary; e.g., a departmental printer may be restricted to use by members of the department. Non-interfering and non-conflicting with other services - any user can use any service or combination of services concurrently. Appropriately interactive with the client - the client can monitor and alter its requests for services. The server should make the status of a request for service available to the client so the client/user can cancel or modify the request if needed; e.g., it should be possible to determine that a data base query is retrieving much more data than anticipated and to cancel that query if desired. Optional - local (to the client) services are allowed; e.g. a local printer may be completely under the control of the local client. IV. SPECIFIC SERVICES THAT WILL BE PART OF ASURITE A.The following services are considered basic to ASURITE, and must be in place before other services can be added: Authentication and authorization - authentication is the verification process that confirms the identity of a person requesting service; this process must be done in a secure manner to prevent others from determining the method of verification. Authorization is the process that permits only those who have been granted permission to use a particular service to actually use that service. Finder/navigator - permits users, clients, and servers to reference services, devices, and people by name rather than by physical location or network address. These services also permit transparent relocation of devices, servers, etc. Time - synchronize date and time of day on all the servers and clients so that time-dependent processes are coordinated. File management - provides for the storage, access, and security of data (e.g., text, images, and voice) particularly to facilitate the sharing, interchange and security of data. File management services include backup and recovery services make duplicate copies of data in case the working copies are damaged and provide procedures to restore lost data from the backup copies, and archiving services provide facilities to store and retrieve seldom used data on low-cost media, such as tape. Print - provides for the transmission, temporary storage, and production of paper output of data (including text, plots, and images) from clients and other servers. Configuration management - set of services to coordinate the software and hardware on the servers and clients and includes notification of changes, update by subscription, coordination of non-optional upgrade of software, and verification of hardware compatibility. Network management data base and status - maintains data concerning the network configuration and operations. B.The following are examples of services or classes of services that will be added to the basic ASURITE services over time: Collaboration support is a set of services that facilitate human communication between individuals, within a group working on a common effort, or among groups interested in a particular topic. These services include messaging, computer-facilitated conferencing, electronic mail, voice mail, calendaring, and groupware. Enterprise applications are those computer applications that support the major administrative functions of the university. Object catalog contains data about enterprise data (e.g., names, descriptions, and usage rules) and common processes using enterprise data (e.g., a complex query that extracts data from several data bases and puts them in a spreadsheet). An object catalog is an extension of the data dictionary concept. On-line consulting is a repository of information and previously asked questions and answers to help users and support personnel solve hardware and software problems. Computation servers handle resource-intensive calculations that are inappropriate for running on a local workstation. Software library services provide for the distribution of shareware or site-licensed software and the lending of software for trial use. Databases services make information available to any client and are provided by commercial, research, administrative, and other sources (e.g., the administrative data warehouse). Scheduling of tasks services control processes that do not need to be run immediately, e.g. long reports or database backups. External access services permit use of the servers from locations outside of the university-operated network, e.g. from Internet sites or via dial-in from home. Problem reporting and tracking services receive and facilitate the resolution of system problems. Approval and signature services permit the electronic (i.e., sans hardcopy) authorization of official documents, e.g., purchase requisitions, grades, and payroll. V. PRODUCT ARCHITECTURE The intent of this section is to list some specific products and standards that currently appear to comply with the general characteristics and services that form the core of ASURITE. The list of products and standards is incomplete because in some cases no product or standard exists that conforms to the ASURITE architecture. However, current products and standards will evolve and new ones will emerge to fill in the gaps. An example of emerging distributed computing standards are the Distributed Computing Environment (DCE) and Distributed Management Environment (DME) standards provided by the Open Software Foundation (OSF). OSF is an independent company formed by a coalition of computer and network product suppliers. Its goal is to provide a set of open industry standards for distributed computing. Manufacturers that conform to these standards are assured of interoperable products. Because DCE and DME also provide extensive coverage of the services listed earlier, ASURITE will be relying heavily on products that use them. Users view ASURITE from their desktop workstations, each with the individual's own preferred method of interaction. In acknowledgment of this, ASURITE will provide support to the general community for desktop Operating System-Graphical User Interface (OS-GUI) combinations that will interact with appro priate servers. The initial set will be: DOS 5 - Windows 3.1 Mac System 7.1 UNIX-Motif. These OS-GUI are expected to evolve or be replaced over time. Possible successors include Windows NT and Windows for Workgroups for DOS/Windows and AOCP for the Macintosh. The primary network communications protocol set required to obtain ASURITE services will be Ethernet and TCP/IP. However, protocols in addition to TCP/IP, e.g., Appletalk, IPX, and DECNET, will also be supported on the university backbone for use by individual work clusters and departmental local area networks for the near term. It is expected that additional network capacity will be needed at ASU, particularly on the University Backbone, to support all of the new services, so ASURITE will be evolving to new, higher speed protocols as needed and funds allow. Examples of new network standards being considered are FDDI and ATM. In the near future higher speed protocols will be used primarily on the backbone and to connect high volume servers and workstations, but the vast majority of workstations will be connected via Ethernet. With the large number of LAN's at ASU, it will be important that ASURITE coexist with the LAN's and interoperate with LAN services such as file sharing, local mail, and print services. Client workstation connectivity via Ethernet provides access to both LAN services and ASURITE services even though the LAN might be using a non-TCP/IP protocol. The ASURITE file service, initially, will use the Andrew File System (AFS) which at present can only be directly used by UNIX clients. However, Network File System (NFS) software can be installed on Mac and DOS/Windows workstations and access AFS files via a NFS/AFS translator provided as part of the ASURITE file service. To the user the AFS files appear in the directory as if they resided on the workstation and can be moved to a LAN server or the workstation by simple drag and drop of the file icons. LAN vendors are expected to incorporate interoperability functions in the future so intermediary services, such as the NFS/AFS translator, are not required. The following tables summarize the ASURITE standards and related products for basic services, client workstations, and communications. These form the components of ASURITE, but, of course, must interact with each other to form a cohesive architecture. Table 1: Basic Services Product Architecture Service Future Initial Future Standard Product Product Authentication OSF/DCE Kerberos v. 4 Kerberos v. 5 Authorization OSF/DCE native OS DCE Access access control Control List File OSF/DCE Andrew File DCE System Distributed (Transarc) File System Time OSF/DCE Internet, DCE Network Time Distributed Protocol Time Service Finder/Navigat OSF/DCE X.500 X.500 or X.500 Internet Domain Name Service Print OSF/DME TCP/IP LPR/LPD DME Print Palladium Service Data Base SQL Access Sybase Sybase Management Group Informix Informix Oracle Oracle Data Base SQL Access Encina Transaction Group Management X/Open-XA Configuration OSF/DME Management Network OSF/DME Management Database Email X.400 SMTP/IMAP X.400 SMTP SMTP/IMAP Calendaring None yet Table 2: Client Product Architecture Function Initial Product Future Product Operating DOS 5.0/Windows 3.1, Future versions System / Mac System 7.1, compatible with Graphical User UNIX/Motif initial products Interface Data Base Sybase Open Client, SQL Access Group Access Microsoft ODBC, standard Borland IDAPI Communications Ethernet Ethernet; card FDDI on high volume workstations Communications TCP/IP TCP/IP software Table 3: Network Architecture Function Initial Product Future Product Wiring Broadband coax with Fiber optic backbone some fiber optic and to high volume campus backbone to workstations, building router, Twisted pair to most Broadband coax to workstations floor closet, Twisted pair to workstation Low-level Ethernet with FDDI backbone and to communication limited FDDI on high volume protocol backbone workstations in short term, ATM or other long term; Ethernet to most workstations, Transmission TCP/IP (see Note) TCP/IP protocol Note: The backbone network also supports DECNET, IPX, and Appletalk for use by departmental LAN's, but access to the ASURITE services requires TCP/IP. VI. Impact on Academic Computing While ASU struggles with the challenge of implementing distributed computing for our administrative systems, much of academic computing is already distributed. Starting in the mid- 1980's, the administration began a series of "faculty computer infusion" programs where the goal was to place a computer on the desktop of every faculty member that desired one. Most of these were PC and Mac systems. This was followed a couple years ago with a "networking infusion" program where the goal was to get the faculty connected. The faculty infusion programs were very successful. However, as we began to look at implementing the ASURITE architecture, we realized we would have to do something about all the older, obsolete technology that is the legacy from the earlier programs. The architecture provides the promise of much additional function and flexibility, but it depends on a minimum configuration that will run Windows 3.1 or Mac System 7. Meanwhile, we had literally hundreds of faculty members with PC-XT's, early Macs, or worse on their desktops. Furthermore, we had many old, obsolete systems in our student computing sites. It would require a mainframe-level expenditure to resolve this problem. Fortunately, we were able to enlist the support of our Provost and Senior Vice President. At the end of FY93, the Provost funded a new infusion program that allowed ~700 faculty to upgrade their systems, which addresses roughly half of the obsolete systems. A similar infusion program is anticipated for FY94 to address the remaining half. In addition, Information Technology (IT) also received funding that allowed us to install ~350 new systems in the student sites. The base systems purchased were 486 and Centris 610 configurations. These upgrades will allow virtually every faculty member and many students to participate in the ASURITE environment. Over this next year, IT will be focusing on deploying the ASURITE basic services. At the same time, several projects are being initiated or extended -- by IT as well as other units on campus - - that will utilize and build upon these basic services. These include: o a distributed client/server e-mail system (including forms routing and calendaring) to replace the present mainframe- based environment -- this will be extended to all faculty, staff, and students as opposed to the present limited availability; o a "self-subscription" service for e-mail and other popular services that will allow us to automate the accounts process for the massive number of accounts that will need to be created; o transitioning customers off the academic mainframes by deploying adequate statistical, compute, and file servers as well as migrating many faculty primarily to their desktops; o a dial-in Ethernet service for access to all ASURITE- compliant services from virtually anywhere; o a server for downloading software products including the clients that will be needed to access the many servers that are being deployed, e.g., e-mail, Library CD-ROM, and GOPHER clients; o a Netnews/Usenet server; o docking stations in the student computing sites to allow students to bring in their own laptops and plug into the network; o an on-line CD-ROM data base server in the Library; o a high quality color print/copy server; and o a slide maker server for presentation (deferred to FY95). A robust distributed academic computing environment promises to provide powerful new tools and capabilities to the faculty. However, careful planning will be needed to deliver on this promise. We have initiated a joint planning effort between IT and the colleges to help ensure we fully understand the needs of each college and that faculty and students experience the minimum amount of discomfort as we begin the evolution to this new environment. VII. Impact on Administrative Computing ASURITE has had a significant impact on ASU's administrative computing. The technical architecture is now widely accepted as an important part of any decision making about technical projects. There are at least three reasons for this. First is because ASURITE offers guidelines not mandates. In a political environment where autonomy is highly valued, people respond better to a suggestion than a requirement. Second, departments are going to spend funds on some form of technology anyway so they appreciate published information about how to make things work together. This is related to the third reason which is that ASURITE provides some insulation from blame. We have had administrative units call us and ask how they could get their project "certified" as ASURITE compliant. We have resisted the idea of a certification process as too bureaucratic but some customers have been persistent. We have done some informal consulting and recommending about purchases, but don't yet certify projects as architecturally sound. So, what's really happening? It isn't enough to have an architecture. We must also build applications that will demonstrate the value of distributed computing. To that end, ASU has acquired an application development environment that will build client/server applications from an enterprise model. We will be using the IEF from Texas Instruments as the basis for automating new student information processes. ASU is also implementing a server-based data warehouse. Initially populated with student data, we expect to follow soon with financial and human resource data. Customers will form queries and manipulate the results from their workstations. We are also seeing a strong growth in gopher style services. One project may make admissions information available to high schools while another is as simple as electronically publishing the minutes of the advisory committee meetings. There is also an emerging need to interoperate between new distributed style applications and legacy IDMS applications. We have a financial aid downsizing project underway that will have data residing on a server as well as using data on our old IDMS database. Challenges There are, of course, challenges. One is a feeling of false security that can come with being aligned with the technical architecture. Some departments may ignore other important issues in distributed computing. For example, the need for departmental disaster recovery planning is still very real. In addition, we need to have applications that are not only technically compliant but also consistent with the university's business model and production standards. Another issue is funding. Who pays for the new costs associated with this style of computing? ASU has managed to provide additional funding to place more workstations on faculty desks, but we haven't yet been able to do the same for administrative staff. Another more concrete example is that we've had customers resist using data access servers to print their own mailing labels because they would then need to buy labels. Under our centralized model, the labels had been provided for "free." From the institutional perspective this should be a non-issue, but for a struggling department all expenditures are significant. VII. Summary We face many critical issues as we deploy ASURITE-compliant services. The following are the most immediate; resolution of these will be crucial to achieving our vision of a distributed computing future: o funding for servers: after the past three years of budget cuts, IT no longer has the funds to provide all campus-wide computing services; o funding for maintenance: for the environment to work smoothly and be reliable, we will need to carefully coordinate release levels for critical software components on clients and servers alike -- however, it's very difficult to dictate how other units spend their budget dollars; o network management: problem and change coordination for critical components of the network is already a problem on our campus and the situation will only get worse; and o systems management: the faculty do not have time to become systems managers, yet software will need to be upgraded, system backups taken, and files archived/restored -- we are actively pursuing solutions with various vendors, but not all of the necessary pieces appear to be available as yet. Establishment of an architecture will make addressing these challenges possible and will ensure the resulting systems environment will deliver on the functions and flexibility that a distributed computing paradigm promises. Perhaps the fundamental issue is the client/server paradigm itself. Can all this stuff work? We hold frequent meetings under the heading of "Client/Server Reality Check." We focus on what products and services will be needed as compared to actual product availability. The frequent conclusion to these reality checks is "yes, we'll get there--but it won't be easy and it won't be soon." The key to ASURITE is keeping in mind that it will evolve and will never be "completed." It is a journey, but not a destination. Without an architectural framework we risk computing anarchy and creation of a distributed computing "Tower of Babel!" REFERENCES Apple Computer, Inc. VITAL Fundamentals. Apple Computer, 1993. Berson, Alex. Client/Server Architecture. McGraw-Hill, 1992 Digital Equipment Corporation, ed. Project Athena: The First Five Years. Digital Equipment Corporation, 1988 Open Software Foundation. Distributed Computing Environment Rational. Open Software Foundation, May 1990. Rosenberry, Ward, David Kenney, and Gerry Fisher. Understanding DCE. Sebastopol, CA: O'Reilly & Associates, 1993. Tapscott, Don, and Art Caston. Pardigm Shift: The New Promise of Information Technology. New York: McGraw-Hill, 1993 ABOUT THE AUTHORS Mr. Armann is Director of the Computer Center at Arizona State University (ASU) and can be contacted at (602)965-5263 or via e- mail at narmann@asu.edu. Mr. Conrad is Director of Computing and Network Consulting Services (Academic Computing) at ASU and can be contacted at (602)965-5620 or via e-mail at larry.conrad@asu.edu. Mr. Huish is Director of Administrative Information Technology (Admin-istrative Computing) at ASU and can be contacted at (602)965-5674 or via e-mail at darrel.huish@asu.edu. ACKNOWLEDGEMENT The development of ASURITE was a team effort involving many people at ASU besides the authors of this presentation. In particular, Connie McNeill, Dr. William Lewis, Dr. Bruce Millard, Gerry Samchuck, and Jack Hsu provided the leadership and made significant contributions. APPENDIX A ASURITE Overview