Rightsizing a Mainframe Administrative System Using Client/Server 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 RIGHTSIZING A MAINFRAME ADMINISTRATIVE SYSTEM USING CLIENT/SERVER During the last five years there have been extensive changes in the administrative computing environment at Colorado State University (CSU). Beginning with a planning process that developed an open blueprint for the future, the University has moved carefully forward towards an open, collaborative administrative environment predicated on a gradual transition to client/server systems, in house development using CASE, and broad campus involvement in the development of next generation administrative systems. THE MAINFRAME CONVERSION In 1991 CSU completed the conversion of its administrative software to IBM hardware and the CA-IDMS database. The current mainframe configuration is an IBM 3090 model 200E with 60 gigabytes of EMC DASD attached. All of the major administrative systems are purchased and, with one exception, are still on vendor maintenance. An IBM RS/6000 model 370 is also being used to support an administrative data warehouse. It is running Oracle version 6 and a migration to version 7 has begun. These systems support the University's administrative needs with good interactive response time and an adequate batch window. This phased conversion process has not been without its bad days and some trauma, but the campus is generally very pleased with the results. Without this stable environment as a starting point, the transition to the next generation of administrative computing would not be possible. THE ADMINISTRATIVE COMPUTING PLAN CSU's Office of Information Systems (IS) initiated a campus-wide administrative computing planning effort in 1990. The resulting planning document encouraged the use of partnerships for implementation and recommended special funding to support such efforts. "The Plan" was a key document for this project. It provided the high level management support for important changes in the way applications software is conceived, designed, and implemented. Its broadly based focus and extensive emphasis on the larger campus needs were catalysts for a shift in emphasis that continues to benefit the University in more ways than this project highlights. THE INFORMATION WAREHOUSE EVOLVES Significantly, the planning document was sub-titled, "Creating a Balanced Environment." It contained a clear call for better vertical balance between both mainframe and desktop platforms and central and college level applications. A key concern for the planners in preparing for this adjustment was the need to create standards for data exchange. This was particularly true given the University's heterogeneous administrative environment of DOS, Macintosh, and UNIX computers. The initial effort to standardize distributed data focused on developing mainframe data extracts for use on microcomputers. At the time, human resource system extracts were available, but their content had been defined centrally and was in need of review. No standard extracts existed for financial or student data. An open process was launched that brought central data managers and college administrators together to define the content of a complete set of data extracts. This required considerable "education" because most of the new departmental computer people were unfamiliar with the amount and complexity of the data in the mainframe systems. (The classic case of users not knowing what it is but knowing they want it.) The teams were assisted by technical people to assure that the data was suitably organized for use in a relational database. In parallel with a growing interest in access to central data, departmental microcomputer users were maturing in their use of desktop software. Spreadsheets were being replaced by full featured database products as platforms for local applications, and "software standards" began to emerge. Standards that were not centrally imposed but grew from popular support for a product throughout the campus community. For example, when a critical mass of interest developed for Paradox and Oracle, IS responded to this development by providing support and encouragement. But, this approach created problems because Information Systems did not always have appropriately trained people. Turning to the source of the interest in these products, IS begged, borrowed and sometimes shanghaied talent from the user community. Having developed complete data extracts that met the needs of college administrators, IS needed a distribution platform. The first hardware platform for the data warehouse was a 486 Banyan Vines server running Oracle. Departments accessed the data warehouse from their microcomputers using Paradox and the middle- ware products SQL*Link and SQL*Net. As usage grew, the Banyan Oracle server was ported to a more powerful and responsive UNIX minicomputer but not without some discussion of costs. A general rule for expense distribution has existed for many years that stated the departments paid for the desktop system and its connectivity while IS purchased and upgraded the central facilities as needed. In the early nineties, CSU found itself in a unique situation: a stable mainframe environment, a plan that mandated change, and the appropriate resources available to make change happen. DEVELOPING A COLLABORATIVE PARTNERSHIP Coincident with the emergence of the data warehouse, the College of Business Computer Center (CBCC) was asked to develop a management information system for the College. Specifically, the Dean wanted to have pertinent and current management information at his fingertips. Existing University reporting systems could not support this for the following reasons: Transaction processing was not timely: Most data was provided through manual processing of administrative documents. This processing involved extensive authorization loops and hand carried mail which typically delayed processing one or two weeks. Administrative units could not easily track transactions: Administrative units were removed from transaction processing resulting in a further one or two week period when the exact status of a transaction could only be determined by contacting the University's accounting personnel. The University's mainframe applications did not support easy to use query or reporting tools: Ad hoc query tools did not exist, and, even though information was accessible, the access methods were not suited to the casual user. It was clear that gathering a timely and comprehensive data set would be the key element to meeting the Dean's request. Post processing data capture from the mainframe systems was discarded as a standalone solution because the authorization loops caused significant delays in mainframe data entry. Preprocessing data capture of all College transactions was the most feasible solution but had two weaknesses. First, externally generated transactions would not be captured leaving a data set that was incomplete. Secondly, CBCC staff had already experimented with several database products. PC based databases were too weak for the job while minicomputer databases were beyond the limited financial means of the College. Only the relatively new client/server software offered a cost effective solution that still provided enough performance, security, portability, and connectivity to make such an approach viable. To address the second weakness, the CBCC opted for an Oracle client/server platform built around the College's existing Banyan Vines network. Key factors in this choice were Oracle's portability, availability for Banyan Vines networks, and the Oracle expertise already present in two other administrative areas on campus. With hindsight, this was an excellent choice as the product has met all expectations. Addressing the first concern of preprocessing data capture was a more complex issue, but, with the Dean's support, the CBCC proposed a campus wide effort to develop electronic transaction initiation, approval, and processing. This project was presented as the College Information System (CIS). A set of five integrated client/server database modules (Human Resources, Financial Services, Undergraduate Information, Graduate Information, and Research Services) that addressed the general needs of administrative end users. The CBCC had three objectives in proposing the CIS: 1. Make all campus transactions accessible to all users. 2. Promote changes in administrative procedures that led to more efficient processes. 3. Create a broadly based coalition with sufficient political muscle to manufacture change. This strategy was initiated by contacting the College Administrative Advisory Group (CAAG). The CAAG is a group of Assistant Deans, Directors, and Managers from the colleges, libraries, continuing education, and several auxiliary agencies. This group agreed to endorse the CIS if the University's Information Systems was an active participant in the design and implementation of the project. After joint discussions, the CAAG, CBCC, and IS signed a partnership agreement with the following distribution of responsibilities. Through its broad support and direct channel to the Deans, the CAAG empowered the partnership to approach and enlist key university administrators from Internal Auditing, the Controller's Office, Registrar's Office, Human Resource Services, and many other areas. Additionally, the CAAG provided end user expertise, prototype reviewers, and assumed the financial responsibility for connecting their users to the CIS. Information Systems enabled the partnership by providing financial and technical assistance to the CBCC staff, reworking rough CIS prototypes into production modules, providing the production platform and server software, and guaranteeing to maintain and enhance the CIS production modules. Their successful efforts to tactfully defuse the inevitable political fallout were also critical to the project's overall success. CBCC implemented the partnership by providing client/server expertise IS had not yet developed, a development platform, and strong, aggressive team leadership for module analysis, design, and prototyping. METHODOLOGY A rapid prototyping methodology was selected for the following reasons: * Rapid prototyping is an action oriented process that discourages posturing and gamesmanship. Prototyping brought tangible products into the hands of reviewers quickly. The speed of delivery made review groups intolerant of group members who dissembled or otherwise blocked action items. * Prototyping let the end user shape the design process. Since the design process was not artificially structured by the development team, the end users had a greater sense of control, involvement, and impact. * End users were not familiar with the potential of the client/server environment and had difficulty visualizing what was feasible. Prototyping's iterative review process allowed end users to experience client/server possibilities and encouraged a broader, more visionary response from end users. * Prototyping built a working model that shaped reasonable end user expectations. End users reviewed a working prototype containing the features they had specified. If a feature could not be implemented, the reasons were identified and explained to the end users during the review process. ANALYSIS/DESIGN OF BUSINESS PROCESSES Analysis and design committees were formed. They consisted of three groups: policy setters who managed many end users, were responsible for a family of business processes, or influenced the University policies and procedures surrounding a family of business processes; end users with generally recognized expertise within a specific business process; and technical experts who translated and reconciled committee work into prototype specifics. Policy setters were typically University business officers, for example the Controller, Associate Dean of the Graduate School, or an Assistant to the Dean for Administration (College). End users came from all parts of the University organization, for example accounting technicians, undergraduate advisors, or staff assistants. Technical experts were managers of administrative subsystems, development team members, or analysts from Information Systems, Analysis and design success was predicated on an environment that encouraged the free flow of ideas, mutual respect for each group's needs, and dialogue instead of confrontation or impasse. Needless to say, the committees struggled to maintain this ideal, but leaders from each group stepped forward at crucial times to facilitate, encourage, and defuse. This ongoing and relentlessly tiring task proved to be the most difficult of the entire project. As the committees defined business functions, the technical experts translated these definitions into database design, functionality, and finally working prototype. Committee results were relayed to the programmers immediately after the committee meetings. Any concerns or questions about technical feasibility were identified and brought to the committee's attention at the next meeting. The programming staff consisted of one or two graduate students who were usually quite familiar with the Oracle development tools. They were equipped with powerful PC workstations and the standard Oracle development tools. They worked an average of 20 hours a week with an increase to 25 hours a week during the end user review process. The development team set two design constraints for the committees. First, the prototype would contain 80% of any business process and would not address the remaining 20%. This constraint was based upon the belief that the easiest 80% of any business process contained all the essential elements while the remaining 20% contained all the customization (and 80% of the development workload). The CAAG and Information Systems did soften the long term impacts of this constraint by adding two stipulations: 1) Any administrative unit could do its own customization but had to bear the full cost of that effort; 2) A standing review committee would judge future customization proposals and those that provided broad benefits without undue costs would be adopted and maintained by IS as part of the production module. The second constraint stated that manual processes would be mirrored whenever practical. This constraint had four powerful advantages: it reinforced the value of existing processes and their supporters; it reassured employees who were dependent upon the existence of these processes and would be important contributors to the prototypes; it encouraged the committees to focus on how they might improve existing processes without reinventing them; and it helped overcome end user inertia by producing prototypes that contained many recognizable elements. Even with the second constraint, the open environment of the analysis and design committees encouraged an atmosphere that has lead to truly remarkable changes in administrative perceptions. These frank and open discussions of administrative procedures have led to a re engineering of administrative processes that goes far beyond the scope of the initial project. In fact, all of the campus' administrative procedures are being looked at from a new perspective. A perspective that focuses on using collaboration, cooperation, and partnership to effectively achieve improvements in quality and productivity. Improvements that are being defined by the whole campus community. IMPLEMENTING THE PROTOTYPE When the end user analysis/design committees were finished and a prototype was working, each administrative unit was asked to provide a review group consisting of 4 to 6 end users. Most of these end users had not actively participated in the analysis/design process but were going to be primary users of the production module. Module prototypes went through six to twelve review sessions depending upon the number of available reviewers and the complexity of the module. Reviewers came to a special facility where they had their own PC for testing the prototype. To help the reviewers focus on the prototype features and to reduce frustration with the new environment, there was one technical support person for every two reviewers. As each feature of the prototype was explained, the reviewers used the feature and provided their perception of its effectiveness. Every effort was made to address ideas, suggestions, and problems on the spot. Most of the comments were refinements to screen or report design, but there were instances where reviewers made suggestions that offered significant improvements to the functionality of the prototype. These suggestions were shared with other reviewers. If they reacted favorably to the idea, it was presented, informally, to the members of the end user analysis/design committee. Several productive enhancements were identified and implemented in this manner. All review groups were given several weeks to comment fully about the prototype. During this period, all modifications were implemented and the prototype was documented. In the final step, the prototype was handed over to Information Systems to be reworked and reshaped into a production module. TRANSITION TO THE UNIVERSITY LEVEL The prototypes created by the College of Business were transferred to IS for implementation across all colleges. Initially we expected that the modules would be implemented as created in the College of Business. However, when the time came to do it, we found the initial module prototype contained unacceptable technical differences regarding data and keyboard standards. These differences were resolved in future prototypes. Nevertheless, there were real difficulties in implementing the prototypes from an expected source but a surprising direction. The first module (graduate information) was shared with the graduate school and there were some significant differences between the perceptions of college administrators and the graduate school. Superficially, these differences focused on some of the traditional reporting, but at a deeper level there were real differences in defining the roles of the respective players. This was the first time a central group had not dominated the definition and design process for central administrative software. Overcoming these differences required actively selling the attractive functionality of the client/server modules. As the second module (undergraduate information) was being completed and receiving rave reviews by college administrators, central student records administrators took notice. It was obvious that the module contained degree audit functionality that was planned for the mainframe. After a detailed review of the module, it was agreed that the college created software would be enhanced to produce an official university document. This also meant that central policies would be reflected in the module and that the records office would maintain most of the data tables. The addition of central influence meant that the project had changed from the original plan. REDEFINING ROLES The desire of central administrators to use parts of the CIS system was largely unanticipated and led to the creation of a supplement to the informal agreement created at the beginning of the project. The supplement dealt with the process of moving the modules from prototype to production and specified the role of the college administrators. It also clarified respective roles regarding future enhancements, maintenance, and any new modules that may be created by the colleges. A college review team was established to represent the interests of the colleges in the implementation process. Check points were defined to assure the integrity of the functionality in the prototypes and a thorough college level testing process was included. A key part of this document was the role of the college review team in reviewing and prioritizing requests for change. However, this supplement to the contract was limited by an agreement with central administrators on three issues: 1. The availability of data must be approved by its central owner. 2. Any process that creates data for input to a central application must be approved by the responsible central administrator. 3. Both the content and presentation format of data for students must be centrally approved. These limits are not surprising. What was surprising is that these are the only limits. In addition, the agreement specifically states that central administrators will not judge the desirability or usefulness of college developed software. A simple process was created for implementing the supplement. Namely, Information Systems will assure that the appropriate people are brought together to review any proposals from the colleges. So, after several years of organizational jostling, a compromise acceptable to all parties is in place. The colleges have established their right to define and create centrally supported administrative software. Central administrators have established that they control certain aspects of university administrative data and its use. Progress. IMPACTS ON INFORMATION SYSTEMS These interlopers in the colleges had their impact on the central development staff, too. UNIX - which one? Relational database -what's wrong with IDMS? Client/server - sure. Come back after we get payroll fixed. Seriously, this project was the opportunity to make some significant changes within the central Information Systems office. The Information System's staff was very much aware of the changes occurring in computing, and the only real question was what would the specific impacts be. Whenever IS encounters significant change, it is always the policy that existing people will be trained to take on the new tasks. The only question is how to do it. For this project, the start was to transfer a software developer from an administrative department to Information Systems. This person had extensive experience with microcomputer applications development. Consequently, he installed the first module and became the seed person for training the mainframe staff. Unfortunately, until very recently all of the central support skills for the project were focused on only one, sometimes two, people. The new employee was the systems programmer, DBA, network manager, and the applications specialist. His vacations were scary events. IS' efforts to train other analysts to support the project did not yield any clones because it was simply too much for one person to learn all at once. The new analyst's experience represented ten years of incremental learning, and the mainframe analysts were simply overwhelmed. Early attempts to create micro- generalist clones were also handicapped by a lack of formal training. Consequently, a different approach was necessary. Will any one be surprised that the new functions are now being dispersed to their mainframe equivalents? And formal training classes are being provided where the expense is not great. The IDMS DBA is going to Oracle school. A mainframe systems programmer is going to UNIX school. These two will use a recently replaced IBM RS/6000 as a training platform. Security administration on the CIS platform will be handled by the same people who manage mainframe security. Applications support will be provided by the same analysts who support the mainframe. Unfortunately, providing a complete Oracle training program for all of the analysts is not financially possible, so their training will be on-the-job implementing specific projects using training materials supplied by the vendor: tutorials, manuals, and texts. One problem remains. Within Information Systems, the skills required for designing and creating new applications have fallen into disuse because of the policy of purchasing mainframe software. In addition, the contemporary methodologies are quite different from those used ten years ago. CIS implementation has become an opportunity to explore these newtechnologies. Accordingly, an experiment with Oracle CASE is underway. The prototypes created by the College of Business are viewed as the strategy and analysis phases of information engineering. The detail design and construction phases will be done using Oracle CASE. Support and future enhancements will use the CASE dictionary and Oracle tools rather than relying on traditional documentation and third generation languages. The early results of this CASE experiment have been very promising. COMPUTER DEMOCRACY Technologies often go through phases that start with only a few highly skilled people users and end with the product becoming ubiquitous. The telephone is a commonly cited example, and a parallel could be drawn between the early telephone operators and the mainframe programmer. The CIS project at CSU may be the technological turning point where administrative computing is moving from an autocracy towards computer democracy. Obviously, the project has distributed many of the key aspects of administrative computing to a far larger group of people. However, the most important accomplishment may be the general acceptance of distributed responsibilities that has followed the distribution of tasks. The acceptance of these new responsibilities will be the foundation for further democratization of administrative computing at CSU.