Revolution in the Information Systems Shop: Reengineering the IS Workplace Copyright 1994 CAUSE. From _CAUSE/EFFECT_ Volume 17, Number 1, Spring 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 REVOLUTION IN THE INFORMATION SYSTEMS SHOP: REENGINEERING THE IS WORKPLACE by Robert B. Eaton and Rodney C. Schuler ABSTRACT: One of the key issues in current efforts to redesign campus business processes is whether the new processes should be enabled by information systems that focus on them or whether the new processes should share highly integrated data and common methods. This article relates a new approach to administrative applications at the University of Saskatchewan--one that entailed reorganization, reorientation, and retooling. Since the 1960s, when computers began to be used for administrative tasks, systems development at the University of Saskatchewan has been focused on individual functions usually performed by one organizational unit. For example, in the finance area, processes dealing with financial accounting were "automated," followed soon by accounts payable and receivable. In the human resources area, attention was paid to the payroll function, while the foci of automation efforts in student records were admissions and registration. We refer to these systems, sets of computer programs designed and implemented to process the data specific to a functional activity (e.g., admissions), as "islands of automation." To extend the metaphor, we may even think of all the systems used in an organizational unit as a system archipelago. In the 1970s, systems designers, realizing that the output of one system was frequently used in another, attempted to make them work more closely by "automating" the interactions. One system created transactions that were "fed" into another, more or less automatically. Thus, with the construction of bridges (or causeways, in some cases), began the age of the integrated application system. An example of this is a 1970s-style "integrated" financial records system, consisting of purchasing, accounts payable, and financial accounting subsystems. At the risk of over- simplifying, the purchasing subsystem "feeds" invoice transactions to the accounts payable subsystem, which in turn "feeds" transactions to liquidate encumbrances in financial accounting. It is more appropriate to refer to these as interfaced, rather than integrated, application systems, since there is merely an automation of the interaction between existing systems. When the age of data administration arrived in the 1980s, it became apparent that these so-called "integrated systems" were misnamed. The concept of data administration implies managing information as an enterprise [read: institutional] resource, not as a resource for a single function. This can be illustrated with the attributes "name" and "address." The library maintains the name and address of individuals librarians know as "patrons," while the registrar maintains names and addresses of individuals known as "instructors" or "students." The controller maintains the names and addresses of "account administrators," "travelers," and "vendors." The personnel/payroll office does the same for "employees," as does the development office for "alumni." However, a person whose job it is to administer data understands that a "patron," "instructor," "student," "employee," "traveler," "vendor," and "alumnus" are the same thing--a person--and whether a person borrows books, instructs, studies, works, travels, administers accounts, or graduated from the institution are merely characteristics of that person. This implies that data about the same things are used by many organizational units and applications that support those units' activities. Unfortunately, systems thinking was not able to deal with this cross-functionality, since it perceived data only in the context of the function being performed. To the library system, the name and address of a "patron" is different from that of an "instructor" or "student," let alone "employee" or "alumnus." In other words, the library maintains the names and addresses of the same entities as are being maintained by the personnel office, the registrar's office, the controller's office, and the development office (not to mention others). Thus, it became apparent that systems thinking had not produced a data resource that was usable by all of the institution's functions that needed to use it. Systems thinking had produced a data resource that was "dis- integrated." The same data were being recorded and maintained by many islands in each of the institution's many systems archipelagos. New administrative applications approach The realization of this came as quite a shock to those of us in the University's computing services department who were developing administrative applications, since it was clear that we were mostly responsible for it-- for twenty or so years we had been the greatest proponents of "systems." We had led the University in an orgy of systems development and implementation during the early and mid-eighties, replacing the library, development, financial, human resources, student records, and a host of smaller systems. Most of these new systems were purchased packages, and we had been required to tailor them to some degree. In addition, in our view, the twelve programmers, programmer/analysts, and systems analysts in the administrative applications area had become system experts, e.g., specialists in finance, human resources, or student records. They received much of their fulfillment by doing good things for their "users," and in response, their "users" expected to deal with certain people whose purpose was to maintain and enhance their systems exclusively. At times it seemed that functional managers saw our employees as their programmers, that is, extensions of their department. Furthermore, departments that had had programmers "allocated" to them for some time expected that their software would be modified more or less automatically, while other organizational units went without attention. It was clear that we were part of the problem. It was also clear that the status quo had to change, and that our area should be prepared to lead this change. Our goal, then, was to give the University a tool to use in its reengineering efforts: a group of information scientists and engineers that could be deployed to create information services for the institution, as opposed to operational systems for individual functional activities. To do this, we needed to completely change our approach to our business. This new cadre of information scientists and engineers, whom we now call informaticians, had to be liberated from the functional silos they occupied. The obvious answer was to change the infrastructure (the only option management had), that is, to reorganize. We also had to reorient or change our relationship with our external environment. And, of course, we had to retool, both in terms of hardware and skills. Reorganization Nobody in our area had experienced all three of these changes happening at once. Some of us had moved from organization to organization. During our careers, all but our most junior colleagues had changed from supporting one function to another, and of course we all had adapted to new hardware and software technology. But changing all three at the same time was the same as turning the organization upside down and shaking it. Not really knowing what was about to happen, we began. In an effort to engage everyone in our area, the notion that we might not be organized the best way was brought up at our weekly "chat." Successive chats did not achieve a consensus; in fact, it appeared that nothing could be changed: everyone was focusing on the reasons why things had to stay the same. To break that impasse, at the next meeting the area manager proposed a new organization structure, one that he thought would address the need for shareable data and care of existing systems, and would free some people for getting us out of the mess we were in. Everyone was asked to think about it, talk about it, and criticize it. It was a month before the subject was brought up again, but after three months of discussion it was clear what the structure should be: an application resource management group, a data resource management group, and a "development center" that focused on the creation of new software. Most thought that it would not work. Worse yet, many thought that the energy to drive the transition did not exist. Regardless, we began operating with the new structure. The application resource management group became responsible for the long-term viability (maintenance) of applications, including our current legacy application systems until they are replaced, as well as new data acquisition applications that are developed. The coordinator of this group was, essentially, a product manager. While the manager of a development project's goal is to produce the product on time and within budget, the product manager has to live with the result. Therefore, the application resource management coordinator was also responsible for software quality assurance. The data resource management group, led by a database administrator, became responsible for managing the physical database environment and the data management tools (our DBMS and repository), maintaining the repository, and creating the physical data design on development projects. The "development center" group had two characteristics. The first was project orientation, i.e., the development center would only do projects, and hence its staff would be full- time project managers and estimators. In most institutions, including our own, project management is seen as an unnecessary overhead task. Consequently, the development center had no permanently assigned staff. Rather, at the mounting of a project, a project manager would be appointed to plan the work and be responsible for estimating each task. The project manager would generally be one of the senior informaticians, but could also be a client or someone contracted from outside the University. Once the project plan was approved by the sponsors, the best available people would be assigned. These could be informaticians from the administrative applications area, or they could be from functional areas. The second characteristic, that projects would usually be multi-disciplinary, was important because it provided a mechanism for cross-functional cooperation or collaboration. Using this approach, functional units and information services are able to work towards a goal that is in the institution's interest, rather than that of one group. Resources, usually human but sometimes financial, can be transferred to a project without one group feeling that it has lost to another. Reorientation In general, we felt business redesign should be left to staff in functional areas. We decided that we would have the greatest effect if we assisted functional areas in analyzing their own business practices and understanding which of their business processes were already being performed elsewhere in the institution. For example, recording a vendor's name and address couldn't be much different from recording a student's name and address--or a patron's, or an employee's. Consequently, if a database and function already exist for recording names and addresses, then they can and should be used. Further, the institution's information services professionals are in the best position to know this. As mentioned earlier, this meant changing people's area of expertise and social attachments. For example, a human resources analyst who was known and valued by the personnel and payroll departments had to become a software scientist and engineer. That meant defining new areas of expertise and establishing loyalties first to the University and second to a functional area. People feel good about being the local expert in a particular area, so we had to find new areas in which they would be recognized as authorities. Identifying new areas of expertise was not too difficult, but before assignments could be made, employee talents had to be carefully assessed and new skill development encouraged. It began with the understanding that, as Watts Humphrey wrote in Managing the Software Process, we "... probably [had] about the best team we could get .... While it is always desirable to recruit better people, it is also wise to focus on making better use of the people we already have. This always pays off"[1] The first change was to create a database administrator position. This was done by naming someone DBA unofficially, and then changing the description of a general systems analyst position when it became vacant. This position was vacated by a senior analyst who was more comfortable furthering his career in a functional unit. When an organization goes through a metamorphosis such as ours did, there are some who choose not to enter the next phase. This suited everyone well: first, he was able to provide needed business analysis in that area and, second, it provided us with a vacant senior position from which the DBA position was created. Next, we attended to areas of expertise. If we were to work in a project environment, we needed project management expertise. To our great fortune, we were able to hire a project management consultant half-time. Her contract specified that she was to tutor those who were struggling to manage projects, rather than managing those projects herself. This approach of using her as a true consultant rather than a term employee had a phenomenal effect and has convinced us that tutoring is the best way of providing instruction. When she left, one of her proteges was named as our internal project management consultant. Business analysis was the second area of expertise developed. The role of the business analyst is to construct a baseline or model from which change can be controlled. The change in this case is the reengineering of business areas. Although larger organizational units can afford their own business analysts, there are many that can not. To address this, senior informaticians who had been marooned on functional islands, but who are analytically sophisticated, have become business analysis experts. This expertise is available on a project basis to units that cannot afford their own analysts. Another area of expertise is emerging technologies, of which one of the most quickly emerging is object orientation. We recognize that everyone wants to be current, but we simply don't have the time for each person to be current with the latest methods and tools. Our object-oriented expert does, though. His job is to be current in what is obviously an important, albeit emerging, area, and to keep everyone informed. Finally, we have also created a toolsmith position, someone who will be able to adapt the software tools we use so that they can be used as productively as possible. As Watts Humphrey wrote, "... even the best professionals need a structured and disciplined environment in which to do cooperative work. Software organizations that do not establish these disciplines condemn their people to repetitively solving technically trivial problems."[2] On any project, much time is spent on setup, e.g., creating shared directories and libraries, setting protection codes, and tailoring software tools and ensuring that all project members know how to use them. These are the types of jobs we have assigned to the toolsmith. Retooling One of the most profound realizations we have come to is that we work together. That may seem obvious, but as we began to retool, it became apparent that many of the highly touted personal productivity tools were just that--personal. While making individuals more productive, they did little to promote group effectiveness. The most obvious example is personal time management--computerized or manual. While each person may be well organized, groups of people are forced to coordinate their time in the same inefficient ways they always have. Our retooling goal, then, was to create as collaborative an environment as possible. Of course we wanted people to have powerful tools, but these tools had to promote shared work. Constraints such as complexity or urgency forced us to collaborate to solve a problem or create a software product. Consequently, we wanted to create a hardware and software environment that would, as Michael Schrage puts it, "allow two or more individuals with complementary skills [to interact] to create a shared understanding that none had previously possessed or could have come to on their own."[3] For hardware we chose multiprocessing workstations-- VAXstations. Since the software we maintained and developed ran on a VAXcluster, it made sense for us to have VAXes on our desktops. With a 19-inch monitor, many executing windows can be open simultaneously. It is not unusual for an informatician to be working on four or five things at the same time. We have found that there is a gain of two hours of productivity for each person per day. That means that four workstation-equipped informaticians do the work of five! The greatest reason for using VAXstations, however, was software. As part of its "Education Initiative" program, Digital Equipment Corporation granted campus-wide licenses for all Digital software. Consequently, we have an extremely rich software tool environment. One of the most intriguing tools is used for personal time management and project planning. People, projects, and facilities (rooms or any other physical resource that needs to be scheduled) have planners. The personal time manager appears as a calendar that runs on an individual's workstation and can then be used to perform the usual time- management operations of booking meetings, defining tasks, and charging time. In addition, the planners of other people and facilities can be scanned for availability. When a project manager assigns someone to a task, the assignment shows up in the informatician's planner, and the assignment can be negotiated. Charging effort expended on project tasks works in the reverse: time charges are made in the individual's planner but also appear in the project's planner, where they can also be negotiated with the project manager. Software of this sort promotes communication and coordination rather than command and control. Note that rather than having to "report" time, people are encouraged to manage their own time. Time reporting, necessary for project control, is then added value to the empowerment of the worker. The toolsmith Changing the focus of administrative applications from individual systems to the institution as a whole required that there be staff with expertise in specific areas. As suggested earlier, this expertise is not in traditional systems; it is in cross-functional disciplines such as project management, estimation, methods, and what we refer to as "toolsmithing": the adaptation of software and hardware tools and environments to increase the effectiveness of other information professionals. It is not possible for employees to be adept with all tools used to define, build, and maintain software. These people work in sophisticated environments, using sophisticated tools. They often require assistance, since even bright, knowledgeable people may not use tools as effectively as possible, or may spend too much time "setting up" a project. The toolsmith is responsible for maintaining, customizing, and investigating software tools and establishing standard environments to enable the "software process." As defined by Watts Humphrey: The Software Process is that set of tools, methods and practices we use to produce a software product. The objectives of the Software Process are to produce products according to plan while simultaneously improving the organization's capability to produce better products[4] The goal of the toolsmith is to relieve other software workers from drudgery, by coordinating the planning, development, and support of methods, techniques, and tools. On development projects, the toolsmith quickly creates a standard development environment that boosts the project team's productivity while supporting change control and project planning and control. The data and application management staff rely on the toolsmith to ensure that the software tools they use are up to date, integrated, and as simple to use as possible. A list of the tools in our software engineering tool kit appears in Table 1. Toolsmithing focuses on four categories, the first of which is extending the applications environment. This means customizing the tools that are used to accomplish software definition and support tasks. The client's software environment is tailored during development, but attention never seems to be paid to tailoring the development and maintenance environments. Software tools are acquired and simply used (often without reading the documentation). This does not maximize the benefits possible with many of the available tools. By tailoring our tools, we help increase productivity and maintain the standard practices that have been developed. The tools are thus used consistently for all tasks. This is important in an environment where each staff member is expected to support multiple information services. Much of our time as IS staff is spent editing such things as source code, mail messages, memos, etc. Therefore, it makes sense that the most valuable tailoring would be made to the editor, since we use it for so many different tasks. Several extensions have been added to our editor to ensure that it performs all the tasks we need it to do. This allows us to have standard features, whether we are editing source code or composing a document. The second category is infrastructure support for projects. An important aspect of a successful project is that the environment be conducive to collaboration and that it conform to the standards of the group. The toolsmith's job is to create an optimized environment, so that analysts and developers can almost immediately begin their work. The toolsmith may also be able to spot and ameliorate difficulties with tool use. The third category is consulting support for staff. With short staffing, it is nearly impossible for every staff member to keep up with all the new tools and utilities as they become available. Staff members with expertise in various different tools are known to be available as consultants to the remainder of the group. Monotonous tasks are often time consuming, and are performed ineffectively by staff, because they do not know a better way and do not have the time to investigate and learn one. By having a resource with expertise in the various tools, there is someone who can point them in the right direction and provide special-purpose instruction, increasing the capability of highly paid, valuable staff. For example, when the database administrator needed special editing to format database definition statements, a twenty-minute consultation allowed the task to be completed within half an hour instead of the estimated one day. The final category is investigating the applicability of new tools. We have a large number of software tools at our disposal. We know that many of these tools would be useful in our work if we had the time to investigate them. By having a staff member whose job it is to investigate these new tools and their applicability to the current environment, the incorporation of new tools and ideas is made easier. An example of IS business process (re)engineering One of the main business processes of an information services department like ours should be managing changes to software. Until 1990, however, the sad truth was that there was little management at all: the only control was the number of changes that could be made by the programmers allocated to the functional areas. There was no management oversight of what changes were applied, no prioritization in an institutional context, and certainly no audit trail. In short, making changes to software was ad hoc and often chaotic. While this may have been tolerated when programmers were allocated to functional areas, the application resource management group was significantly smaller than the number of programmers doing maintenance in the past and was now trying to maintain all legacy systems. Clearly, we needed a process to truly manage changes, and that process had to be engineered, i.e., designed. Figure 1 depicts the model of our software change management process, which we developed three years ago and have altered little since then.[5] As can be seen there are three sources of change requests: clients (the functional users of the information systems), informaticians (defined earlier), and software vendors (with whom we have maintenance contracts and who, from time to time, send us bug-fixes or enhancements; these vendor-supplied changes are also treated as change requests). Figure 1: Software change management context diagram [FIGURE NOT AVAILABLE IN ASCII TEXT VERSION] Figure 1 also shows that both clients and informaticians discuss change requests by supplying "replies" to them. These replies are kept in context with the change request. A final reply, labelled as "summary," briefly sums up the work and anything learned during the completion of the change request. Periodically, an overall summary of change request work, labelled as "change request status report," is prepared and distributed to the Change Request Priority Committee. This committee, as its name implies, also provides advice regarding the priorities of change requests. Figure 2: Software change management process model [FIGURE NOT AVAILABLE IN ASCIIT EXT VERSION] Figure 2 illustrates this process in more detail. It shows the subprocesses that are performed to manage the changes to the software. Accompanying this process model (but not shown) is an entity-relationship model describing the data that are being kept. Figure 2 also illustrates the points where the toolsmith adds value by integrating various software tools and providing a standard structure across applications. The highlighted portions of the model show where customizations and extensions have been made. The process described by these models allows for management oversight, client input to priority setting, task management (i.e., clear definition of responsibility for a change and the recording of effort, both estimated and expended), and a complete audit trail. Since a task is created with a project management tool for each change request received, scheduling is facilitated, and we have an accurate idea of our maintenance backlog. Where we are today These changes have been far reaching, but not all implications have been discovered or addressed. While new areas of expertise have been recognized and assigned, the software change management process is the only one that has been rigorously defined and automated. Clearly, the software development process needs definition, and undoubtedly there are others that need to be addressed. Administratively, a new performance-appraisal process, based on employees creating and utilizing shared data and methods, is still to be designed and implemented. Retraining has also not been successfully addressed. As mentioned earlier, we are convinced that tutoring/coaching is the best way to transfer knowledge, but capable consultants and the funding to pay for them are difficult to find. In fact, funding for any kind of training is difficult to find, as is the time needed for learning and process improvement. It is extremely difficult to convince clients of the need to improve productive capability while they are so anxiously waiting for products. There are a couple of techniques that have proven successful, however. One is to dedicate time to learning--our guideline is two days per month. Another is what we call a research project. Research projects are process-improvement or learning mini- projects of one to two weeks in duration. They are staffed by personnel who have been assigned to a development project just completed. Normally, the development project team members would replace application resource management staff that had just been assigned to work on the next project. However, before the next project is begun, a research project is undertaken. The notion of a research project and when it is scheduled has three important benefits. The first is that anxious clients are less likely to notice the time that is taken to do what they think is non-productive work. Second, there is the ability to control learning and process-improvement tasks so that there are measurable results. Finally, the research project provides a transition between development and support activities. The underlying principles that guided our reorganization, reorientation, and retooling are still an important component of our administrative applications approach. In yet another reorganization of computing services that took place earlier this year, however, the data resource management and application resource management functions were consolidated into an institutional databases and applications area. At the same time, in recognition that it had become an essential management tool, the development center was elevated organizationally to a separate area reporting to the department's director. Elevation of the development center to a direct reporting relationship to the management team has allowed management to identify and initiate projects that are staffed from all groups in the department and to make departmental commitments. By assigning staff to projects in the development center, management is doing two things: limiting the amount of maintenance that is undertaken and doing the utmost to ensure that developers are focused on their tasks. It has also allowed us to cooperate more effectively with our clients: when a project is initiated, our clients are able to contribute to the project as developers, not merely consumers. In fact, the project leader for our recently completed telephone registration project was from the registrar's office! Conclusion We all know of the rapid change in price and performance of computing and networking hardware. This is also happening at a time of funding decreases, escalating demands for information (by academics and administrators alike), and the growing ability for information consumers to process data themselves. These forces virtually guarantee massive redesign of our institutions' business processes and the information systems that support them. Having grasped this reality, institutions will have to deal with the issues of transition. One of the key issues is whether the new processes should be enabled by systems focused on them or whether all new processes should share highly integrated data and common methods. While the traditional systems- oriented IS organization may be able to deal with the former option, it certainly cannot deal with the latter environment. The organizational model from the University of Saskatchewan presented in this article addresses the development and support needs of the new IS organization, whose goal must be the creation of shared information services, not systems. *********************************************************************** Table 1: Tools in the Software Engineering Toolkit * Language Sensitive Editor--an extensible editor that "knows about" languages. In addition to giving language syntax assistance, one is able to compile programs and review compiler errors. * Code Management System (CMS)--a librarian for tracking and controlling changes to source code (programs, documentation, 4GL applications, and so forth). * Module Management System--an application-building function for simplifying and automating the building (compiling and linking) of applications. * VAXnotes--a conferencing tool for tracking change requests and communicating with clients and other staff. * VAXMail--a direct communication tool. * DECwrite--a document-publishing application. * Motif--a windowing environment. * DECplan--a project management application. * CDD/Repository--a distributed repository of institutional information definitions and descriptions. * DECdesign--an analysis and design tool. * VAX Test Manager--an application for organizing and automating regression tests. ====================================================== Footnotes: 1 Watts S. Humphrey, Managing the Software Process (Reading, Mass.: Addison-Wesley, 1989), p. 26. 2 Ibid., p. ix. 3 Michael Schrage, Shared Minds, the New Technology of Collaboration (New York: Random House, 1990), p. 40. 4 Humphrey, p. 3. 5 The model is fully described in a paper presented at CUMREC '91, "Automating Change Control," by R. B. Eaton. ======================================================================== For further reading Smith, W.G. "Requirements for IRM." Database Newsletter, May/June 1990. Smith, W.G. "Organisational Structure and Policies for the IRM Environment." A presentation made at All About IRM '91, Beaver Creek, Colorado, July 1991. ======================================================================== Robert B. Eaton is Manager, Institutional Data and Applications at the University of Saskatchewan. As part of the Department of Computing Services, his group's primary focus is the design, creation, and management of the University's data resource. He has spoken at many conferences, most notably CAUSE and CUMREC, on how small IS organizations can utilize current methods and techniques. Rodney C. Schuler is a programmer/analyst in the University of Saskatchewan's Department of Computing Services. In addition to his regular assignments he specializes in adapting software tools and environments to increase the effectiveness of those using them. ************************************************************************ This article was adapted from a paper presented at CUMREC in May of 1993 in San Antonio, Texas. ************************************************************************ 03/30/94 (meh) Revolution in the Information Systems Shop: Reengineering the IS Workplace