Professional:| books | classes | data blueprint | opportunities | papers | projects | publications | research | xml | where

      Personal: affiliations | contact | creativity | dogs new clothes | home | links | michael gee | mp3s
      | philosophies | search | website

      website paiken:research

          Data Reenginering Case Study

      Data Reengineering Project Context

      by Peter Aiken & Bill Girling

      The project is an integrated human resource information system. It is relatively common situation. Break the shrink wrap on the new multi-million dollar client server application software and the directions say something like 'plug in your database here.' The problem is that your legacy database isn't one, its two, and they reside on two different hardware platforms. One - the pay system is 10 years old and it is physically implemented as four very large VSAM files. The personnel system - approaching 20 years of service - is a homegrown, net-work-style Unisys database. Two types of data structures, two operating systems, two hardware platforms, two computing eras, and, as usual, two sets of deficient documentation. The shrink-wrapped 'Commercial off the Shelf' solution assumes that the new database goal is to replace the existing database. It isn't - the reason the systems are being replaced because they don't meet current user information requirements. So how do you go about the process of engineering the new integrated database to plug into your new shrink-wrap software?

      This situation was faced by the Commonwealth of Virginia (CoV) as it attempted to implement its new PeopleSoft-based system. When fully implemented (system prototyping began in early 1997), the project will represent a number of landmarks. It will be one of the largest government-based PeopleSoft implementations to date. It is the Commonwealth's first state-wide client server application. It represents an innovative industry-academic partnership. And, it is a classic application of data reengineering. The remainder of this article describes the process of reengineering the legacy data into an integrated database. The project was designed to meet current and future CoV information requirements. Other data reengineering goals include development of data migration plans for physically evolving the data and documenting business rules capable of influencing the related process reengineering efforts aimed at streamlining tedious processes associated with the legacy systems.

      Conceptually, the project began in 1991 in response to growing inadequacies with the existing, independently operated, personnel and payroll systems. Decades old technology and physically separated application environments resulted in inefficient and untimely responses to user needs, significant redundant data entry and data reconciliation requirements, high maintenance and production costs, and concerns about securing and retaining technical staff required to support the systems.

      After considerable self study, a big six consulting firm was hired in 1994 to coalesce the system functional specifications and in late 1995 the procurement effort began. In September 1996, the CoV contracted with PeopleSoft to purchase its government time and attendance, pay, benefits and human resource modules. Concurrently, Oracle was selected as the DBMS. With procurement complete, implementation issues moved to the forefront.

      Public sector funding pressures and political sensitivity to avoid massive government program failures created a situation were credible progress must be achieved rapidly. With systems development economics putting high price tags on new information systems development, organizations are increasingly turning to reengineering as a more affordable means of upgrading their existing information systems base by leveraging their legacy system investment and facilitating migration to replacement applications. It is estimated that the reengineering market will be $52 billion in 1997, with $40 billion alone to be spent on information systems reengineering. Reengineering can be a less expensive alternative to system regeneration (zero-based replacement) because it applies analysis techniques to recovering existing system metadata. Thus, reverse engineering enables reengineering.

      Data reengineering is a relatively new formulation of systems reengineering technologies developed to facilitate rapid, effective, and cost efficient database engineering required by aggressive project schedules. Interest is growing in the area of data reengineering, this variant was originally developed for use as part of the Department of Defense's Corporate Information Management Initiative. Data reengineering is enjoying wider application in response to industry demands for the benefits of a more data centered approach to systems reengineering. Data reengineering permits the project to be developed as a flexible, data focused system that can serve the CoV's current and future requirements. Additionally, rapid reengineering can reduce the time spent running parallel systems during system transition.

      Data reengineering is a structured application redevelopment technique involving analysis of the existing data stores, model construction, and prototyped solutions prior to actual system implementation. Structured techniques provide data engineers with tools enabling them to comprehend certain otherwise unfathomable situations by: allowing the form of the problem to guide the form of the solution; providing guidance for problem decomposition; featuring a variety of tools simplifying system understanding; offering a set of strategies for evolving design solutions; providing criteria for evaluating solution quality; and facilitating organizational knowledge development. Structured techniques, near-standardized modeling representations, and CASE tool support are key concepts that make data reengineering economically viable.

      Figure 1 illustrates the project goals were to analyze the existing data stores in order to identify their physical implementation. The overall approach was to de-velop models of the two existing databases and representing each of them logical as data models using a CASE tool. From these we created logical system models that are free from implementation details. From these the existing system requirements were identified and compared to the the project information requirements. The models were combined, normalized and compared with PeopleSoft Version 4 and the Version 6 supplied as examples. The 'to be' logical data model was derived and the case tool generates the Oracle SQL to physically implement the new the project database. The new database is prototyped for the users, passing through several iterations as it approaches acceptability.



      Figure 1. Project data reengineering project overview.

      As shown in Figure 2, the original data reengineering project plan considered: the existing Personnel Management Information System (PMIS) and Commonwealth Integrated Pay and Personnel System (CIPPS) databases, a copy of the database schema implemented at another CoV university using PeopleSoft software (Version 4), and the PeopleSoft database samples delivered with its Version 5 & 6 - as the primary sources of evidence. (Note: the project plan was also implemented based-on non-technical considerations such as state purchasing regulations and the availability of certain information.)



      Figure 2 - High level data reengineering project plan.


      Navigate from here: returning to the project home page, or jump to another part of the case study (executive summary, project context, sample reverse engineering outcomes, reengineering results: models and business rules, CASE tool usage, illustration index, our acknowledgements , or references) - or jump to Peter Aiken's home page, download some reengineering articles, or access other reengineering links.

      This page and all web site contents were last updated and are copyright
      8/9/07 and previous years by Peter Aiken - all rights reserved.