Application Replacement

Overview

Symptoms

The replacement scenario is clearly the most complex of the many options facing IS management today. The redevelopment approach provides new insight into this difficult challenge. Historically, IS has tended to ignore existing applications when building replacement systems, claiming that aging architectures rarely resemble strategic targets.

But typically, some percentage of data and complex procedures, representing a portion of what some people call "business rules", remains unchanged under the target architecture. This scenario helps IS discover and capitalize on the potential of reusing that portion of existing systems that can leverage the creation of new ones.

Symptoms include:

· Current architecture no longer meets ongoing business requirements

· Current technical foundation is dated or obsolete

· User requires functional upgrades that are difficult or impossible to add to the current architecture

· Application area must conform to corporate architecture, enterprise model, etc.

· Integration with newer applications is difficult or impossible

· Business has changed to the degree that current system no longer supports the organization

Requirements

This scenario is unique since a replacement requirement, at a high-level, could be satisfied by an in-house redevelopment effort or through the acquisition of an application package. Initial planning for this scenario takes this into account.

Typical scenario requirements may include:

· Replacement architecture and/or interface system integration requires total redesign

· Data, while remaining fairly consistent, requires relational redesign and integration into corporate data architecture

· Future maintenance should be performed at the design level where changes are made to models and systems are automatically regenerated

· New and diverse functionality is required in the new system

· Some percentage of current calculations or procedures, while being utilized in a different context, will remain constant under the new architecture

· There is a formal, in-house development methodology to guide the redevelopment process - if there is not, this is the wrong scenario

· A top-down set of models will be used to guide and formal each stage of the development cycle - preferably information engineering based or some derivation

· The replacement alternative could involve a package acquisition - if this is the case, but is yet undecided, the initial analysis steps of this scenario are critical

· The time frame for implementation of this new system is at least 2 to 3 years off

· Key SME personnel, currently dedicated to maintaining the current system, are required for the actual redesign and redevelopment effort

Application Replacement Planning Considerations

While this overview of replacement is somewhat generic, the reuse of current designs and processes under a new, strategic architecture is something that should at least be a goal with most organizations. This approach should be customized as needed to accommodate the particular needs of the organization.

The value of short-term Positioning to simplify maintenance and facilitate the reallocation of key personnel should not be underestimated. Organizations will, in fact, discover that many of the short-term Positioning activities serve a second purpose in preparing data and process definitions for reuse under the target architecture.

Finally, organizations using the redevelopment approach will begin to see that the much promoted, "from scratch" approach to building replacement systems is actually the more radical approach of the two.

Package Versus In-House Analysis

If in-house redevelopment is being compared to one or more application packages make sure to account for the following issues.

· Position the assessment proposal to reflect this multi-component comparison

· Position the existing system as another application package option with the added understanding that:

- The current application has no purchase price

- The existing system has no restrictions as to how it can be modified to facilitate implementation and integration

- The current system can be incrementally improved as it evolves towards the target architecture

· The functional requirements produced in the functional assessment task will be used to specify vendor package requirements

· A vendor package should accommodate the integrated requirements of these models

· If possible, obtain package vendor models and utilize these models to perform top-down gap analysis against the target architecture

· Alternatively obtain package source objects and derive bottom-up models from the package to perform target gap analysis

· Determine if the package(s) or in-house application comes closest to meeting strategic requirements as defined in the top-down model

Potential Hypotheses

The nature of this scenario leaves the potential options fairly wide open. The following are some viable alternatives that may be considered under this scenario.

· A vendor package may be used, as is, as the basis for the new system

· One or more packages may be modified/integrated as the basis for the new system

· One or more packages and/or in-house systems may be integrated as the basis for the new system

· One or more in-house systems and/or packages may be integrated with a strategic top-down model to create the new system

Scenario Re-Directive

Finally, the nature of this scenario establishes and tests a multitude of hypotheses as the basis for the new system. Upon determining an approach, this scenario may redirect users to the package assimilation scenario (no modifications) or the application integration scenario.

