Data Reengineering: Reengineering Results

by Peter Aiken & Bill Girling

The reverse engineering analysis of 'Classic PMIS' also revealed the existence of several business rules. For example consider how relationships documented by the four entities comprising the 'Classic PMIS' model view (Figure 5) illustrate how the legacy data structure was engineered to enforce the following business rules:

• BR1) Zero, one, or more EMPLOYEES can be associated with one PERSON;
• BR2) Zero, one, or more EMPLOYEES can be associated with one JOB CLASS;
• BR3) Zero, one, or more EMPLOYEES can be associated with one POSITION; and
• BR4) One or more POSITIONS can be associated with one JOB CLASS.
  
  

The organizational implications of these business rules are fundamental to the design of the new system and must be understood by the engineering and key specialists during the reengineering or the risk of fundamental design mistakes is high. As discovered, the business rules were also documented in the CASE tool as shown in Figure 6.

The business rules proved directly useful to the integrated business process reengineering occurring as part of the implementation. Subsequent analysis for the other PMIS model components was more involved but resulted in the model shown as Figure 7.

Development of the CIPPS data model required a different form of analysis. CIPPS is an integrated pay and personnel system implemented solely as a pay system. All data structures are fully implemented but only the pay functions of the system are used. At run time, four very large VSAM files are translated by a proprietary Dun & Bradstreet product called "Millennium" into what appear to the application programs as database tables. The VSAM files are redefined into approximately 350 different tables that are available to the CIPPS program modules. The vendor made provisions for user extensions to the system to be added through a series of utility files many of which were added batch programs or as general ledger routine interfaces (Figure 4). For the reverse engineering analysis, entities were added to the functional decomposition component/model view i.e., batch program , leave, general ledger, or information maintenance subsystem (for either company, employee, or system information).

Once the entire logical "as is" model was developed, we began to develop the logical "to be" model. We developed a series of matrices such as shown in Figure 9. Each existing logical entity was evaluated for possible use against the information requirements specified for the project. For each entity, in conjunction with the key specialists we developed an answer to the question: "Is this a business thing (person, place, or thing) about which the project needs to create, read, update, or delete information?" Our initial hypotheses were validated (or proven incorrect) using model refinement/validation session with the key specialists and the final result was the logical "to be" the project data model.

As we developed candidate versions of the logical data model, we used the CASE-tool features to generate the SQL required to specify an Oracle database capable of implementing the "to be" model. As these models were implemented, they were quickly populated with test data and attached to the PeopleSoft modules. In this manner the end users could test the effects of various design changes in near real time. Populating the tables with real data enabled us to debug the proposed data migration procedures in advance. Users were able to catch data anomaly errors prior to actual implementation. In addition, data reengineering has also provided additional information about the PeopleSoft internals that was not provided as part of the system documentation that has been useful in the reimplementation.