Figure 3 indicates the project team composition and roles. A class of data engineers was recruited through the University's Information Systems Research Institute to work on the project as part of their graduate curricula in information systems in the School of Business. In addition, participation by key specialists (technical and non-technical end users for each system) was required in order to provide functional user and technical perspectives. Weekly, the data engineers were configured into teams to accomplish one or more parts of the project plan. Sometimes the teams required interaction with PMIS and CIPPS key specialists. Information was often transferred during formal and informal model refinement and validation sessions.
Figure 3 - Data reengineering project team roles.
Comparing the PeopleSoft version 4 data model implementation with the out of the box version 6, provided clear indications of how the default PeopleSoft database had evolved growing from about one thousand tables to more than fifteen hundred as the underlying model was refined and the functionality was increased. But comparing these to the Commonwealth's information requirements was like comparing apples to oranges. In order to develop a specific means of comparison it was necessary to develop logical representations of the information requirements that were independent of the physical implementation details. The data models for PMIS and CIPPS had to be developed using data reverse engineering techniques. To structure system metadata, the project teams developed a PMIS and CIPPS functional decomposition (Figure 4). Data engineering teams popu-lated the data model by developing data models of the entities as implemented in each decomposition. Modeling the two systems was challenging.
Figure 4 - Functional decompositions of CIPPS and PMIS.
The core PMIS functionality was developed by the Commonwealth in 1978 to maintain information about four primary types of information: job positions, employees, job classifications, and persons involved in the system. In Figure 4 the area labeled 'Classic PMIS,' represents the core of the original system. In the 20 years since, PMIS functionality has been expanded beyond the original requirements to include functions not designed into the original system: a minority and female talent bank; a wage employee subsystem; benefits enrollment system; incentive pay; and CoV-wide position reporting.
System development was overseen by system programmers of which only one still remains available for consultation. Developed before the implementation of the relational model, the Unisys network data structure doesn't directly translate to a relational structure. There are no common keys, instead data associations are maintained using linked lists. System documentation indicated the nature of the linked information but the actual physical implementation of the links was handled internally.
Figure 5 - Four entities comprise the 'Classic PMIS' model view.
Figure 6 - Business rules maintained using the CASE tool facility.
Reverse engineering 'Classic PMIS' revealed, not surprisingly, four primary entities shown in Figure 5: PERSON, POSITION, EMPLOYEE and CLASS. These became the first four entities and respective relationships entered into the CASE tool. The attribute names were compiled by running a Unisys utility and then using macro-based cutting and pasting into the CASE tool. Entity definitions were added but during the initial stage the data engineers did not need to understand the meanings behind each individual attribute.
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.