Transformation & Integration Scenarios

Business Driven Redevelopment Scenarios Overview

Redevelopment Scenario Usage Summary

Scenario Concept

Comsys-TIM scenarios facilitate rapid analysis of specific IS situations that management must accommodate on a regular basis. Once selected, a scenario identifies a unique path through Comsys-TIM to accommodate project requirements. This includes applicable assessment and planning steps, code improvement steps and various Transformation or model driven steps based on the situation. Comsys-TIM scenarios support a wide variety of IS redevelopment needs including client/server migration, century date change, multi-system integration, technology migration, systems stabilization, package assimilation and full scale replacement.

Scenarios are the key to making Comsys-TIM readily applicable to a variety of situations with limited training requirements. Analysts compare a given set of application issues with symptoms defined under one or more scenarios. Once a scenario is identified, a list of scenario requirements can be compared against application area needs. The scenario then identifies the assessment and implementation steps within the core of Comsys-TIM required to meet specific project requirements. Scenarios even assist in selecting from a variety of alternative approaches.

Organizations with little redevelopment experience should utilize Enterprise Redevelopment Planning to assess requirements, perform an enterprise assessment and apply the guidelines in the last task to suggest project based scenarios. This is discussed further in the scenario selection section that follows. Also, analysts should be aware that a path through Comsys-TIM is rarely sequential. Certain scenarios may even apply certain Transformation steps prior to selected Positioning steps. This is also discussed in more detail in subsequent sections.

Scenario Structure

Each scenario is built around a similar design structure. A scenario contains activities that help the user establish project objectives, evaluate alternative approaches, develop an assessment plan, perform the assessment, build an implementation plan and execute implementation tasks. Each set of activities is comprised of step names that link directly back to redevelopment tasks under the Comsys-TIM framework. Scenario specific directives are interspersed between steps.

This common structure supports creation of assessment and implementation plans by referencing the initial planning steps found at the beginning of applicable redevelopment tasks. Planning steps contain the algorithms required to build a detailed assessment plan that can be adjusted based on situation specific requirements. The implementation plan is then based on metrics and related data gathered during the assessment. The scenario implementation plan can again be adjusted based on unique project and application requirements.

This structure is graphically displayed for each scenario within Comsys-TIM. New scenarios, either developed through user extendibility or through future releases, should follow this same over all structure.

Scenario Selection

Using a scenario involves problem analysis, requirements review and work plan customization. Analysts researching legacy redevelopment requirements should review the Scenario Impact Matrix, identify one or more candidate scenarios and compare application area issues to the symptoms listed at the beginning of that scenario. Certain scenarios, such as Century Date Change and Enterprise-Wide Portfolio Analysis, use selected Enterprise Redevelopment Planning steps. This stage, however, may be used as a generic assessment and planning guide to assist with application area scenario selection.

The concept is fairly straight forward. If an organization knows what they are trying to accomplish, they may select a scenario and modify it as required. If, on the other hand, management is unsure as to how redevelopment supports organizational needs, Enterprise Redevelopment Planning guides planners through the analysis and scenario selection process.

Once symptoms are mapped to a given business area's needs, scenario requirements should be reviewed with the management team. Requirements, and the subsequent plan, should then be customized based on unique project needs. Alternative approaches should be clearly defined during the first step of the assessment. This dictates the scope of the overall assessment and subsequent implementation effort.

Most scenarios assume and accommodate potential alternative approaches within the assessment process. Feasibility analysis and the planning tasks assist the user in selecting and detailing the best alternative. Occasionally, a scenario directs analysts into a different scenario. For example, Application Replacement may direct users to the Package Assimilation scenario.

Another approach involves combining scenarios to address a broader problem. For example, Application Stabilization may be used to improve maintainability, while the Graphical User Front-End scenario is used to facilitate end user data access. One reason to combine scenarios is so that analysts do not have to repeat the same assessment tasks under a separate project.

A second reason stems from having to apply concurrent tasks to a system because of time limitations. Care must be taken when combining scenarios since the impact of one task on a subsequent task may not be readily apparent to the novice user. Task entry/exit criteria, along with embedded guideline notes, should be consulted carefully.

Finally, assessment projects are typically phased. Large systems, multiple systems, combined scenarios or an inexperience can drive assessment phasing. A typical approach for staging and scoping activities as a project planning activity may include the following:

1. Determine the minimum analysis/planning steps required to get to a decision point and establish as Phase I. This typically involves objective setting, technical assessment, user backlog requirements analysis and an initial interim plan.

2. Determine what, if any, system Positioning activities may begin based on this limited level of analysis. This could include code stabilization steps for example.

3. If required, add incremental analysis steps in subsequent phases. This typically involves an architecture assessment and revised interim plan as Phase II. This is typically followed by functional assessment steps, feasibility analysis and strategic plan as Phase III. Phases II and III imply architectural modifications as dictated by a scenario.

4. Parallel Phases II and III with various Positioning steps as appropriate based on point 2 above.

5. Stagger and sequence all activities for each system being assessed. Scoping guidelines are included in the information redevelopment planning and objective setting/proposal development tasks.

6. Refine the plan based on resource requirements and planning guideline steps.

Scenario Symptoms and Infrastructure Impact

Application Integration Scenario

This scenario supports cross functional analysis and integration of stand alone systems. A typical example might include payroll, insurance and pension systems that need to be rolled into a fully integrated human resources system. Symptoms of this scenario include the following:

· Multiple, stand alone systems may all process similar data redundantly and inconsistently

· Inadequate or nonexistent sharing of data between systems is severely limiting user service levels

· Redundant or overlapping processes exist within systems belonging to different application areas

· Downstream systems have evolved to handle much of the functionality that should be defined in core systems

· Users get different answers to the same questions from different systems

· Management is committed to integrating systems using formal, approach that applies Information Engineering techniques

· Stand alone systems cost too much to maintain due to lack of coordination with related systems

Application Replacement Scenario

The replacement decision is clearly the most complex issue facing IS today. This scenario provides new insight into a difficult challenge. It utilizes design recovery and component reuse techniques to leverage application replacement efforts. Replacement initiatives are unique because, at a high-level, they may be satisfied by an in-house project or through application package acquisition. Initial planning for this scenario takes all potential options into account and then helps analysts build an implementation plan or re-directs them to another scenario. Symptoms include the following:

· Current functional and data architecture no longer meet ongoing business requirements

· Current technical foundation is dated, obsolete or irreparable

· User requires functional upgrades that are 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

· Management is committed to redeveloping systems using formal, approach that applies Information Engineering techniques

Application Stabilization Scenario

This is the most commonly applied scenario. It analyzes basic weaknesses in the current application, determines user requirements and produces a detailed implementation plan to upgrade the current system. This scenario involves no architectural modifications and provides some insights into streamlining the maintenance process itself.

Symptoms include:

· Large and/or growing user request backlog

· High system failure rates or reliability and integrity problems

· Long modification lead times, poor IS responsiveness or user dissatisfaction

· Long learning curve, high turnover, junior staff or poor morale among support team

· High system maintenance costs that are not proportionate to business returns

· Users limit requests or reroute requests to other areas due to poor responsiveness

· Maintenance personnel are working on redesign or redevelopment initiatives

Code Based Client/Server Migration Scenario

Redeveloping legacy systems from scratch is not required when major business functions remain constant in the target environment. Furthermore, organizations may not wish to redevelop systems in a model driven environment. This essentially means that the current system is to be remodularized and rehosted to a client/server based environment.

Symptoms for code based migration to client/server include:

· Management looking for fastest implementation path to client/server

· Organization accepts need for a relational database architecture in a distributed environment

· Language of choice, or at least an acceptable alternative, is the language host based systems already use

· Client/server system requirements functionally mirror host based implementation in terms of a one-for-one replacement

· Language change or language level upgrade is an acceptable pre-step to a client/server migration

· Management is not interested in fancy models - just results

· Client/server has been mandated and time allotted is too short for a complete redesign

Data Warehouse Scenario

This scenario builds an integrated, downloaded database and graphical front-end to access the data. A graphical front-end to integrate information gathered from disparate systems is a stop gap measure. Long-term solution involves using approaches detailed in the Application Integration or Client/Server scenarios.

The following symptoms apply:

· Redesigned business functions require service functions to be consolidated to single points of access, i.e., a customer only having to deal with a single service representative

· Users require access to data that crosses organizational and application boundaries

· Corporate data warehouse requires disparate systems to feed a comprehensive data model

· Disparate data across multiple systems make it difficult to access user summary information

· Users want a graphical user interface (GUI)

· There is not enough time or budget to integrate or modify core applications

Enterprise-Wide Portfolio Analysis Scenario