The integration scenario assumes multiple existing systems will be integrated with or without benefit of a strategic top-down model. Staying within this scenario through implementation means that a single system is being utilized as the baseline with top-down formal model integration utilized where available.

Build Application Replacement 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 and typically includes options to capture and integrate bottom-up and/or top-down views as follows:
· Bottom-up (only) integration of existing stand alone systems
· Bottom-up (only) integration of vendor package and existing stand alone systems
· Bottom-up/top-down integration of existing stand alone systems
· Bottom-up/top-down integration of vendor package and existing stand alone systems
· In-house/package acquisition and assimilation

Develop Inventory/Analysis Objectives

Establish Assessment Task List

Note: Each system must undergo environmental, process flow and data definition analysis - adjust work plan accordingly.

Finalize Environmental Analysis Work Plan

Finalize Process Flow Analysis Work Estimates

Note: All steps of data definition analysis will be performed for each system. Perform the "assess multi-system data definition usage" step across multiple systems if those systems are being reviewed as a basis to become integrated baseline.

Finalize Data Definition Analysis Work Estimates

Note: Assume all steps of the architectural assessment are to be performed for each system entering this analysis. This may not be practical or required for vendor packages but is recommended if possible.

Finalize General System Architecture Work Plan

Finalize Presentation Layer Analysis Plan

Finalize Data Access Layer Assessment Plan

Create Architecture Summary Work Plan

Note: Perform all steps in the user backlog analysis task for all users of all application areas impacted by the replacement initiative.

Finalize User Backlog Analysis Plan

Note: The next four steps focus on comparing bottom-up views of current systems to themselves or to top-down models based on options being evaluated. An integrated view of current baseline is created as final step. The following is recommended.
· Use in-house integrated set of systems as one set of bottom-up models
· Use vendor package(s) as another set of bottom-up views - where applicable
· Combine bottom-up views where in-house/vendor package are under review as a combined solution
· If multiple bottom-up views are being compared to top-down models, plan to execute gap analysis steps multiple times for each functional assessment task listed below

Finalize Subject Area Analysis Work Plan

Finalize Function Hierarchy Analysis Plan

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.

Finalize IS Infrastructure Analysis Plan

Note: Narrow down hypotheses at this point to focus one or at the most two recommended approaches - feasibility analysis will walk user through this process.

Finalize Feasibility Analysis Plan

Note: Interim plan should improve/stabilize all assessed systems based on assessment findings. This may be done just to free analysts from current system to work on new top-down design or on package assimilation effort.

Finalize Interim Planning Task Effort

Note: The redevelopment plan will include either a bottom-up integration or a top-down/bottom-up integration effort based on selected hypothesis - follow estimating guidelines in step below.

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: The process flow analysis is performed for each system input to this assessment.

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 systems may use both steps.

Record Manually Derived Process Flow Metrics

Record Tool Derived Process Flow Metrics

Produce Process Flow Narrative Summary

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: The following steps are performed for each system input to this assessment.

Perform System-Wide Data Definition Analysis

Assign Data Definition Metric Counts

Note: The main target of data definition analysis in this scenario is the record grouping analysis. Other data definition metrics may be left blank.

Calculate Data Definition Metric Scores

Produce Data Definition Narrative Summary

Review Data Definition Analysis Results

Note: The following step is a required component of this analysis where multiple related systems might serve as the basis for an integrated redesign effort.

Assess Multi-System Data Definition Usage

General system architecture assessment

Note: The following steps are performed for each system input to this assessment - include packages if source is available and time allows.

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.

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.

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

Note: If multiple baselines are being assessed, multiple summaries are produced (i.e. one for package A, one for multiple in-house, etc.)

Build Architecture Summary Metrics

Verify/Finalize Architecture Analysis Results

User backlog requirements analysis

Categorize User Backlog Requests

Uncover Hidden User Request Backlog

