Model Driven Client/Server Migration

Overview

Symptoms

The client/server migration approach outlined in this scenario augments new object based and event driven design efforts. It also extracts value from existing systems as a key component of the process. Finally, it addresses a phased strategy for the replacement of multiple systems and sub-systems.

This approach is used because recreating complex, transaction oriented systems from scratch is prohibitive. Scenario symptoms for the model driven client/server migration approach are summarized below:

· There is a need to reduce mainframe cycles and hardware costs by moving systems off of host environment

· Users require improved accessibility of data through distribution of presentation, data and functions

· IS wants to streamline maintenance efforts based on an object oriented, event driven development approach

· Requires redesigned of data and functionality for one or more core systems using state-of-the-art, model driven design

· Enhanced adaptability for ongoing user requirements

· Current development and maintenance paradigm is unacceptable long-term

Requirements

The client/server migration approach outlined in this scenario augments new design and development efforts. It also extracts value from existing systems as a key component of the process. Finally, it addresses a phased strategy for the replacement of multiple systems and sub-systems. This approach is used because recreating complex, transaction oriented systems from scratch is prohibitive.

Model driven, client/server migration requirements include:

· Business driven view of an overall architecture that accommodates replacement of multiple core systems

· State-of-the-art technical architecture to support multiple and diverse user base

· Commitment to object based and event driven design and development

· Ability to recast existing data in an integrated relational data architecture

· Ability to capture, reuse and transition from legacy business rules into new business and data architecture

· Controlled migration from the current mainframe to target server environment

· Sophisticated communication software to link servers, including mainframes and workstations

Model Driven Client/Server Migration Planning

The following recommendations are based on the premise that migrating to client/server is not unlike migrating to any other new architecture. While the target may differ to a great degree, the means of achieving that target is similar. Defining a target architecture is critical. Development methodologies and tools are just catching up with the demand for client/server projects. This scenario uses an object oriented, event driven target paradigm. Comsys-TIM tasks referenced in this scenario define supporting tools.

The following identifies preparatory considerations to be reviewed prior to entering this scenario.

· Apply the IE, Information Strategy Planning (or similar) process to define strategic information requirements

· Determine client/server development techniques, including object, event and business rule modeling, to be used on this project

· Review concept of using a derived data model as the baseline from which to begin object derivation process - see object derivation analysis task in Transformation

· Keep data model synchronized with object model and legacy environment throughout design process as basis for implementing system on top of a relational database (RDBMS)

· Apply a client/server methodology where available to define analysis, design and development techniques

· Review new architecture with users and application management

· Investigate use of LTM as a transition management facility - this is essentially a requirement for event and business rule derivation analysis later in this task

· Address critical cross functional integration issues as part of the planning, analysis and design process

· Determine transition issues for large or diverse cross sections of the legacy environment being replaced

Note: If parts of systems serving as baseline for rule extraction are to remain intact, LTM and post-design re-aggregation are required - see business rule derivation steps in this scenario.

· Assess and select model based development tools to support development based on tool guidelines within each step of the model driven phases of this scenario

· Verify that this is not a GUI (front-end) development or code based migration effort (if either of these are required/desired, proceed to one of those scenarios)

Build Client/Server 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 are articulated for systems being assessed. This typically includes options to capture and integrate bottom-up and top-down views. A pure bottom-up approach is not recommended - but feasible. Multi-system integration is assumed, but obviously not a requirement.
· Bottom-up/top-down integration of existing stand alone systems
· Bottom-up only approach
· Build from scratch (not typically practical or cost effective)

Develop Inventory/Analysis Objectives

Establish Assessment Task List

Note: The following steps are the actual Inventory/Analysis steps to be used in this assessment - assume each system will undergo analysis.

Finalize Environmental Analysis Work Plan

Finalize Process Flow Analysis Work Estimates

Note: All steps of data definition analysis, including assess multi-system data definition usage, will be performed.

Finalize Data Definition Analysis Work Estimates

Note: Assume all steps of the architectural assessment are to be performed.

Finalize General System Architecture Work Plan

Finalize Presentation Layer Analysis Plan

Finalize Data Access Layer Assessment Plan

Create Architecture Summary Work Plan

Note: User backlog analysis should target overlapping requests to provide integrated/distributed views of data among systems - these are strategic requirements.

Finalize User Backlog Analysis Plan

Note: The next four steps focus on comparing bottom-up views of current systems to top-down models based on target client/server architecture. Integrated view is created as final step.

Finalize Subject Area Analysis Work Plan

Finalize Function Hierarchy Analysis Plan

Note: While current system data model extraction and functional decomposition are required planning steps as input to planning, dependency modeling and matrix development, while highly recommended, are optional.

Finalize Function Dependency Analysis Plan

Finalize Function/Entity Type Analysis Plan

Note: Perform IS infrastructure analysis on all application areas supporting all systems being assessed. Determine skills with server development, testing, object/event modeling, etc.

Finalize IS Infrastructure Analysis Plan

Note: Feasibility analysis selects a "best" and most cost effective approach.

