Old Systems Never Die... They Just Age Us Copyright 1992 CAUSE From _CAUSE/EFFECT_ Volume 15, Number 1, Spring 1992. 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 technology in higher education. To disseminate otherwise, or to republish, requires written permission.For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu OLD SYSTEMS NEVER DIE... THEY JUST AGE US by Gene T. Sherron ************************************************************************ Gene T. Sherron is Vice President for Computer and Information Resources and Associate Professor of Information and Management Sciences at Florida State University, where he is responsible for central academic and administrative computing and University-wide telecommunications. He has served on the CAUSE Current Issues Committee and is currently a member of the CAUSE Board of Directors. ************************************************************************ ABSTRACT: Ask seasoned directors of administrative computing about their information systems and many will tell you about aging systems that range from the large, integrated applications that still work only because an army of maintenance programmers prop them up, to the undocumented, stand-alone, machine-language antique that three veterans keep alive through heroic efforts. But aging systems all share one key characteristic: They have been ravaged by change to the extent that they are often unable to respond adequately to additional change. With each change to policy or state law or federal regulation, with each move to a new generation of hardware, programmers have patched over earlier changes. Given enough software layers to cover changes in hardware and enough computing power to handle the software layers, these aging applications can keep working for decades. But can the people who maintain them? Many colleges and universities run emulators to replicate earlier hardware and write simulators to keep those oldies running. Yet, sometimes the original author of such a program "ages" into retirement. The chore of fixing and upgrading aging applications software programs -- which have grown to tens of thousands of lines of code in some cases -- now eats up the lion's share of total software resources in many institutions. Generally, the maintenance burden has grown so large so fast that there are few programmers free to develop new applications. Maintenance is 80 percent of what we do, but the vendors have insisted on addressing only 20 percent of the problem -- the development side.[1] For decades, COBOL has been the consistent common denominator among financial and human resources applications. While it is old and somewhat unsophisticated compared to today's database and 4GL languages, it still serves us well. And we will probably continue to use it for several reasons. First, since it has been used on our campuses for decades, it is deeply entrenched in our applications and our mind set. Secondly, experienced COBOL programmers are abundant and can become effective in a short period of time. Finally, recruitment of COBOL programmers is relatively easy compared to database programmers, and their salary levels tend to be 20 to 30 percent lower.[2] Thus, in years of flat or declining budgets, campuses get boxed into the status quo -- staying with COBOL, continuing that flat-file architecture, and, above all, keeping those computing costs down! In addition to the human resources factor, we also must deal with the fact that software solutions lag far behind hardware advancements. CIO magazine recently asked a dozen top information executives to suggest issues they would like to discuss with CEOs of technology companies. The CIOs complained that software vendors still trail their hardware counterparts in creating new products.[3] With U.S. companies spending over $90 billion annually on software, it is discouraging to learn that software productivity today is lower than it was in 1950.[4] An informal campus survey As a means of investigating the aging systems problem at colleges and universities, we conducted an electronic mail survey late last summer. The "population" for this survey was derived from CAUSE members who listed e-mail addresses in the association's directory. From this cast of hundreds, three to five colleges and universities were selected from each state to receive our electronic "questionnaire." This limited number (150) sent nationwide made the survey manageable to administer yet reasonably comprehensive. Forty of the 150 individuals who received this network survey instrument responded (just under 27 percent), most within 48 hours. The first and primary question of the survey was intended to quantify the magnitude of the aging systems problem. The definition used for an "aging system" was an arbitrary one. For lack of any commonly accepted definition, we chose to suggest that an application or system was "aging" if it was over five years old and/or did not run under a database management system (DBMS). On average, respondents indicated that by this definition 68 percent of their administrative information systems/applications were "aging," and nine respondents were bold enough to admit that over 95 percent of their systems were in the aging category. The methods for migrating away from these aging systems would seem to take as many forms as there are institutions. But for ease of grouping responses, respondents were asked to rank in importance six suggested optional strategies: * move to all new software, as soon as possible * gradually upgrade to relational DBMS (a 5+ year program) * continue with our old production systems but provide users with 4GL- type retrieval software such as FOCUS, SQL, etc. * retain a mixture/balance of flat file and RDBMS applications; make changes as required * not a problem; we have modern systems * we'll keep our "aging" systems for a while The strategy ranked as first in importance (40 percent) was to "move to all new software, as soon as possible," with the second most popular strategy (34 percent) "gradually upgrade to relational DBMS, a 5+ year program." Even though no one selected it as their first strategy, a surprising 33 percent indicated that they would keep their aging systems for a while. A somewhat similar conservative response was to "retain a mixture of flat file and RDBMS applications and make changes, as required." Although only two institutions reported this as their "first" strategy, it was interesting that half of the campuses listed it as one of several strategies they are adopting and 29 percent included the "do nothing" option as part of their strategies. Top management involvement a must Before discussing strategies for dealing with aging systems, it might be helpful to make some generalizations about colleges and universities and information systems. As mentioned earlier, we can blame tight budgets and a paucity of good software, but the very nature of colleges and universities puts us at a disadvantage. In contrast to "bottomline" businesses, institutions of higher education see themselves as "service" organizations. As a consequence, it seems that most of our campuses are not positioned to: * totally replace administrative information systems * divert significant resources for new systems development * mobilize users to accept the status quo for years, awaiting new systems design, development, and implementation * allocate millions of dollars for new systems * readily adapt to change. As two survey respondents reflected in their open-ended comments: The problem is real and recognized, but the funding required to solve it represents a genuine barrier to any quick solution. (Kansas State University) We need to reexamine some of our budget priorities and make a significant investment in the acquisition of modern, more efficient software systems. (Florida International University) The history of administrative information systems (IS) development teaches us that institution-wide systems planning that emanates from the IS shop is often not successful. But we may be at the dawning of a new age. There is evidence that our constituency -- students, parents, and research sponsors -- is causing academe to be more sensitive to the "bottomline." Many campuses are realizing that senior managers, including the vice presidents, must be committed to new systems or things just won't happen. And, most of all, managers must get involved. James Martin's advice bears repeating:[5] Information is an extremely vital corporate resource. It affects productivity, profitability, and strategic decisions. Any resource that important needs planning from the top. Database plans tend to create political problems, often severe ones, and various factions will oppose them. Often these problems can be solved only when top management has made it clear that it believes that database is the way of the future, and has signed off on a corporate information systems plan. First the vision, then the solution What must be assumed then, before getting top management endorsement, is that there is a vision. There is a need for users and the IS leadership to build a credible vision of the institution's future applications software development and maintenance needs and then figure out how to achieve that vision. Then they must assess where they are with tools, methods, and the software development process.[6] Over the last decade, campus IS managers have opened their checkbooks and their organizations to long lists of new software development tools and techniques: * 4GLs and prototyping * structured programming and object-oriented techniques * graphics-based design and analysis tools * new data-oriented methodologies * integrated computer-aided software engineering (CASE). But tools, methods, and techniques alone won't fix broken systems, so it is timely to consider the range of options for dealing with aging systems. As a point of departure, the following are options for dealing with aging systems provided by the Index Group, a Cambridge, Massachusetts-based consultancy:[7] * Replacement -- generally feasible only for discrete applications. * Augmentation -- for applications with good technology but poor functionality. * Abandonment -- for applications with both poor technology and poor functionality. * Renovation -- for applications with good functionality but poor technology. * Maintenance -- similar to renovation but less extensive. Total replacement The frustration level with old systems would have to reach great heights for an institution to make a commitment to totally replace its administrative systems, but it does happen every now and then. One example is Penn State, which in the late 70s took the heroic step of replacing its administrative systems and entered into a vendor contract to build a total, integrated management information system. Even after the vendor partnership failed, Penn State's administration continued to be committed to new systems and supported their eventual development. A more recent example of total system replacement comes from The Citadel, which made its switch from a completely remote batch system running at the University of South Carolina's central computing facility to a brand new, campus-based proprietary system -- a two-million-dollar project that spanned a four-year period. Whether the campus is the size of Penn State's 40,000 students or The Citadel's 4,000, millions of dollars are involved and years are needed to make major changes to administrative systems. A more practical middle ground Certainly there is a promise of higher productivity and better information with DBMS. There are also complaints that it is a real "cycle hog," and with servers as powerful as yesterday's mainframes, why not distribute computing to the users? With so many "shadow bookkeeping systems" all over campus, the only real solution is to migrate to a "distributed" RDBMS, where users needs are met and information captured only once, at the user level. Power to the users! (University of Arizona) Because funds will not be allocated to replace all obsolete systems within a few years, we are exploring downsizing approaches. But will it scale to an institution our size? Can downsizing really be managed in a phased manner to achieve real savings that can be reinvested to substantially reduce the costs of replaced systems? Is there anybody out there who has tried it and generated some experience on which answers to these questions can be based? (Northwestern University) So while some of us are trying to evaluate downsizing and distributing, there is that middle- of-the-road approach that is not going to wait for RDBMS and "distributing." Since very few of us have an opportunity to start all over with a clean slate, the reality is that we have lots of installed applications, an entrenched way of developing software, and a management that is unwilling to pay the price of upheaval and uncertainty associated with the total replacement approach. So, consider some of this philosophical advice: It's not age, but quality of life that counts. If we bought all new systems today, it would take years to install them. By that time, they would all be old again. And most of the vendor software available today is already old -- much of it has been on the market a decade or more. So that's like buying a "new" used car. If a system has been well maintained, including periodic upgrading to current technologies, there isn't a strong reason to consider its age. (University of Wisconsin- Madison) Where do we want to be? The problem that lies ahead is not one of simply designing a new set of applications to address the specific needs of users. We have already spoken to the fact that funding all new systems won't happen very often. Moreover, it is not simply a technological challenge. To truly embrace the concepts of new systems, we face a management challenge in which the campus itself must change -- to simultaneously continue to use old systems, make strategic enhancements to some systems, and convert others to new technologies. And even we can't agree on whether our "new technologies" should be RDBMS, Unix servers, distributed processing, or downsized computing. Yet, the promise of these new systems is that they will provide a competitive edge in the higher education marketplace of the 1990s, if they allow us to leverage both time and people to achieve such success. In spite of all of this, campuses across America are doing more than "muddling through." Some (such as Princeton University) have been going about a quiet revolution for over a decade to replace every major system and provide users with modern retrieval tools. And even they would caution that "there are many (flat file) systems which work just fine the way they are. We will not replace them until they don't provide the functionality required." And at MIT over the past several years, a "reengineering" campaign has been underway as an approach to replace old systems: "Users will always be resistant to change. But they are willing to change and even participate in the design of a new system when they see systems people work to support the users and give them 'business functionality.'" Perhaps Columbia University's survey response provides an apt closing thought for where we all want to be: We will attempt to balance our desire for new systems against an assurance that we do so with a clear vision of our final target, with an assurance that our user community is being provided with the best service per dollar investment, and that our technological plan is well- grounded in the business of running the university. Informal survey on migration of aging systems 1. I would estimate that ____% of our administrative systems/applications are "aging" (i.e., systems over five years old and/or non-DBMS). 2. Please rank in order of importance the following strategies that you are considering: A. move to all new software, as soon as possible B. gradually upgrade to relational DBMS (five+ year program) C. Continue with our old production systems but provide users with 4GL-type retrieval software such as FOCUS, SQL, etc. D. retain a mixture/balance of flat file and RDBMS applications; make changes as required E. not a problem; we have modern systems F. we'll keep our "aging systems" for a while G. other 3. Opinions/observations/comments: __________________________________ ======================================================================== Footnotes 1 Jeff Moad, "Maintaining the Competitive Edge," Datamation, 15 February 1990, p. 64. 2 Report to the Faculty Senate on "Developing a Data-Base Strategy for Florida State University" by Tom James and Danny Hawkins, Florida State University, September 1990, p. 5. 3 Allen E. Alter, "Brass Tacks," CIO, June 1991, p. 110. 4 Jeff Moad, "The Software Revolution," Datamation, 15 February 1990, pp. 22-23. 5 James Martin, Managing the Data-Base Environment (Englewood Cliffs, N.J.: Prentice-Hall, Inc., 1983), pp. 58-59. 6 Vaughan Merlyn and Gregory Boone, "The Ins and Outs of AD/Cycle," Datamation, 1 March 1990, p. 62. 7 Glenn Mangurian, "A Full House of Options," Computer Decisions, January 1989, p. 46. ========================================================================