Note: The following step is key to linking overlapping/redundant requests across related systems.

Eliminate/Consolidate Redundant Requests

Perform User Request Critical Path Ordering

Calculate Functional Quality Metrics

Complete User Backlog Analysis Summary

Subject Area/Entity Type Analysis

Note: One bottom-up model will be created for each system input to this analysis - if a set of related existing systems is being modeled, use the cross system grouping analysis (data definition analysis last step) to create one ER model for that group.

Derive Current System Subject Areas

Prepare/Load Current System Entity Types

Derive Existing Entity Relationship Diagram

Note: The following step is performed using current to current and/or current to target views based on hypotheses being explored. Gap analysis may be performed using integrated ER (see above) and/or models from packages. The key here is to perform a gap analysis and model merge for each hypothesis proposed at the beginning of this scenario.

Perform Current to Target Data Gap Analysis

Perform Current/Target ER Model Merge

Note: Create one summary for each gap analysis (i.e. hypothesis) performed.

Create Subject Area Analysis Summary

Function hierarchy analysis

Note: The following steps are performed for each system input to this assessment. Follow the same basic premise used in the subject area/entity type analysis task above.

Create Current Function/Process Hierarchy

Map Functions to Program Source Modules

Note: The following step requires top-down target model as a target. If none exists, one alternative could involve obtaining an industry standard (package) model as a mapping target. Functional coverage is difficult to assess when no strategic model is available as a baseline.

Build Current to Target Function Map

Summarize Functional Reusability Analysis

Function dependency analysis

Note: The following is performed for each system input to assessment. Apply the same basic grouping/assessment comparison principles used in subject area/entity type analysis task above.

Derive Current System Dependency Diagram

Note: The following step requires top-down target model as a target. If none exists, one alternative could involve obtaining an industry standard (package) model as a mapping target. Functional coverage is difficult assess when no strategic model is available as a baseline.

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 other bottom-up views to assist in determining the level of overlapping and unique functionality among systems.

Assess Current System Matrix Overlap

Note: The following step requires top-down target model or, if available, a cohesive model of an application package if it is being considered.

Compare Current to Target Matrices

IS infrastructure analysis

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

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). At this point, a decision will be made to use one or more in-house and/or vendor packages as a repository of functionality from which to derive a replacement application.

Develop Application Summary Metrics

Develop Assessment Findings Report

Note: If a package is selected because it maps well to required target functionality/architecture and the package is to remain intact after implementation (no core changes), proceed to package assimilation scenario.

 

Note: If multiple in-house systems and/or vendor packages are to be substantially used as the basis for the target system, regardless of the availability of a top-down set of models, proceed directly to the "Build application integration plan" step in application integration scenario. This scenario supports comparative analysis of multiple bottom-up integration options if a single hypothesis could not be settled upon.

 

Note: If a single system is going to be used as the baseline for the target system or a fairly robust top-down design is available with derived designs serving to "fill out" that design, continue using this scenario to drive the remainder of the redevelopment project.

Create Application Replacement 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 each of the 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.

Finalize Application Staging Plan

Finalize Language Change Work Effort

Note: This language change task planning step is optional based on input system and requirement to derive logic from non-standard languages.

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

Finalize Code Slicing Work Plan

Develop Reconciliation/Re-Aggregation 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

Note: If a single redevelopment hypothesis (option) was not selected during feasibility analysis, multiple redevelopment plans may need to be created to perform cost analysis on each plan.

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. At this point users will have a clear idea as to whether top-down models will be tempered using bottom-up derived data or if a single, bottom-up system is being used as baseline with new functionality added along the way. Work plans should be tempered accordingly using available development methodology.

Finalize Logical Data Analysis Work Plan

Finalize Process Hierarchy Analysis Plan

Finalize Process Dependency Work Plan

Finalize Business Rule Analysis Plan

Finalize System Structure Analysis Plan

Finalize Interaction Analysis Work Plan