Finalize Feasibility Analysis Plan

Note: Interim plan should focus on streamlining systems for client/server environment based on assessment findings.

Finalize Interim Planning Task Effort

Note: The redevelopment plan involves a top-down/bottom-up integration effort based on selected hypothesis.

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

Identify/Categorize External System Components

Inventory/Cross Reference Mainframe Components

Review/Refine Environmental Analysis Results

Produce Environmental Counts and Scores

Produce Environmental Analysis Narrative Summary

Process flow analysis

Note: Process flow analysis is performed for each system input to this assessment. Look for large, monolithic modules.

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. Mixed language types, however, may require both steps.

Record Manually Derived Process Flow Metrics

Record Tool Derived Process Flow Metrics

Produce Process Flow Narrative Summary

Review Process Flow Analysis Results

Data definition analysis

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

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: The following step is required if multiple systems are being assessed.

Assess Multi-System Data Definition Usage

General system architecture assessment

Note: The following steps are performed for each system input to this assessment. The DFD flows will be used to assess target architecture event analysis.

Document Batch System Information Flow

Document On-Line System Information Flow

Develop System/Sub-System Interface Map

Assess Batch Versus On-Line Update Factor

Note: The following step is a required component of this analysis as interface systems must be accommodated under the new server environment.

Document Related System Interfaces

Identify Use of Non-Standard Technologies

Document Subroutine Interface Levels

Summarize General Architecture Analysis

Presentation layer assessment

Note: The following steps are performed for each system input to this assessment (if multiple systems are being assessed).

Identify Batch Output Presentation Media

Identify/Categorize Batch Input Sources

Identify/Categorize On-Line Presentation Media

Summarize User Supported Environments

Record Presentation Layer Analysis Metrics

Create Presentation Layer Narrative

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

Application Architecture Summarization

Build Architecture Summary Metrics

Verify/Finalize Architecture Analysis Results

User backlog requirements analysis

Note: This analysis will focus on how backlogs will be handled during server architecture transition. These steps are very important to determine true user requirements.

Categorize User Backlog Requests

Uncover Hidden User Request Backlog

Eliminate/Consolidate Redundant Requests

Perform User Request Critical Path Ordering

Calculate Functional Quality Metrics

Complete User Backlog Analysis Summary

Subject Area/Entity Type Analysis

Derive Current System Subject Areas

Note: The following two steps are performed for each system being assessed.

Prepare/Load Current System Entity Types

Derive Existing Entity Relationship Diagram

Note: The following step is performed using current to target views.

Perform Current to Target Data Gap Analysis

Perform Current/Target ER Model Merge

Create Subject Area Analysis Summary

Function hierarchy analysis

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

Create Current Function/Process Hierarchy

Map Functions to Program Source Modules

Note: The following step requires top-down target model - a requirement of this scenario. This is the basis for subsequent logical/physical functional mapping.

Build Current to Target Function Map

Summarize Functional Reusability Analysis

Function dependency analysis

Note: The following step is performed for each system input to this assessment. Current dependencies will assist in evolving event based server environment.

Derive Current System Dependency Diagram

Note: The following step requires top-down target model.

Map Current to Target Dependency Diagrams

Summarize Function Dependency Analysis

Business Function/Entity Type Analysis

Note: The following step is performed for each system input to this assessment.

Establish Current System Matrix

Note: The following step compares multiple bottom-up views to determine level of overlapping and unique functionality.

Assess Current System Matrix Overlap

Note: The following step requires top-down target model - a requirement of this scenario.

Compare Current to Target Matrices

IS infrastructure analysis

Note: The following steps are performed for each system area input to this assessment - focus is on testing environment (data) and future education requirements.

Determine Staff Experience/Skill Ratings

Determine Testing Skill/Maturity Ratings

Determine IS Development Tool Ratings

Determine IS Quality/Maturity Ratings

Determine IS Summary Rating Factors

Perform Feasibility Analysis

Assessment Integration & Feasibility Analysis

Note: The following steps focus on selecting an approach (hypothesis).

Develop Application Summary Metrics

Develop Assessment Findings Report

Create Client/Server 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 subsequent work plan steps (each belonging to a respective Positioning task) that follow.

Finalize Interim Support Work Plan

Note: Application staging estimates must be developed for each of the subsequent Positioning steps outlined below. See suggested step flow in subsequent phases of this scenario.

Finalize Application Staging Plan

Note: If a language change is required to derive logic from non-standard languages, insert language change/language upgrade planning step here.

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

Develop Literal Externalization Work Plan

Note: The following task allows organizations to slice out logic that will not be migrated to server environment, retain it or move it into another application system (that is remaining on host).

Develop Reconciliation/Re-Aggregation Plan

Note: Validation step below is used to develop an estimate to validate each Positioning step listed above. See step flow in subsequent phases of this scenario for validation placement.

Establish Validation Criteria & Plan

Identify Support Structure Adjustments

Integrate Interim Plan/Strategic Objectives

Client/server migration planning

Build Strategic Redevelopment Plan