Many times an IS organization requires an accounting of all application systems. This may be enterprise-wide or may be restricted to a business segment, such as a division. This accounting identifies all systems, sub-systems and run streams by providing summary level technical and functional information on those systems. It further summarizes relationships among systems. This Comsys-TIM scenario is called Enterprise-wide Portfolio Analysis. It utilizes a subset of steps as outlined in the Enterprise Redevelopment Planning stage.

A main difference between this scenario and performing all steps within Enterprise Redevelopment Planning is that this scenario summarizes current capability while a complete enterprise assessment maps findings to strategic requirements. Symptoms indicating a need to perform an enterprise-wide portfolio analysis include:

· Management requires detailed audit of information systems environment to estimate asset value

· Categorization of systems and sub-systems by business area is required to establish portfolio baseline

· This baseline is to be represented in some type of repository for ongoing reference purposes

· Planning initiatives require current systems data structure and functional overview

· Migration and redevelopment projects require baseline information to segment portfolio into functional work units

Graphical User Front-End Scenario

Organizations with an immediate need to bring a client/server "look and feel" to end users typically begin by adding a graphical user interface (GUI) front-end to one or more systems. This is a scenario that impacts core systems to the degree desired, while providing a graphical user interface to end users. Symptoms are listed below:

· Users require an improved interface to legacy system

· Input can be streamlined through more efficient data gathering and data transfer to host

· Core system functionality, data structures and data interfaces remain unchanged

· I/O and business logic isolation can be, minimized or applied on an extended basis to move validation or other logic to workstation environments on a selective basis

· Front-end edits may be moved to client workstation

IBM COBOL/370 Upgrade Scenario

This scenario will focus on the migration of OS/VS COBOL systems to COBOL/370 standard. If desired, however, this scenario could be used as the framework for a migration from OS/VS COBOL to VS COBOL II, DOS/VS COBOL to COBOL for VSE or even DOS/VS COBOL to COBOL/370.

The COBOL language level upgrade approach outlined in this document applies to organizations that have the following characteristics:

· Large scale and/or critical mainframe IBM COBOL applications utilizing language levels for which IBM has discontinued support

· Management committed to move the current systems to a new language level

· Identified, business driven requirements to take advantage of visual development and/or object oriented technologies while retaining current investment in application source code and programmer skill set

· Systems in need of virtual storage constraint relief

· Strategic directive to employ distributed processing technologies in new and existing applications

· Language level upgrade to the new COBOL standard can serve as a first step toward a desired OS/2 client/server migration

Integrated-CASE Population Scenario

Moving to an Integrated Computer-Aided Software Engineering (I-CASE) environment is a strategy that many organizations want to pursue as they integrate applications, redesign architectures and replace systems. The move to I-CASE; however, tends to be difficult to justify as a stand alone project. If the decision has been made, however, this scenario supports the process. The difference between this scenario and the integration, replacement or client/server scenarios is that it populates the I-CASE environment while leaving the functional and data architecture basically intact.

Symptoms include:

· Management has made a significant investment in I-CASE products and they are not being used

· Information Engineering has been adopted and management would like to use I-CASE as a vehicle to move systems closer to that paradigm

· Management anticipates maintenance productivity improvements from moving systems into the I-CASE environment

Language Conversion Scenario

This is a conversion scenario that specifically applies to moving IBM Assembler language code (ALC) to COBOL. Because many of the characteristics of a conversion are common across language types, this particular scenario could be adapted to support other language to language conversions.

The ALC to COBOL approach applies to applications with the following symptoms:

· Large scale ALC or ALC/COBOL applications

· An identified, business driven requirement to apply significant changes to the application

· Lack of availability of an application package that could meet replacement requirements

· Identified funding to complete a large scale conversion project

· Current systems contain unique or complex business logic that must be retained within a replacement system

· Management is committed to move the ALC application into a COBOL environment

· A baseline system must be established from which current applications may be migrated to a strategic architecture

Model Driven Client/Server Migration Scenario

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

· 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

Package Assimilation Scenario

This scenario assumes that a package has been purchased and that assimilation (i.e., implementation and integration into the IS environment) is required. If several packages are being considered or management is weighing one or more packages against in-house development, refer to the application replacement scenario. This scenario assumes that the package is not going to be altered beyond an occasional, small scale modification.

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

· Explicit redocumentation of the package is required

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

· Vendor will continue providing upgrades that precludes users from changing the core system

