This paper was presented at the 1996 CAUSE annual conference. It is part of the proceedings of that conference, "Broadening Our Horizons: Information, Services, Technology -- Proceedings of the 1996 CAUSE Annual Conference," page 1-3- 1+. 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. To copy or disseminate otherwise, or to republish in any form, requires written permission from the author and CAUSE. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303-449-4430; e-mail info@cause.org. MANAGING THE IMPLEMENTATION OF AN ENTERPRISE-WIDE INFORMATION ARCHITECTURE Nicholas C. Laudato Dennis J. DeSantis University of Pittsburgh Pittsburgh Pennsylvania Fall, 1996 ABSTRACT In 1994, a team of faculty and staff at the University of Pittsburgh completed the design of an enterprise-wide information architecture and framework for engaging the University in business process reengineering. The architecture provides the blueprint for developing an integrated set of information services, processes, and technologies. It enables significant efficiencies in business and service processes, and facilitates informed decisions concerning information technology expenditures and acquisitions. Implementation of the architecture does not adhere to a traditional master plan approach, but rather adapts principles taken from the Oregon Experiment, to grow the envisioned information system from the ground up. In this approach, the enterprise-wide architecture evolves as user- proposed projects are developed in adherence to the information processing patterns articulated in the architecture. This presentation explains a unique approach to guiding and managing implementation of a pattern-based enterprise-wide architecture at a large institution. It reviews the organizational structures created to support the architecture and to address the infrastructure issues that are prerequisite to its successful implementation. Finally, it summarizes the status of the projects currently being implemented under the guidelines of the University Information System Architecture. BACKGROUND In February 1993, the University of Pittsburgh's senior administration initiated a project to transform the institution into a modern organization where information is viewed as an asset and used to strategic advantage. The Information Architecture and Process Innovation Project was an in-house initiative, lead by a respected senior faculty member and staffed by four other individuals taken from their normal responsibilities for the life of the project. The project team defined the following mission: * Design an architecture for the University Information System (UIS) that will provide a framework for making decisions about information systems and for improving the UIS in the future; * Establish a methodology for business process reengineering using the UIS; and, * Develop a plan for migrating from the current systems to the envisioned UIS. The team made their final recommendations to the University community in June 1994, in the form of a 500-page report and a 40-page summary, titled "Reshaping the Enterprise: An Overview."[1] The architecture project is further documented in "Reshaping the Enterprise through Information Architecture and Process Reengineering."[2] This paper focuses on the issues related to guiding and managing the implementation of the information architecture. It reviews the organizational structures created to support the architecture and to address the infrastructure issues that are prerequisite to its successful implementation. It also summarizes the status of the projects currently being implemented under the guidelines of the University Information System Architecture. KEY ELEMENTS OF THE PROJECT'S APPROACH From the beginning, the Information Architecture and Process Innovation Project Team felt it was critical to involve as much of the University community as possible in its deliberations. To this end, the Architecture Team sought and interviewed nearly one hundred influence leaders among Pitt's faculty and staff. With input from these individuals, the Architecture Team developed a statement of the architectural philosophy and a set of principles on which to base the design of the University Information System. They presented this statement to faculty committees and to special interest focus groups, and published a draft statement in the University Times. As a result of this effort, the information systems philosophy statement represented a general consensus of the University community. The information systems philosophy and set of principles formed the basis for a pattern- based architecture. This approach was taken in preference to a more traditional "master plan" approach in order to avoid the common problem of plan obsolescence caused by rapidly changing technology. The pattern-based approach promised to prevent the architecture from becoming obsolete before the University made any significant progress toward its implementation. The pattern-based architecture was intended to enable administrators to make decisions about developing, modifying, or acquiring components of the University's information systems based on the components' adherence to the specified patterns. The patterns would be subject to on-going review and refinement to ensure that they incorporate advancing technology and continue to meet the needs for which they were designed. The information architecture would evolve as more and more projects are implemented that comply with its specifications. The Pitt approach recognized a close relationship between information engineering and business process reengineering. Information processing technology was viewed as critical to empowering users to reengineer their business processes, and the reengineered processes were seen as determining the need for the information technology. The University administration looked to its process reengineering efforts to realize savings and efficiencies that would cost- justify its investment in information technology. Finally, the Architecture Team sought to recommend guidelines that could be implemented using state-of-the-practice technology and reasonably cost effective methods. For this reason, they developed a set of working application prototypes to illustrate some of the principles articulated in the architecture statement. These prototype applications would serve as validation or "proof of concept." The most ambitious of the prototypes, a client/server application that puts a graphical user interface on a character-based legacy application, is currently in use by over 200 faculty advisors and staff in ten schools and four campuses, and is being implemented by several others. The pattern approach and the registration/advisement prototype application are both explained in "You CAN Teach an Old Dog New Tricks: Extending Legacy Applications to the New Enterprise Architecture."[3] THE INFORMATION ARCHITECTURE The overall University Information System architecture can be visualized as a set of layered architectural views. For each layer, the Architecture Team defined a set of guidelines and standards that would help users make informed decisions about information systems acquisitions. The technical architecture was supported on the one hand by the information systems philosophy and set of articulated principles, and on the other hand by an organizational structure that would allow it to evolve through the implementation of projects that complied with its directives. (FIGURE 1 MISSING IN ASCII TEXT VERSION) The UIS was intended to appear to its users as a single set of applications automating the information processing activities they perform. All activities would involve a familiar set of information processing tasks, each with a standard interface. The system would create the illusion that all data was stored and processed at the user's location. The architecture stressed conformance with emerging industry standards for distributed information systems. Such standards facilitate the use of common desktop productivity tools, facilitate electronic data interchange with organizations outside the University, and promote independence from individual vendors. The University Information System would evolve through the implementation of user- initiated projects. User project design teams would present their project proposals to a review committee. Proposals would be described using a pattern language (addressing environment, function, performance and budget issues). The decision to fund projects would be based largely on their adherence to the architectural patterns. This approach borrowed elements from work done at the University of Oregon[4] in the evolution of their physical campus architecture (buildings, roads, etc.). The essential ideas were to: * Identify a set of communally adopted patterns, that would guide the design of everything in the UIS; * Describe all proposed projects using the adopted pattern language; * Make decisions about which projects to fund based on their adherence to the patterns; * Allow the whole architecture to evolve "organically" through implementation of the individual projects; and, * Protect the well being of the architecture and the information systems by an annual diagnosis/evaluation system that will identify which patterns remain valid and which are no longer appropriate. ORGANIZATIONAL STRUCTURE The following diagram shows the original organizational structure that was proposed by the Architecture Team to guide the development and implementation of the architecture and process innovation initiatives. (FIGURE 2 NOT AVAILABLE IN ASCII TEXT VERSION) At the center was the University Information System Advisory Committee (UISAC). Its task was to provide overall guidance, direction, and priority setting. The UISAC would report to the Senior Vice Chancellor for Business and Finance and would be composed of representatives from the entire University community, including academic units, administrative units, the Regional Campuses, Computing and Information Services, the Board of Trustees, and an outsider. It would have the responsibility for creating an enterprise-wide business and information system strategy, and for making policy and funding recommendations for information system and reengineering projects proposed by academic and administrative unit design teams and by the Computing and Information Services area. The UISAC would provide a consistent and coordinated approach to the University's administrative information systems and information technology infrastructure and policies. It would coordinate implementation of the information architecture and business process reengineering initiatives. The Architecture Team also proposed that an "Advanced Technology Group" be formed to investigate and implement emerging technologies, as well as to enhance the technical capabilities of staff in the Computing and Information Services area. The Advanced Technology Group would be charged with developing prototype applications using the newest technologies and techniques. They would select applications that had a potential immediate payoff for the University. The final recommendation of the Architecture Team was that the Computing and Information Services area be charged with the ongoing responsibilities of the Information Architecture and Process Innovation Project, ensuring that the architecture evolves and grows with changing technology and that the process reengineering efforts are related and refined. The final report of the Architecture Team was completed in March 1994, and submitted to the Senior Administrative Staff for review. This group, composed principally of the chief administrative officers of the University, also received six project proposals from end user groups. In an effort to ensure universal buy-in to the envisioned University Information System, the administration created the 14-member Information Architecture Review Committee, composed primarily of faculty, and chaired by the Dean of the Faculty of Arts and Sciences. The Review Committee's charge was to: * Determine the efficacy of implementing the envisioned Information Architecture; * Evaluate six user-proposed projects to determine the degree to which they complied with the architectural guidelines; and, * Determine priorities among the six proposed projects. The Review Committee completed these tasks in about six months. They endorsed the architecture report and recommended funding for some of the projects. Because all of the components proposed in the architecture report had not been implemented, funding recommendations were received by an ad hoc group of senior administrators. This process would become more formalized, as discussed later. The first major project approved under the auspices of the Information Architecture and Process Innovation Project was the procurement system. Upon its formal approval, a project team was identified and charged. Because a pilot business process reengineering effort for procurement had already been conducted as part of the original Architecture Project, the procurement project started with the creation of a Request for Proposal (RFP). To resolve the technical issues associated with the implementation, and to assist in evaluating vendor responses to the RFP, the Procurement Team formed a Technical Advisory Group. The Technical Advisory Group consisted of a mix of end users and technical staff from Computing and Information Services and user offices. As the first large-scale client/server implementation effort at the University, the Procurement Team needed to address and resolve the detailed infrastructure issues identified in the Information Architecture statement. Some examples of these issues include the selection of a relational database management system, the selection of operating system and hardware vendors for application and database servers, the determination of appropriate training programs for both technical staff and end users, and the specific end user ad hoc reporting tools that would be deployed. To resolve such issues, the Technical Advisory Group created a series of working groups patterned after the architectural layers and the advisory groups originally recommended for the University Information System Advisory Committee. The ten working groups addressed the following areas: hardware and operating systems platforms, network and system management, data and document management, applications software, desktop/user interface, message handling, electronic commerce, security, training, and organization. For a brief time, the University administration did convene an oversight group it called the University Information System Advisory Committee. This committee was short-lived, however, and an existing committee, the Information Technology Steering Committee (ITSC), assumed its intended responsibilities. The transition from the UISAC to the ITSC was made to ensure consistency, coordination, and an on-going relationship between the academic and administrative sides of the University. The ITSC was an existing high-level committee charged with setting priorities and allocating funds generated by the student-computing fee. It originally focused on major capital funding allocations in the areas of student computing, faculty computing, instructional media, library automation, and network infrastructure. It was transformed into a planning and executive committee concerned with an annual review and approval of a set of strategic plans for the utilization of information technology throughout the University, as well as an annual review and approval of an updated capital plan to support those strategies. This expanded scope resulted in charging the ITSC with making all major allocations for computer-related acquisitions at the University, and with the responsibility for monitoring the projects implemented under the auspices of the Architecture Project. The Provost assumed the chair of this restructured Information Technology Steering Committee and created a series of subcommittees to advise him on a more detailed level than possible in a single high-level committee. The subcommittees were created to parallel the subcommittee structure in the existing Executive Committee for Academic Computing (ECAC), and to ensure consistency with the ECAC through shared membership of key individuals. They addressed information architecture, faculty access, student access, and networking and library concerns. Finally, the Computing and Information Services area formed the Planning and Advanced Technology group to formulate and articulate a vision for the future of CIS and to explore and demonstrate technology directions for the University. (FIGURE 3 MISSING IN ASCII TEXT VERSION) To summarize the organizational and infrastructure issues, the Architecture Team originally recommended that the University perform a business process reengineering effort before automating any process. This goal remains, but is tempered by reality. While never blindly automating an existing process, it may at times be more prudent to engage in process improvement instead of full-fledged business process reengineering. Originally, the Architecture Team intended to formally identify a set of information processing patterns, define a "pattern language," educate users in the language, and require that all user-initiated projects be described using this common pattern language. This did not happen. Instead, information system designers and planners use the architectural principles and standards statements as a set of guidelines for making systems and priority decisions. From the purist point of view, these two outcomes represent disappointing compromises, in that the original proposals were not completely implemented. Realistically, however, the University changed more fundamentally than anyone could have expected at the start of the project. Organizationally, the Architecture Team originally recommended the creation of a new committee to act as project reviewer and "keeper of the architecture." What evolved over time was far better. The existing Information Technology Steering Committee saw its mission expanded to include the role originally proposed for the University Information System Advisory Committee. Finally, some of the work originally envisioned for the Advanced Technology Group was assumed on an ad hoc basis by the infrastructure working groups to the Procurement Team. This role has now been formally incorporated into the mission of a newly-formed Planning and Advanced Technology group within Computing and Information Services. What has not yet occurred is the formal relationship originally envisioned between the Planning and Advanced Technology group and the Information Technology Steering Committee. STATUS OF PROPOSED PROJECTS This section describes the status of the six proposals originally reviewed by the Information Architecture Review Committee. The proposals were initiated by end users in response to their perceived needs, and were at different levels of complexity and various stages of planning, design, and implementation. They were examined in terms of their compliance with the architectural guidelines and their appropriateness as exemplars of the University Information System. PROCUREMENT PROJECT The information architecture initiative originally identified potential processes to be reengineered in order to validate the Architecture Team's proposed business process reengineering methodology. The existing procurement process was identified as a broken process that suffered from poor technological support and required intensive people and paper procedures. For this pilot reengineering effort, a team of faculty, staff, and administrators, as well as people from outside the University community, examined the existing purchasing process and its related processes, and created a new procurement process. The new process sought to drastically reduce paper, improve turn-around time, enable access to information, streamline purchasing and accounts payable activities, adopt departmental purchasing cards, and free up buyers so they could significantly improve vendor negotiations. Upon approval of the procurement project, a Project Team was formed to implement the reengineered process. The Project Team issued a Request for Proposal (RFP) in November 1994. The Procurement Project evolved into the PRISM (Pitt's Real- time Information System for Management) Project. The PRISM Project encompasses the purchasing and accounts payable functions as well as the general ledger function. The RFP process resulted in the University acquiring Oracle Financials and a site license for the Oracle database and tool products. The PRISM Project Team is currently focused on a July 1997, implementation date. Human Resources The University's existing human resource systems are paper- based, and thepayroll system is over 20 years old. These processes are extremely people and paper intensive. There has always been considerable interest in replacing these systems, but unfortunately, they must yield to some higher priority projects. The current hope is to begin a major reengineering effort within the next year or two that will address both payroll and human resources. The status of the project is on hold. SPACE MANAGEMENT The University suffered from the lack of a central repository of space and asset data, not only to support daily operational needs, but also to support sponsored research indirect cost proposals. Concurrent with the formulation of the Information Architecture and Process Innovation Project recommendations, the University acquired MIT's INSITE software. The Information Architecture Review Committee endorsed its acquisition and the system was implemented in December of 1995. ID CARD SYSTEM A few years ago, the University's ID card was viewed as an obstacle, rather than a resource for campus service providers. A design team was formed to investigate the state of the practice for ID systems currently in use. The ID Card Design Team formulated a set of recommendations in the Spring of 1995 that would implement a "One Card" system for faculty, staff, and students. This card would be enterprise-wide and possess debit functionality, building access, digitized photographs, and electronic validation. The initial decision of the Information Architecture Review Committee was to endorse the project in concept, but to delay its implementation in favor of higher priority projects primarily because of the amount of capital funding necessary. One year later, however, the University outsourced the ID card and most of its functionality to American Express/Special Teams, and have implemented the new ID card in September 1996. CERMIS In the fall of 1995, the Provost appointed a team of faculty and staff to develop a conceptual design for, and assess the feasibility of implementing, a system that would support the access and analysis of integrated curriculum, enrollment, and resource data. The proposed Curriculum Enrollment Resources Management Information System (CERMIS) Project would provide easy to use tools for the academic and administrative areas matching instructional resources to student academic needs. Additionally, it would facilitate planning for academic offerings, analyzing departmental, college-level, and University-wide productivity. A feasibility study was completed in the summer of 1996, and this project has now been merged with another project that will be discussed later. REGISTRATION One of the outcomes of the information architecture initiative was the development of a working prototype now known as PittSTAR (Pitt's Student Advising and Registration System). PittSTAR provides a graphical front-end to the University's character-based legacy student system. Its design was specifically targeted to occasional users of the student system. It is now used by over 200 faculty and advisors in ten schools and four campuses. Over 30% of the University's students were registered via PittSTAR during the Fall Term, 1996. The success and wide interest in PittSTAR lead the University, in the Fall of 1994, to identify a Registration Design Team charged with analyzing the current registration process and developing a direction and recommendations that would enhance the delivery of registration services to the University community. A major assumption at the time was that the existing legacy student system would have to remain in place for the foreseeable future. The Registration Project Team's methodology included discussions with students, faculty, advisors, and departmental and program representatives. Over an eight month period ending in July 1995, the Registration Design Team assembled an interdependent set of recommendations that also addressed the related processes of course scheduling and academic advising. These recommendations encompassed changes in the current registration process, enhancements to current legacy student system software, and the introduction of new delivery technologies. The major components of the proposed solution included the implementation of automated course scheduling software, expanded access to course and student registration information, expansion of PittSTAR to provide extensive query information and also permit on- line student self-registration, and telephone registration. This project was approved and limited funding was available for continued development of PittSTAR. THE SOLARS PROJECT An additional factor that changed the focus of the Registration and CERMIS proposals was the year 2000 problem. A detailed analysis of the existing legacy software resulted in the conclusion that, like many other institutions, Pitt's current student system would be dramatically affected. Given the financial resources estimated to fix the year 2000 problem, coupled with the projected costs for the Registration and CERMIS projects, the authors were asked to evaluate the possibility of replacing the existing student system with one that was compliant with the information architecture. The authors completed a feasibility study in July 1996, including a preliminary review of potential vendors. In November 1996, the Chancellor formally approved the ITSC's recommendation for funding for the Student On-Line Academic Resource System (SOLARS) Project. This project combined the CERMIS data warehouse initiative, the continued development and distribution of PittSTAR, and the acquisition and implementation of a new integrated student system. With SOLARS, the University will acquire a system that will not only handle dates for the 21st century but also improve functionality and take advantage of important technological advancements. Central to the project will be a data warehouse surrounded by application packages to both feed information to, and extract information from, the data warehouse. When fully implemented, this project will result in significant changes in the way student services are delivered both in central administrative offices and in departments and academic centers. For example, as the University gains on-line access to information, the need for paper reports to distribute information will decrease. Students might choose to register on-line, and many of the redundant and time-consuming steps required to prepare course-related information will be reduced. Automated room scheduling will allocate classroom space more efficiently and systematically, enabling increased classroom utilization. SUMMARY The Information Architecture and Process Innovation Project was initiated to (1) propose an architecture for the University Information System (UIS) that would provide a framework for making decisions about information systems and for improving the UIS in the future, (2) establish a methodology for business process reengineering using the UIS, and (3) develop a plan for migrating from the current systems to the envisioned UIS. All of the recommendations of the Architecture Team have not been fully implemented as originally conceived. However, the architecture greatly facilitated a series of difficult resource, priority, and technological decisions, and continues to provide the blueprint for developing an integrated set of information services, processes, and technologies at the University of Pittsburgh. It also initiated an effective and cohesive organizational structure for addressing the challenges of managing the implementation of an enterprise-wide information system. It enables significant efficiencies in business and service processes, and facilitates informed decisions concerning information technology expenditures and acquisitions. Implementation of the architecture does not adhere to a traditional master plan approach, but rather grows the University Information System from the ground up. In this approach, the enterprise-wide architecture evolves as user- proposed projects are developed in adherence to the guidelines, standards, and information processing patterns articulated in the architecture. The organizational structures created to support the architecture and to address the prerequisite infrastructure issues continue to evolve. ENDNOTES: [1] James G. Williams, Dennis J. DeSantis, Nicholas C. Laudato, Maureen R. Moroney, and Michael S. Rissman, "_Report of the Information Architecture and Process Innovation Project--Reshaping the Enterprise: An Overview_" CAUSE Information Resources Library, Available at URL: http://www.cause.org/information-resources/ir- library/abstracts/csd1098.html [2] Nicholas C. Laudato and Dennis J. DeSantis, "Reshaping the Enterprise Through Information Architecture and Process Reengineering" _CAUSE/EFFECT_, Winter 1995, Available at URL: http://www.cause.org/cause-effect/cem95/cem954.html [3] Nicholas C. Laudato and Dennis J. DeSantis, "You CAN Teach an Old Dog New Tricks: Extending Legacy Applications to the New Enterprise Architecture" Presentation at CAUSE 1995 Annual Conference, Available at URL: http://www.cause.org/information-resources/ir- library/abstracts/cnc9505.html [4] Christopher Alexander. _The Oregon Experiment_. (New York: Oxford University Press, 1975) Page 10