Relational Data Base Migration

Overview

Symptoms

A migration to a relational database management system (RDBMS) is typically driven by a larger business scenario. However, enough organizations are working towards this objective that it warrants a separate scenario. Note that this scenario does not support a "quick and dirty" conversion to relational database.

Migration implies that the proper design effort is completed prior to implementing a relational database base system. Not taking this approach will result in a system that has performance, reliability and user related problems and will eventually require re-engineering at some point in the future.

Symptoms of this scenario include:

· Existing flat file, hierarchical or network database system requires a move to relational database

· User requires a more flexible view of database on changing business requirements

· Management has dictated that systems will be migrated to a relational database

Requirements

The requirements for the relational database migration scenario are identified below.

· Migrate application to relational database in a source to source conversion (i.e. no I-CASE or multi-system integration involved)

· Existing data structures must move to relational database while baseline business functions remain intact

· Data definitions and data access logic within the code must be modified to access new relational design

· Physical data structures must be reconciled, rationalized, normalized and migrated to support new system design

· Negative user impact must be minimized necessitating a code based migration

RDBMS Planning Considerations

The relational database migration scenario is designed to embed a new database design, along with required source code modifications, into an existing system. The goal within this limited scope scenario is to create a durable design for performance, integrity and user accessibility without forcing the system to be modified in other ways. Architectural changes are limited to data representations. Source code changes are limited to Positioning preparatory tasks to facilitate access logic changes.

This approach may appear to have more tasks involved than required. Remembering that this is not a conversion, but a data architecture change with far reaching impact, should help cost justify this approach with IS management. A bad relational database design will impact performance, accessibility and the overall credibility of the IS organization. Using this scenario to migrate an application to relational database (or similar relational database) will prevent this from occurring.

Build RDBMS Migration Plan

Develop Assessment Proposal

Objective setting/proposal development

Complete Executive Planning

Position System(s) Under Option Strategy Matrix

Note: The following step is where options/hypotheses are articulated for systems being assessed. This scenario is restricted to a code based migration option that involves no top-down design, no integration and model based generation.

Develop Inventory/Analysis Objectives

Establish Assessment Task List

Note: The following steps are the actual Inventory/Analysis steps to be used in this assessment.

Finalize Environmental Analysis Work Plan

Finalize Process Flow Analysis Work Estimates

Note: All steps of data definition analysis, except "assess multi-system data definition usage", are performed.

Finalize Data Definition Analysis Work Estimates

Note: Only the "document batch and on-line system" and the "identify use of non-standard technologies" steps are performed in the general system architecture assessment. DFD flows will be used to address required data access changes.

Finalize General System Architecture Work Plan

Note: Current user interfaces are not to be redesigned.

Finalize Data Access Layer Assessment Plan

Finalize Subject Area Analysis Work Plan

Note: Perform IS infrastructure analysis to assess testing maturity and understanding of relational technology.

Finalize IS Infrastructure Analysis Plan

Note: A single hypothesis scenario requires minimal effort to summarize assessment findings.

Finalize Feasibility Analysis Plan

Note: Interim plan should include stabilizing high risk programs prior to migration and rationalizing all data definitions - see assessment steps that follow in this scenario.

Finalize Interim Planning Task Effort

Finalize Strategic Redevelopment Work Effort

Develop Inventory/Analysis Work Plan

Complete Inventory/Analysis Assessment Proposal

Assess IS Application Infrastructure

Environmental analysis

Note: The following steps are performed for each system input to this assessment.

Identify/Categorize Physical System Components

Inventory/Cross Reference Mainframe Components

Review/Refine Environmental Analysis Results

Produce Environmental Counts and Scores

Process flow analysis

Note: Process flow analysis to pinpoint high risk candidates that will undergo relational database based access logic changes.

Verify and Finalize System/Sub-System Groupings

Perform Process Flow Analysis

Note: Only one of the following two steps is executed based on tool availability.

Record Manually Derived Process Flow Metrics

Record Tool Derived Process Flow Metrics

Review Process Flow Analysis Results

Note: The following step is optional based on interest of application support teams - large projects may skip this step.

Produce Detail Program Analysis Listings

Data definition analysis

Note: This analysis focuses on I/O groups linked to files or databases that will be converted to relational structures.

Perform System-Wide Data Definition Analysis

Assign Data Definition Metric Counts

Calculate Data Definition Metric Scores

Produce Data Definition Narrative Summary

Review Data Definition Analysis Results

Note: Perform the following step if multiple standalone systems involved.

Assess Multi-System Data Definition Usage

General system architecture assessment

Note: Limit analysis to the following steps.

Document Batch System Information Flow

Document On-Line System Information Flow

Note: The following step is a required component of this analysis to determine special interface routines that must be built for shared files or databases that must retain original structure for systems outside the scope of this analysis.

Document Related System Interfaces

Identify Use of Non-Standard Technologies

Data access layer assessment

Note: The following steps are performed for each system input to this assessment.

Finalize Database/Data File Inventory

Assess Physical Data Usage Redundancy

Determine Data Integration Levels

Rate Data Architecture Conformance

Summarize Data Architecture Analysis

Subject Area/Entity Type Analysis

Derive Current System Subject Areas

Note: Bottom-up model is the basis for the new relational model.

Prepare/Load Current System Entity Types

Derive Existing Entity Relationship Diagram

