A Requirement-Based Approach to Data Modeling and Re-engineering Alice H. Muntz Christian T. Ramiller Hughes Information Technology Corporation HughesInformation Technology Corporation MS SUS64lC410 MS SClS64lC41O PO Box 929 19 PO Box 929 19 Los Angeles, CA 90009 Los Angeles, CA 90009 ahmuntz8hac2arpa.hac.com 1. Introduction Abstract Re-engineering is the process of analyzing, upgrading, This paper reports on the managerialexperience, and integrating enterpriseinformation systemsto meet the technical approach, and lessonslearned from re- expandedoperating requirementsof the present, as well as engineering eight departmental large-scale to prepare a sound base for effectively meeting future information systems. The driving strategic needs. In this paper, we report our experience, key objective of each project was to migrate these technical approach,and lessonslearned from applying our systems into a set of enterprise-wide systems, framework ([MH94], [AHR94], [AHR93], [HI93a], which incorporate current and future [HI93b]) to eight large scale legacy information systems, requirements, drastically reduce operational and each containing several million lines of code, and maintenance cost, and facilitate common thousandsof data elements. understandings among stakeholders(i.e., policy Our requirement-basedre-engineering approach differs maker, high-level management, IS from ([P&B94], [HDA87], [M&M90], [M&S89], developer/maintainer/end-users). A logical data [NEK94], [MNBBK94],[HCTJ93]) that we couple our model , which contains requirements, rules, extended entity-relationship modeling methodology and physical data representation as well as logical tools with model integration processes to produce a data object, clearly documents the baseline data normalized data model. In a re-engineered data model, requirements implemented by the legacy system the physical data objects, pertaining to the physical and is crucial to achieve this strategic goal. schemas,link to the relevant logical data objects, external Re-engineering products are captured in the data objects,business requirements, and systemrules. dictionaries of a CASE tool (i.e., in the form of a business process decomposition hierarchy, as-is Why Requirement-Based Data Modeling and Re- data model, normalized logical data model, and engineering? linkages among data objects) and are supplemented with traceability matrices in A requirement-basedre-engineering approach should be spreadsheets.The re-engineered data products used when the information infrastructure of an enterprise are used as follows: (1) migration of the legacy is out-of-control and is not meeting its goals. Typical databases to relational database management symptomsare: systems, (2) automatically generation of people can’t share or integrate data across the databasesand applications for migration from enterprise mainframes to client-server, (3) enterprise data data can’t be combined from multiple sources standardization, (4) integration of disparate the information people need is in a system information systems, (5) re-documentation, (6) somewhere else, not accessibleto them data quality assessmentand assurance,and (7) the Information System (IS) staff can’t support the baseline specifications for future systems. existing infrastructure becauseof obsolete platforms or programs designed, built, and supported by one person Pemdssion to copy withoutfee all or part of this material ir grantedprovided that the copies are not made or distributedfor direct commercial advantage, the VLDB the IS department charges are skyrocketing, but copyright notice and the title of the publication and it3 date appear, and notice is people still can’t get the information they need (what) given that copying b by permission of tk Very Large DotaBare Endowment. To copy otherwise, or to republish, requires a fee on&or special permission from the to conduct the business;when they want it, how they EJt&wment. want it, or in the form they want it Proceedings of the 20th VLDB Conference Santiago, the information systems don’t support enterprise Chile, 1994 strategicplanning or tactical decision support information and application requirements have not been mappedto businessfunctions 643 IS Development Life Cycle Information Technology (IT) Task Use of Requirement-Based Re-Engineering Products I BusinessRequirements * Functional Economic Analysis B understanding requirements of as-is business processes l BusinessProcess Improvement /data models and how IS supportsusers and business l Enterprise Data Architecture . inventory of baseline requirements implemented in the * EnterpriseData Model current IS l Cross-functional Model . composition of the logical data dimension and tbe physical Integration data dimension of enterprise data architecture and l EnterpriseModel Integration enterprisedata model l Data Element Standardization m integration of tactical and operational data models among l EnterpriseData Warehouse businessfunctions l EnterpriseData Repository . integration of strategic, tactical, and operational data modelsfor all businessfunctions . uniform name for the samedata object to facilitate reuse * same name, meaning, and usage for the sharable data instancesand objects . Information system l Enterprise IT Consolidation identification of duplicating or similar databasesfor the Requirements Planning samebusiness functions l EnterpriseIS Security l understanding requirements of as-is business processes /data modelsand how IS supportsusers and business Software/Database l Forward Engineering l elimination of obsolete requirements, modification of Requirements changedrequirements, and addition of new requirements Preliminary Design l data objects formulated from data usage,processing rules, Detail Design l Object Engineering attributes, and entities of logical data model l data quality requirementsrepresented in the re-engineered logical data model l Data Quality Engineering Implementation l DatabaseGeneration l databasesand tables automatically generated by CASE tools using re-engineereddata models l ScreenGeneration l screen/reportdesign and implementation via CASE tools l Report Generation using re-engineereddata models Unit Test l Data Migration l linkage between the legacy data elements to the as-is Integration normalized data model used by the data extraction Program l linkage between the to-be data element to the as-is normalized data model used to store the extracted legacy data to the to-be databasetables l Data Quality Assurance l data quality requirements specified in the re-engineered data model l Data Administration l data requirements specified in the re-engineered data model l Training l understandingof requirementsand how tbe IS implements I l Maintenance I the requirements Table 1. Use of Requirement-Based Re-Engineering Products new application architecture and technology l modifying one application causes errors, aborts, and / infrastructure. or erroneous information in a different application As a part of our re-engineering approach, we resolve data A requirement-based data modeling and re-engineering conflicts (e.g., synonyms, homonyms) during data approach should be used to re-document or map business modeling and model integration. In section two, we requirements, functional requirements, and data describe our approach to identify data conflicts and requirements to architecture, design, and implementation. classify data conflicts. Depending on the scope of the re- As depicted in Table 1, re-engineered data models enable engineering effort, various levels of integration will occur. identification of obsolete portions of applications, We developed an integration taxonomy to guide our outstanding unfulfilled requirements, applications that integration process for data modeling and re-engineering require changes or consolidation based on new functional legacy information systems. Sections 3 describes this requirements to meet current and future business needs. integration taxonomy. Section 4 describes our The re-engineered design will provide a basis for requirement-based data modeling approach. Section 5 developing a plan to migrate reusable applications to the uses an example to illustrate our model integration 644 approach. Finally, in the last section, we summarize Synonyms are data element names which are different lessonslearned from these re-engineering experiences. but which are used to describe the same thing in the various systems. The “same thing” refers to (a) the same 2. Five Data Conflicts Types critical attribute of a real-world thing, or (b) the same real-world thing. An example is shown in Figure 1. Here When systems are to be re-engineered or consolidated, the term ACTIVITY within the pay system is used to functional and data conflicts, and data duplication need identify what is called a UNIT or ORGANIZATION special attention, to determine the impact of selecting one within the personnel system.This conflict was uncovered system’simplementation over another. Data conflicts fall by noting the similarity in associations as well as in into one of 5 general types. definition. Personnel Data MODEL I Pay MODEL ORGANIZATION_ UNIT _ POSITION ORGANIZATION- ACTIVITY - POSITION ORGANIZATION-- any groupof individualsthat servea ACTIVITY- an organization identified by ths major daiment code, for which 1 functionwithin the Enterprise. grouping of employees works. UNIT-- an organizationalsub-group identified by the personnelaccounting symbol authorization number to track the ownerof a positionto whichemployees will