Redocumentation Scenario

Many old systems are not well documented or documented at all. There seems to be a continuous need to understand legacy systems more effectively. The redocumentation scenario is aimed at providing this information for maintenance or redevelopment support teams.

Symptoms include:

· New or junior personnel cannot figure out what a system is doing, or supposed to be doing

· A major enhancement is held up because analysts cannot figure out where to apply changes

· People refuse to work on a system because they cannot figure out what it does

· Functional documentation is cryptic, inaccurate or incomplete

· There is limited technical documentation showing overall system architecture, information flows, program processing flows or system-wide data usage

· Management is committed to merging systems using formal, approach that applies Information Engineering techniques

Redundant Systems Consolidation Scenario

Many organizations have multiple systems that perform the same basic functions. For example, a merger or an acquisition may have resulted in three separate billing systems. System cloning also contributes to this issue. Redundant systems contribute to excessive maintenance, inconsistencies in user interface, redundant/inconsistent data and a host of integration problems. If systems seeking consolidation are related (such as payroll, pension and insurance systems) and not duplicate systems, the analyst should proceed to the application integration scenario.

Symptoms indicating that this scenario is applicable include the following:

· Currently running several systems that essentially perform the same or similar functions

· Several similar systems contain overlapping and/or redundant physical data

· While not identical or as functionally rich, the redundant system or systems serve the same basic function

· The organization wishes to consolidate redundant business areas into a single functional unit

· IS wishes to consolidate redundant systems support areas into a single unit

· High IS and user support costs require the consolidation of redundant functions

Relational Data Base Migration Scenario

A migration to a relational database management system (RDBMS) is typically driven by a larger business scenario. But 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 based 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 follow:

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

· User requires a more flexible view of data-based on changing business requirements

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

Building Customized Redevelopment Scenarios

Scenario Structure

Scenarios are basically groupings of Comsys-TIM steps to facilitate planning and implementation of various types of redevelopment projects. A consistent scenario structure should be used for new scenarios. This structure relies on activity groupings that include building the integration plan, preparing and/or stabilizing current applications and, depending on the scenario, migrating to the target architecture.

Each activity grouping, represented by a box or "button" on the following exhibit, is a collection of steps that allow the user direct access back into the body of the Comsys-TIM redevelopment framework. This is done on-line through "hot key" access to steps within the framework. Each scenario step name must match exactly to the step name listed in the framework.

Initial steps include establishing project objectives, identifying alternative options, building the assessment plan, performing the assessment, deciding on an approach and building the implementation plan. A second activity set includes upgrading the current application through various Positioning steps. In some cases this concludes the project. Where business, data or technical architecture is impacted, subsequent Transformation steps are invoked to develop the "replacement" application under the target architecture.

Scenario specific directives are interspersed between relevant "hot key" steps. The goal is to minimize the amount of custom directives embedded in a specific scenario by taking advantage of common guidelines within the Comsys-TIM framework. This allows for scenarios to take advantage of new techniques or tools as they are added to the common framework.

Designing and Building New Comsys-TIM Scenarios

Utilizing the structural guidelines for a Comsys-TIM scenario provided in the prior section, an analyst may build a customized scenario based on unique requirements within a given organization or application area. If the scenario has common applicability across organizations, it might be incorporated into a future Comsys-TIM release. The following guidelines should be used when adding a custom scenario to Comsys-TIM.

1. List the specific symptoms and requirements unique to that scenario.

2. Verify that these symptoms and requirements are not addressed in an existing scenario.

3. Use the base scenario model presented in the Application Integration Scenario - this is a superset of the typical steps required in a given scenario.

4. Establish the proposal development, assessment, feasibility and planning steps required for the new scenario.

5. Determine which assessment tasks/steps apply to this analysis. All three technical assessment tasks typically apply whereas the last four functional and all architectural tasks support more specialized cases.

6. Use the first step in each applicable assessment task to build the assessment plan.

7. Always perform the feasibility analysis and interim planning tasks, but only invoke the strategic redevelopment planning task if an architectural shift is required.

8. Use the first step of each applicable Positioning and Transformation task to build interim and strategic redevelopment plans.

9. Select and list the appropriate Positioning and Transformation steps to meet the requirements of the scenario.

10. Intersperse various notes or directives within the steps based on unique scenario project requirements.

11. Follow the Comsys-TIM user guide to add these scenarios to the product using the extensibility function.