Package Assimilation

Overview

Symptoms

This scenario assumes that a package has been purchased and that assimilation (i.e. implementation and integration into IS environment) is required. If multiple packages are under consideration or management is weighing one or more packages against in-house redevelopment, consult the application replacement scenario.

The first four steps of the application replacement scenario assess the gaps between the ideal target system, the current system and one or more packages. Basing a package acquisition on objective criteria up front saves significant time and money over the long run.

Symptoms fitting this scenario include the following:

· A decision has been made to acquire a third party application software package

· An application package has already been acquired

· The package must interact, interface or in some way integrate with other in-house systems or packages

· The vendor will continue to provide upgrades and maintenance, precluding users of the package from changing the core system

Requirements

If a package was purchased to be used as a baseline for integration or redevelopment, or to be largely modified in some way, one should investigate other scenarios to meet these requirements. This scenario assumes that the package is not going to be altered beyond an occasional, small scale modification, and includes the following requirements:

· The package must receive information/data from one or more existing applications

· The package must send information to one or more existing or planned applications

· The package is required to send data to a graphical user interface system, an executive information systems (EIS) or other relational query based environment

· Support or feeder systems must be created to "round out" package functionality

· Organization wants to determine the initial and ongoing quality of the software package

· IS wishes to verify that package is, and stays, consistent with corporate data model

· Organization wishes to inventory, document and cross reference physical package components

Package Assimilation Planning Considerations

This scenario focuses on issues that organizations must consider during the integration of vendor application packages. These decisions, which include integration, deactivation, addition and implementation of multiple functions scattered across in-house and package software are very complex.

This information may be summarized in a variation of functional planning Form 004. An example of this type of variation on Form 004 is shown below.

The figure above shows functions derived from strategic requirements (S/R), analysis of packages under consideration (PK1, PK2, PK3) and legacy systems (LEG). Once a package is selected (this may be performed as part of the Application Replacement scenario), the plan for various functions and components, derived from new development, the package itself and the legacy applications, must be articulated as follows.

The other important issue is the assessment of the overall quality of a package and holding the vendor accountable for the improvement, or the degradation, of the quality of their systems. It is the intent of this scenario to empower organizations that rely on vendor software packages to one degree or another.

Topics included in this scenario are shown in the following figure.

Developing technical and functional documentation, in the form of formal models, allows an organization to develop interface systems, user inquiry systems or graphically based EIS applications. This figure shows some of the assimilation issues and the redevelopment related activities that support those requirements.

Assess/Document Application Package

Develop Package Analysis Proposal

Objective setting/proposal development

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.

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

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: Each of the following four tasks are redocumentation tasks that utilize only the bottom-up analysis step of that task.

Finalize Subject Area Analysis Work Plan

Finalize Function Hierarchy Analysis Plan

Finalize Function Dependency Analysis Plan

Finalize Function/Entity Type Analysis Plan

Finalize Feasibility Analysis Plan

Note: Interim plan is limited to capturing and porting data usage information into a physical representation.

Finalize Interim Planning Task Effort

Develop Inventory/Analysis Work Plan

Complete Inventory/Analysis Assessment Proposal

Inventory/Document Application Package

Environmental analysis

Note: The following steps focus on documenting all physical system components.

Identify/Categorize Physical System Components

Identify/Categorize External System Components

Process flow analysis

Note: Process flow analysis is performed for the package in order to assess the quality of that package. Poorly written packages should be sent back for correction. These steps may be rerun each time a new release is issued by the vendor.

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

Review Process Flow Analysis Results

Data definition analysis

Note: Data definition analysis assesses data usage quality and gathers meta-data as input to functional data analysis.

Perform System-Wide Data Definition Analysis

Perform Data Definition Complexity Analysis

Perform Homonym Analysis

Assign Data Definition Metric Counts

Review Data Definition Analysis Results

General system architecture assessment

Note: The following steps document package information flows. Apply applicable steps based on the presence of sub-system or multi-system division.

Document Batch System Information Flow

Document On-Line System Information Flow

Develop System/Sub-System Interface Map

Document Related System Interfaces

Identify Use of Non-Standard Technologies

Document Subroutine Interface Levels

Presentation layer assessment

Note: The following steps document user views and system interfaces.

Identify Batch Output Presentation Media

Identify/Categorize Batch Input Sources

Identify/Categorize On-Line Presentation Media

Data access layer assessment

Note: The following steps document data stores that are potential interfaces to feeder systems.

Finalize Database/Data File Inventory

Assess Physical Data Usage Redundancy

Determine Data Integration Levels

User backlog requirements analysis

Note: Application area should determine internal backlog requirements and deliver this to vendor.

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

Note: Bottom-up data model derivation, performed below, simplifies interface requirements to other systems, data warehouses, user based systems or an enterprise view of data.

Derive Current System Subject Areas

Prepare/Load Current System Entity Types

Derive Existing Entity Relationship Diagram

Function hierarchy analysis

Note: Functional decomposition allows analysts to more clearly understand how the system works so that interface systems may more readily be developed.

Create Current Function/Process Hierarchy

Map Functions to Program Source Modules

Note: If this analysis identifies a poorly designed application, ask the user to correct the situation.

Function dependency analysis

Note: This analysis step is optional but further helps document application functional flows.

Derive Current System Dependency Diagram

Business Function/Entity Type Analysis

Note: Function/data matrices assist with documenting how the system views, uses and updates data.

Establish Current System Matrix

Build Package Assimilation 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.

Assess Data Definition Rationalization Scope

Finalize Data Definition Rationalization Plan

Finalize Data Definition Migration Plan

Note: Include physical data upgrade as required to convert data to package environment.

Finalize Physical Data Upgrade Plan

Note: Where organizations wish to put GUI front-ends on a package or integrate package data with other systems, middleware enabling steps should be estimated. Note that the last of middleware enabling step focuses on capturing summary level data versus linking GUI front-ends directly to the package.

Estimate Middleware Enabling Work Effort

Identify Support Structure Adjustments

Integrate Interim Plan/Strategic Objectives

Implement/Integrate Application Package

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

Physical data upgrade

Note: Perform the following only as required by package implementation effort.

Verify Physical Data Integrity

Purify Physical Data

Expand/Convert Physical Data

Data definition migration

Note: The following step loads physical data utilization into appropriate repositories/dictionaries for documentation purposes.

Perform Repository Pre-Loading Analysis

Execute Repository Load Process

Note: The following step contains multi-purpose infrastructure guidelines. The repository section applies to this scenario.

Create Infrastructure Management Procedures

Develop/Maintain Package Interface Systems

Note: Organizations interested in "front-ending" packages, sharing data among other systems and giving users an improved interface should apply the following steps.

Client server design finalization

Finalize Middleware Tool Requirements

Design Client/Server Interfaces

Middleware communication finalization

Generate Middleware Communication Code

Enable Middleware Mainframe Linkage

Finalize and Link Middleware Applications

Note: Following step supports linkage to a summary level data base. This could be the package’s own relational data base system or an extracted view created from a package’s operational data. Creating a summary level relational data base involves following the Data Warehouse scenario in Comsys-TIM.

Build Middleware Direct Data Store Links