Finalize Dialog Flow Analysis Plan

Finalize Presentation Analysis Work Plan

Finalize Physical Data Design/Migration Plan

Finalize Program Specification Work Plan

Note: The following step is required only if multiple strategic plans were created to detail and compare multiple redevelopment options.

Review/Select Redevelopment Hypothesis

Finalize Redevelopment Work Plan

Position Systems for Replacement

Stabilize Current System Baseline

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Language change/language upgrade

Note: Placement of this task within this scenario supports partial or small scale language change objectives for selected modules. System-wide efforts should refer to the Comsys-TIM language conversion scenario.

Prepare Source Code for Conversion

Convert/Upgrade Each Source Module

Perform Environmental Migration

Validation

Perform Code Quality Assurance

Perform Data 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

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: First step below assists in refining task plan and is recommended because restructuring was not completed when original assessment plan was produced.

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

Setup Data Name Rationalization Libraries

Review Record Grouping Analysis

Build Composite Record Definitions

Identify/Reduce Homonyms

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

Note: Code slicing is a short-term, high pay back task that reduces work associated with code reconciliation & re-aggregation. If large modules do not exist (no immediate slicing need), slicing may be integrated in code reconciliation & re-aggregation.

Application staging

Identify/Categorize Components of Interest

Create Working Version Libraries

Document Versions and Library Protocol

Synchronize Staged Source with Production

Code slicing

Develop Program Slicing Analysis

Perform Program Slicing Process

Perform Alternative Slicing Technique

Re-Configure Slice Related Components

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

Code reconciliation & re-aggregation

Note: The scope of this task is governed by the reusable components discovered during function hierarchy analysis. Apply the following steps only if the current system will make up a substantial portion (over 50%) of the target system. Use function hierarchy analysis as a guide as dictated by steps below.

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

Integrate/Migrate Application Architecture

Finalize Target Data Architecture

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

Note: The following step is optional based availability of top-down model based on the redevelopment option selected.

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 or added to the derived bottom-up view.

Normalize Merged ER Model

Review and Sign-Off Normalized Data Model

Develop Target Process Models

Process hierarchy/dependency analysis

Note: The following step is performed on a system by system basis.

Derive Bottom-Up Process Hierarchy Model

Note: The following step is used only where no top-down model is available using a bottom-up only approach.

Redesign Bottom-Up Process Hierarchy(s)

Note: The following step relies on availability of top-down model where bottom-up hierarchy models are used to refine top-down views.

Integrate Bottom-Up/Top-Down Hierarchies

Finalize Target Process Hierarchy

Develop Bottom-Up Process Dependencies

Note: The following step relies on availability of top-down model where bottom-up hierarchy models are used to refine top-down views.

Merge Current/Target Process Dependency Models

Finalize Target Process Dependency Model

Business rule analysis

Derive Bottom-Up Process Action Diagrams

Note: The following step relies on availability of top-down model since this scenario is only applied where a single current system is being redeveloped.

Merge Processes into Target Action Diagram

Refine Completed Process Action Diagram

System structure analysis

Note: Perform the following step for each existing system being integrated.

Derive Current System(s) Structure Chart

Build Target System(s) Structure Chart

Interaction analysis

Note: Perform the following step for each existing system being integrated.

Build and Refine Current System Matrix

Build and Refine Target Application Matrix

Complete Target Application Design

Dialog flow analysis

Assess Current System Dialog Flows

Perform Dialog Flow Gap Analysis

Create Target Dialog Flow Diagrams

Presentation analysis

Categorize Existing Screen/Report Layouts

Perform Presentation Functional Analysis

Determine Reusability Under Target System

Refine Target System Report/Screen Design

Program specification

Capture/Import Reusable Procedures

Finalize Target Procedure Action Diagrams

Finalize Data Integration Phase

Physical Data Analysis & Migration

Finalize Physical Data Model

Perform Physical Data Migration Process

Gain Physical Design/Migration Plan Sign-Off