Developing a Distributed Computing Architecture at Arizona State University Copyright 1994 CAUSE. From _CAUSE/EFFECT_ Volume 17, Number 2, Summer 1994. 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, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: jrudy@CAUSE.colorado.edu DEVELOPING A DISTRIBUTED COMPUTING ARCHITECTURE AT ARIZONA STATE UNIVERSITY by Neil Armann, L. Dean Conrad, Darrel Huish, and Bruce Millard ABSTRACT: Colleges and universities, along with many other organizations and the computer industry, are rushing to reap the benefits of the new distributed computing paradigm by implementing client/server applications. But there are many ways to move to a client/server environment, and institutions must plan their implementations to avoid technological anarchy--a "Tower of Babel" in which the pieces do not communicate or cooperate. Arizona State University (ASU) has established a computing architecture to ensure that all new distributed computing pieces will actually work together. This architectural approach is called ASURITE, ASU's Rational Information Technology Environment. This article describes ASURITE, beginning with a discussion of the rationale, or business case, for undertaking the development of a distributed computing architecture, followed by a description of the general architectural approach. General qualitative characteristics of the architecture and objectives of the ASURITE services are then described, followed by a discussion of the specific ASURITE services, the product architecture that will be used for those services, and the impact of the architecture on the University community. The development of ASURITE is a very collaborative endeavor that goes far beyond the authors of this article.[1] A small group from Information Technology and the College of Engineering formulated the initial ideas for ASURITE; participation then expanded to include staff and faculty from other University units to develop the initial draft document. Members of the team made presentations to various committees at all levels of the University to gain acceptance of ASURITE. The document continues to evolve, as more specific requirements are developed and products are selected. Business need 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 its operation without long delays while waiting for external expertise. However, when departments implement technology in a piecemeal fashion, they 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 ensure that all pieces of technology will operate together. This approach is not practical for ASU, because there is a high degree of departmental autonomy; the University has already made a large investment in a de facto heterogeneous computing environment, and even if everyone agreed on a homogeneous set of technical products, it could not afford to replace significant portions of its technology. The University needs 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 a 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 myself? Standards 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[2] 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. 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, analogous to an audio component. The components are frequently called "servers." The computing environment at ASU will have several data servers that store and retrieve data. Several print servers will produce output at various locations. Mail servers will store and forward mail throughout the University, and so forth. 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 security service can be maintained centrally, rather than having multiple security checks with multiple procedures and passwords. For other modules, such as a database used by only one department, departmental implementation and support is more appropriate. However, 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 that invokes the services where and when needed to satisfy an individual's need. The desktop computing and communications resource will become the focal point of the individual's interaction with enterprise systems and data, with collaborative groups, with research databases, and other resources. Data in various forms (ASCII text and numbers, sound, images, and video) will converge at the desktop, which becomes 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 technology used to provide those services and data. The diagram in Figure 1 provides an overview of the ASURITE as it will be implemented over time. Figure 1: ASURITE overview [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] General characteristics of ASURITE In the mainframe world, we now take for granted many characteristics that have evolved over the years to provide highly reliable, manageable, and secure information systems. Those characteristics must be retained in the distributed computing environment as well, and new objectives unique to the distributed environment are needed to achieve its promise. We have defined a set of general qualitative characteristics for the ASURITE architecture. ************************************************************************ ASURITE Architecture Characteristics * Adaptability * Manageability * Reliability * Security * Performance * Extensibility * Scalability * Consistency * Connectability * Accessibility ************************************************************************ As national and industry standards evolve, and as the University's needs change, the architecture must be adaptable, so we can enhance and incorporate new ways of doing essentially the same business functions without major developmental impact. The flexibility of distributed computing to meet changing needs brings with it a very complex environment, so adaptability needs to be balanced with _manageability_. The myriad components must be centrally controlled or coordinated and monitored, including planning capacity changes to various essential services. As applications are transferred to the client/server environment, University operations will be critically dependent on the _reliability_ of the infrastructure. Critical computing resources, as well as the communications network, must remain in continuous operation, even if components suffer failure, need maintenance or upgrading, or are destroyed or damaged by a disaster. While the openness of modern communications networks provides great benefits in flexibility and connectivity, it also requires very effective _security_ of resources on the network. Service requesters, both people and other services, must be identified with a high degree of reliability, and granted access to resources based on the classification of data and the requester's business function. Excellent _performance_ with fast response and high throughput is an obvious objective, but in order to maintain performance, the architecture must have _extensibility_ and _scalability_. The first is being able to add new kinds of functionality to existing processes without major impact, while the second calls for the increase or decrease in processing capacity without major revisions to the underlying infrastructure. Scalability also means the ability to add capacity in cost-effective increments. The interfaces between the services and the people using the services via the client workstation need to have _consistency_, so they are at least relatively stable over time and decrease impacts of service changes. The communications infrastructure provides _connectability_, such that all users have communications access to a variety of area, national, and international networks. There must also be accessibility that provides University community members the ability to use ASURITE services wherever they are, provided they have a properly configured client workstation. Characteristics of individual services While the above objectives apply to the overall distributed computing architecture, the following qualitative characteristics apply to the individual services offered within ASURITE. The design and implementation of each service must incorporate these characteristics. A fundamental objective is to make each service appear to be _an extension of 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. All services should be _interoperable_; that is, (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, i.e., the client does not need to know where the service is coming from. Services need to be as _incorruptible (virus-free) and as secure as practical_, so that computer viruses are detected and prevented from spreading to servers and clients and that data and computer systems are protected from unauthorized use and tampering; however, absolute guarantees of virus prevention and security are not feasible. The impact of hardware and software failures should be reduced or made _fault-tolerant_. 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 operation within a few hours. Services must also be _disaster-tolerant_, so the services can be restored in a timely manner when a disaster, such as a fire, destroys equipment or data. Each service needs to be _expandable_, so that service capacity can be increased to meet the demands of more users or more complex functionality without modifying user procedures. Servers are to be treated as _peer to the client_; that is, no master/slave relationship should exist between client and any server. Clients are not controlled by servers. 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. Since all services are technically accessible to any user on the network, individual service providers may opt for _restricted access_ if necessary. For example, usage of a departmental printer may be restricted to members of the department. Services must be _non-interfering and non-conflicting_ with other services, so any user can use any service or combination of services concurrently. Clients should be able to monitor and alter their requests for services, because the services are _appropriately interactive with the client_. 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. For example, it should be possible to determine that a database query is retrieving much more data than anticipated, and to cancel that query if desired. ************************************************************************ Individual Services Characteristics * Extension of desktop * Interoperable * Incorruptible and secure * Fault-tolerant * Disaster-tolerant * Expandable * Peer to the client * Restricted access possible * Non-interfering, non-conflicting * Appropriately interactive with the client * Optional to the client ************************************************************************ Services are _optional_, which permits local (to the client) services. For example, a local printer may be completely under the control of the local client and not accessible through the network to any other client or server. Specific services that will be part of ASURITE The services that ASURITE will be providing to the University community will, by their very nature, vary over time. Our intent is that the services evolve into a more complex and comprehensive set, rather than seeing them as a static, never changing environment. We have determined a core set of "infrastructure" services that need to be in place (basic services) before we can provide the second-level services (application services) that will make this architecture so beneficial to the University community. Basic services In a distributed computing environment, one of the greatest concerns must be security of data. The ASURITE _authentication and authorization_ services provide the basic security mechanisms. 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. Usually "unseen," the _time_ service is necessary to synchronize date and time of day on all the servers and clients, so that time-dependent processes are coordinated. The time synchronization is also necessary to properly provide the authentication service. The _finder/navigator_ services are intended to be used at a low level by software, but also by customers directly. They permit 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. _File management_ is an extremely important function to both customers and the administrative computing arm of the University. The file management service provides for the storage, access, and security of data (e.g., text, images, and voice) particularly to facilitate data sharing and interchange. File management services include _backup and recovery_ services that 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 that provide facilities to store and retrieve seldom used data on low-cost media, such as tape. All ASURITE customers--for example, students, faculty, and administrators--need to see the results of computations. The _print_ service provides for the transmission, temporary storage, and production of paper output of data (including text, plots, and images) from clients and other servers. As an adjunct service of the print service we will likely add other output services, e.g., microfiche and optical disk. In the current computing environment, software changes (new versions and better packages) occur almost daily. In addition, the hardware on which the software runs (either on the desktop or the servers) is changed frequently. This leads to a situation in which the customer doesn't know which version to use. The solution lies in the _configuration management_ service, which is a set of services to coordinate the software and hardware on the servers and clients. It includes notification of changes, update by subscription, coordination of non- optional upgrade of software, and verification of hardware compatibility. The _network management database and status service_ maintains data concerning the network configuration and operations. It contains information about current configurations, so that problems can be resolved quickly. In addition, it contains information about planned down-times, acceptable network software packages and configurations for workstations, and a history of problems that have occurred, to help customers identify why unexpected events are happening to them. Application services The following are examples of services or classes of services that will be added to the basic ASURITE services over time. These examples are an initial set that University customers and IT representatives have identified. We expect these to grow dramatically, as the basic services are put in place and these application services become widely used. _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 other groupware. _Enterprise applications_ are those computer applications that support the major administrative functions of the University. While a significant portion of these services is database oriented, other enterprise applications are needed. They include human resources, purchasing, class scheduling, parking, institutional modeling, planning, and many others. Most of these services will be implemented in the client/server model and, hence, will rely heavily on the security services and the desktop for both presentation and computation. An _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 databases and puts them in a spreadsheet). An object catalog is an extension of the data dictionary concept that we feel is essential for administrative computing. _Online consulting_ is a repository of information and previously asked questions and answers to help users and support personnel solve hardware and software problems. This service will be an extension of a service already being used at ASU.[3] We expect to broaden its scope, as well as integrate it with the ASURITE basic services. Computing has become an integral part of almost all aspects of University life, from the sciences to social services and beyond. As part of IT's role, it is necessary to provide computing capacity beyond what our customers get from their desktops. Thus, IT is providing _computation servers_ that handle resource-intensive calculations that are inappropriate for running on a local workstation. The _software library_ services provide for the local storage of shareware or site-licensed software and the lending of software for trial use. An additional use of this service could be the storage of locally produced ASURITE-compliant software modules and packages that would allow for simple, easy integration into the network. _Database_ services make information available to any client and are provided by commercial, research, administrative, and other sources (e.g., the administrative data warehouse). While we try to provide an open access environment for information, we are also required to keep some things private. Our database services will make extensive use of the security services. Some processes, which support the University community, do not need to be run immediately, e.g., long reports or database backups. The _task scheduling_ services are used to control these processes. We live in an environmentally aware and highly mobile culture. Thus, we need _external access_ services to permit use of the other services from locations outside the University-operated network, e.g., from Internet sites or via dial-in from home. The external access services allow students, faculty, and staff to work from home and travel to other locations around the country (and, eventually, the world) and still have access to their customary applications. The _problem reporting and tracking services_ receive and facilitate the resolution of system problems. These services are similar to but more encompassing than the network management basic service described above in that they are active services rather than passive databases, and include resolving problems related to computers, printers, building operations, and other services. _Approval and signature_ services permit the electronic (i.e., sans hard copy) authorization of official documents, e.g., purchase requisitions, grades, and payroll. These services include digital signatures, work- flow messages, and images of scanned documents where necessary. Product architecture A number of specific products and standards currently appear to comply with the general characteristics and services that form the core of ASURITE. Tables 1, 2, and 3 summarize ASURITE standards and related products for basic services, client workstations, and communications. While these form the components of ASURITE, they of course must interact with each other to form a cohesive architecture. The lists are 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. Table 1: Basic services product architecture Table 2: Client product architecture Table 3: Network architecture [TABLES NOT AVAILABLE IN ASCII TEXT VERSION] Note: The backbone network also supports DECNET, IPX, and Appletalk for use by departmental LANs, but access to the ASURITE services requires TCP/IP. Examples 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 combinations that will interact with appropriate servers. The initial set will be: DOS 5.0/Windows 3.1; Mac/System 7.1; and UNIX/Motif. These interfaces 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/PowerPC line. The primary network communications protocol set, required to obtain ASURITE services, will be Ethernet and TCP/IP. However, protocols in addition to TCP/IP--for example, Appletalk, IPX, and DECNET--will also be supported on the University backbone network for use by individual work clusters and departmental local area networks (LANs) for the near term. It is expected that additional network capacity will be needed at ASU, particularly on the backbone, to support all of the new services, so ASURITE will be evolving to new, higher-speed protocols as needed and as funds allow. Examples of new network standards being considered are asynchronous transfer mode (ATM) and 100 Mbps Ethernet. 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 through standard 10 Mbps Ethernet. With the large number of LANs at ASU, it will be important that ASURITE coexist with the LANs 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 protocol other than TCP/IP. The ASURITE file service, initially, will use the Andrew File System (AFS). Network File System (NFS) software will be installed on some Mac and DOS/Windows workstations to provide access to AFS files via an NFS/AFS translator that will be provided as part of the ASURITE file service. To the user, the AFS files appear in the directory as if they reside on the workstation, and they can be moved to a LAN server or the workstation by simple drag and drop of file icons. LAN vendors are expected to incorporate interoperability functions in the future, so the need for intermediary services, such as the NFS/AFS translator, will decrease. Impact on academic computing Much of academic computing is already distributed at ASU. Starting in the mid-1980s, 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 who desired one. Most of these were PC and Macintosh systems. This was followed a couple of years ago with a "networking infusion" program, where the goal was to get a significant portion of the faculty connected to the network. Those early 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 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-XTs, 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 roughly 700 faculty to upgrade their systems, which addressed roughly half of the obsolete systems. A similar infusion program is planned for FY94. In addition, the Information Technology (IT) division also received funding last year that allowed us to install about 350 new systems in the student sites. The base systems purchased were 486 and Centris 610 configurations. We have asked for a follow-up program for the sites this year as well. These upgrades will allow virtually every faculty member and many students to participate in the ASURITE environment. Over the past year, IT has been focusing on deploying the ASURITE basic services. At the same time, several projects of interest to the faculty have been initiated--by IT as well as other units on campus--that will utilize and build upon those basic services. These include: * 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; * 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; * transitioning of customers off the academic mainframes by deploying adequate statistical, compute, and file servers, as well as migrating many faculty primarily to their desktops; * a dial-in Ethernet service for access to all ASURITE-compliant services from virtually anywhere--using the PPP protocol; * 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;[4] * a Netnews/Usenet server; * installation of docking stations in the student computing sites, to allow students to bring in their own laptops and plug into the network; * an online CD-ROM database server in the library; * a high-quality color print/copy server; and * 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 that 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. 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. This has taken place almost effortlessly--with nothing more complicated than publishing the details in the departmental newsletter and hosting a few presentations. In slightly more than a year's time, ASURITE has become an encompassing term that communicates an array of technical requirements in just one acronym. There are at least three reasons for the easy acceptance of the concepts contained within ASURITE. First, the architecture offers guidelines, not mandates. In a political environment where autonomy is highly valued, people respond better to suggestions than requirements. Second, departments plan 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 compliant with ASURITE. We have resisted the idea of a certification process as too bureaucratic, but many customers are eager to have some outside unit participate in a difficult technology decision. The users of distributed technology have come together to elaborate on the concepts of ASURITE. Our administrative computing advisory committee recently published a white paper on the impacts of distributed computing, which seeks to be informative about the pitfalls of departments doing their own independent technical architecture. Implementation and challenges 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. Just this year we began using the Information Engineering Facility (IEF) CASE tools from Texas Instruments as the method for building ASURITE-compliant applications. We have begun two initial IEF projects. These are called "pathfinder" projects, in recognition of their trail-blazing nature. Later in 1994 we will be automating new student information processes using ASURITE as our technical guideline. ASU is also implementing a server-based data warehouse, initially populated with student data. We expect to provide financial and human resource data soon. 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 under way that will have data residing on a server as well as using data on our old IDMS database. 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 been able to do the same for administrative staff. A concrete example is that we have had customers resist using data access servers to print their own mailing labels because they would then need to buy labels from their local budgets. Under our centralized model, the labels have been provided "free." From the institutional perspective, this should be a non-issue, but for a struggling department, all expenditures are significant. Looking ahead 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: * funding for servers--after several years of budget cuts, IT no longer has the funds to provide all campus-wide computing services; * 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, but it is very difficult to dictate how other units spend their budget dollars; * 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 * 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 that 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, not a destination. ************************************************************************ For further reading: Berson, Alex. Client/Server Architecture. New York: McGraw-Hill, 1992. Distributed Computing Environment Rationale. Cambridge, Mass.: Open Software Foundation, 1990. Project Athena: The First Five Years. Maynard, Mass.: Digital Equipment Corporation, 1988. Rosenberry, Ward, David Kenney, and Gerry Fisher. Understanding DCE. Sebastopol, Calif.: O'Reilly & Associates, 1993. Tapscott, Don, and Art Caston. Paradigm Shift: The New Promise of Information Technology. New York: McGraw-Hill, 1993. VITAL Fundamentals. Cupertino, Calif.: Apple Computer, Inc., 1993. ======================================================================== Footnotes: 1 While many people at ASU were involved in the effort, the contributions of a few were particularly significant. Connie McNeill was instrumental in initiating the project and leading it through the initial stages; Dr. William Lewis has been the leading advocate among University officials; Gerry Samchuck provided significant architectural vision; and Jack Hsu contributed a continuous reality check. 2 All registered trademarks used in this article are the property of the registered owner. 3 L.D. Conrad and M.G. Royal, "On-line Consulting Services: How to Make Everyone a Computer Support Person!" Proceedings of the EDUCOM'93 Conference (New York: McGraw-Hill, 1993). 4 "The Internet Gopher client/server provides a distributed information delivery system around which a world/campus-wide information system (CWIS) can readily be constructed. While providing a delivery vehicle for local information, Gopher facilitates access to other Gopher and information servers throughout the world." [This explanation is quoted from the "Frequently Asked Questions about Gopher" file on the Gopher server at the University of Minnesota where Gopher was developed.] ======================================================================== Neil Armann is Director of the Computer Center at ASU, responsible for operations and system support for central academic and administrative systems and the development, implementation, and operation of the ASURITE basic services. L. Dean Conrad is Director of Computing and Network Consulting Services at ASU, with management experience in a variety of technical and applications support roles in both the public and private sectors. Darrel Huish is Director of Administrative Information Technology at ASU, a unit responsible for developing and enhancing applications for major administrative functions. He is also co-chair of ASU's student process reengineering project. Bruce Millard is a research scientist with ASU's Information Technology division, where he is a staff consultant for the planning, development, acquisition, and integration of new technologies into ASU's computing environment. ************************************************************************ Developing a Distributed Computing Architecture at Arizona State University