Develop Redevelopment Cost/Benefit

Note: The following steps identify work tasks and associated estimates required to complete the above two planning steps. Goal of these tasks is to port application data and logic into server architecture.

Finalize Logical Data Analysis Work Plan

Note: Object model derivation may be based on ER model or logical data model. Planned implementation of an object oriented system on a RDBMS suggests that a relational design is needed in any event.

Finalize Object Derivation Analysis Plan

Finalize Event Derivation Analysis Plan

Note: Rule derivation requires criteria/approach definition as a prerequisite step as defined below.

Define Rule Abstraction Criteria/Approach

Finalize Business Rule Derivation Plan

Note: Steps used in middleware enabling are finalize middleware tool requirements, design client/server interfaces and build middleware data store links. Note that steps are distributed across last two activities of last phase of this scenario.

Estimate Middleware Enabling Work Effort

Finalize Presentation Analysis Work Plan

Finalize Physical Data Design/Migration Plan

Finalize Redevelopment Work Plan

Prepare Systems for Client/Server Migration

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

Note: Minimize effort in steps below based on the degree that modules will retain their identity in target server architecture.

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

Perform Code Quality Assurance

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Refine 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

Note: First two steps assist in finalizing task plan and are typically applied at this point to adjust work estimates produced during the interim planning step.

Setup Data Name Rationalization Libraries

Review Record Grouping Analysis

Build Composite Record Definitions

Apply Descriptive Composite Names

Propagate Composite Record Definitions

Review and Propagate Secondary Names

Reconcile DNR Source with Production

Validate/Implement Rationalized Code

Validation

Perform Code Quality Assurance

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Refine Validation Data Sets

Validate Modified Programs

Obtain Validation Sign-Off

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Literal externalization

Note: This task is performed optionally based on a requirement to capture and externalize embedded data within current system. Perform no more than one of the following three steps.

Perform Literal Group Analysis

Create Tables from Literals

Externalize Embedded Literals

Validation

Perform Code Quality Assurance

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Refine Validation Data Sets

Validate Modified Programs

Obtain Validation Sign-Off

Remodularize Selected Source Code

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Code reconciliation & re-aggregation

Note: Scope of this task is dictated by reusable components and logic that must be maintained intact within legacy system. Use function hierarchy analysis or LTM mapping analysis as a guide to isolating and/or deactivating selected business functions as part of the client/server migration process.

Build Reconciliation/Re-Aggregation Analysis

Eliminate/Reconcile Redundant Processes

Re-Aggregate Segregated Functions

Validation

Perform Code Quality Assurance

Compile/Link Baseline Components

Compile/Link Positioned Components

Identify Validation Data Sets

Refine Validation Data Sets

Validate Modified Programs

Obtain Validation Sign-Off

Migrate Applications to Client/Server Architecture

Finalize Target System Object Model

Logical data analysis

Load/Merge Bottom-Up ER Model(s)

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

Refine Bottom-Up Derived ER Model

Merge Top-Down/Bottom-Up ER Models

Note: The following step creates normalized data model representing a view of existing stand alone system and new data as defined by top-down model view. Apply any special client/server requirements to model at this time.

Normalize Merged ER Model

Review and Sign-Off Normalized Data Model

Object derivation analysis

Perform Entity/Object Structural Mapping

Discover/Represent Object Composites

Identify/Add Singular Object Instances

Note: The following step maintains mapping analysis between data model and object model using LTM.

Add Entities/Objects into LTM Repository

Perform Object Model Behavioral Mapping

Specify Event & Business Rule Models

Event derivation analysis

Note: The following steps capture and respecify events. Step guidelines specify approach within single and across multiple systems.

Abstract/Define Externally Caused Events

Abstract & Define Time Driven Events

Abstract & Define Process Driven Events

Derive Layered Operation Structures

Business rule derivation

Note: While criteria were established during planning, it is prudent to solidify the approach prior to beginning business rule abstraction. Guidelines can be found in Define Business Rule Criteria/Approach step of the Business Rule Derivation task.

Identify Legacy Business Rules

Note: The following step identifies rules required to stay intact after implementation of client/server system using deactivation analysis. If this is required, it is recommended re-aggregation and reconciliation step be re-invoked prior to system deployment.

Reconcile, Respecify and Deactivate Rules

Complete Client/Server System Design

Client/server design requirements finalization

Note: The following steps are taken from middleware enabling and deal with specific configurations within a client/server environment. Use as a check list for environmental design.

Design Client/Server Interfaces

Presentation analysis

Categorize Existing Screen/Report Layouts

Perform Presentation Functional Analysis

Determine Reusability Under Target System

Refine Target System Report/Screen Design

Finalize Data Integration & System Migration

Physical Data Analysis & Migration

Note: Steps below finalize physical data design for new system. Key here is that object model is based on legacy derived data model and synchronized throughout design process using LTM. Deploying an object based system on top of RDBMS is greatly simplified using this overall approach.

Finalize Physical Data Model

Perform Physical Data Migration Process

Gain Physical Design/Migration Plan Sign-Off