Create Subject Area Analysis Summary

IS infrastructure analysis

Note: The following steps are performed for each system input to this assessment.

Determine Staff Experience/Skill Ratings

Determine Testing Skill/Maturity Ratings

Determine IS Development Tool Ratings

Perform Feasibility Analysis

Assessment Integration & Feasibility Analysis

Note: The following two steps summarize assessment findings.

Develop Application Summary Metrics

Develop Assessment Findings Report

Create RDBMS Migration Plan

Create interim support plan

Create Interim Plan Outline

Correlate Analysis Requirements/Findings

Identify Positioning Tasks/Cost Analysis

Develop Pilot/Proof of Concept Plan

Note: The "finalize interim support work plan step" refers to select work plan steps of Positioning - in this case select code stabilization and data name rationalization steps.

Finalize Interim Support Work Plan

Note: Application staging estimates must be developed for each of the subsequent Positioning steps outlined below.

Finalize Application Staging Plan

Note: Flaw analysis & removal and restructuring are performed on highly flawed/poorly structured modules impacted by the new database - target large, edit and/or update modules.

Finalize Flaw Analysis & Removal Work Plan

Determine Restructuring Work Effort

Finalize Design Improvement Work Effort

Assess Data Definition Rationalization Scope

Finalize Data Definition Rationalization Plan

Note: Validation step below is used to develop an estimate to validate each of the Positioning steps listed above.

Establish Validation Criteria & Plan

Identify Support Structure Adjustments

Integrate Interim Plan/Strategic Objectives

Create strategic redevelopment plan

Build Strategic Redevelopment Plan

Develop Redevelopment Cost/Benefit

Note: The following steps identify the work tasks and associated estimates required to complete the above two planning steps.

Finalize Logical Data Analysis Work Plan

Finalize Physical Data Design/Migration Plan

Note: Programs impacted by database changes must have logic modifications applied. While not a formal Comsys-TIM redevelopment task, the phase at the end of this scenario to accommodates these requirements. Each impacted program should have hours assigned for modification as indicated in the last phase of this scenario.

Finalize Redevelopment Work Plan

Prepare Systems for RDBMS Migration Effort

Stabilize Application Code

Note: Apply selected stabilization steps based on findings of the assessment effort.

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Flaw analysis & removal

Produce Detailed Flaw Analysis Reports

Note: Enter/execute following steps only as required

Eliminate Runaway Logic Paths

Assess and Eliminate Dead Code

Review/Eliminate Active Exits

Review/Eliminate Looping Range Violations

Review and Eliminate Recursive Performs

Review and Eliminate ALTER Logic

Perform Quality Review and Finalize Changes

Code restructuring

Create Detail Restructuring Analysis

Perform Program Structuring Adjustments

Establish Restructuring Parameters

Perform Source Code Restructuring

Design review & improvement

Optimize Program Size

Optimize Procedure/Paragraph Size

Eliminate Logic Spikes/Reduce Complexity

Review and Correct Switch Variables

Review and Improve Procedure Names

Review/Refine Table Handling Techniques

Finalize Design Review/Improvement Task

Validation

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Validate Modified Programs

Obtain Validation Sign-Off

Standardize System-Wide Data Definitions

Note: Apply selected data definition standardization steps based on findings of the assessment effort.

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Data name rationalization

Setup Data Name Rationalization Libraries

Review Record Grouping Analysis

Note: Limit rationalization effort to selected I/O records impacted by relational migration scenario.

Build Composite Record Definitions

Apply Descriptive Composite Names

Propagate Composite Record Definitions

Note: Secondary (program level) name rationalization is omitted from this scenario to reduce work effort/validation time.

Reconcile DNR Source with Production

Validate/Implement Rationalized Code

Validation

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Validate Modified Programs

Obtain Validation Sign-Off

Perform RDBMS Migration

Finalize Integrated Data Architecture

Logical data analysis

Note: The following steps utilize a single, bottom-up derived model - no model merge is required.

Load/Merge Bottom-Up ER Model(s)

Note: The following step is used to integrate existing system data usage.

Refine Bottom-Up Derived ER Model

Normalize Merged ER Model

Note: If the modeling tool generates SQL, utilize these features and capture the generated SQL for use in the subsequent code adjustment phase.

Review and Sign-Off Normalized Data Model

Finalize Physical Design/Migration

Physical Data Analysis & Migration

Finalize Physical Data Model

Note: Data migration under the integration scenario includes a purification step that is highly recommended since it can be applied as a byproduct of the migration itself.

Perform Physical Data Migration Process

Gain Physical Design/Migration Plan Sign-Off

Perform Source Code Redesign/Changes

Source code data structure access modifications

Note: The working assumption here is that baseline functions are to remain intact, while isolated I/O logic will be modified to utilize GUI and relational access logic. Follow analysis guidelines specifically pointing to relational data base or client/server migration.

Build Reconciliation/Re-Aggregation Analysis

Note: The following step supports reconciliation of redundant logic and creation of I/O logic sub-routines including isolation of data structure and screen/report access related logic. Use this concept and specific design requirements as a guide to using this step.

Eliminate/Reconcile Redundant Processes

Note: Step below supports the creation of new routines comprised of source logic from existing programs. Follow analysis guidelines specifically pointing to relational data base or client/server migration.

Re-Aggregate Segregated Functions