Redevelopment Paradigms

Mapping Software Re-engineering to Top Down Methodology

Most IS managers do not envision how software re-engineering technology can help accomplish strategic goals. Outlining the role of software re-engineering under a replacement strategy is the goal of this document. When it comes to making a systems replacement decision, management continues to pursue the three alternatives that have so often served in the past; build a new system, buy a package or do nothing. Doing nothing has become too high risk, leaving rebuilding and package procurement as available options.

This discussion deals with in-house redevelopment. The way redevelopment decisions are made must improve and, once made, the process used to implement a given decision must change. Simply stated, re-engineering technology can have a tremendous impact on redevelopment initiatives. This discussion outlines how formal, top down methodology and re-engineering work in consort to support the analysis and implementation of redevelopment requirements.

Defining a Mapping Target

To position the idea of methodology, it is important to settle on a single, generally accepted approach. Information Engineering or IE tends to be the methodology of choice in most large organizations today. This does not mean that the majority of IS shops have implemented or even accepted IE. What it means is that if a shop has selected a stated direction, it is probably IE. Methodology selection is important since the discussion covers the mapping of relatively new and unfamiliar technologies to a particular development approach.

A second common paradigm is object oriented (OO) analysis and design. Comsys-TIM accommodates object and event driven development by mapping to the Martin/Odell OO methodology. This particular incarnation of OO relies on IE at the planning level while providing object, event and business rule specification techniques at the analysis and design level. Both of these development approaches will be used as a basis to link redevelopment approaches to development initiatives.

Software Re-engineering Overview

Before describing the process of mapping re-engineering to top down methodology, it is important to clarify some terms. This discussion uses the IEEE definition of re-engineering. Re-engineering is the entire process of capturing information, storing it, refining it and forward engineering it into a new system. While many of the components of this diverse technology set already exist, the human factor is significant in a number of areas. This will become increasingly evident later in this paper.

Comsys Transformation and Integration Methodology - Comsys-TIM

Comsys-TIM provides a road map to applying re-engineering technology to a wide range of IS initiatives. Areas supported include ongoing maintenance, major enhancement, technology migration and full scale replacement. Since the last category embodies many of the aspects of the first three, and it is the topic of this discussion. Comsys-TIM is built on the premise that there is some level of value that can be derived from the existing information portfolio to assist in leveraging system replacement efforts. Comsys-TIM scenarios define specific redevelopment paths in complete detail and should be used for specific project planning and implementation efforts.

Comsys-TIM is built upon a four-stage framework. The Enterprise Redevelopment Planning stage and Inventory / Analysis stage support a variety of planning and analysis activities. Enterprise Redevelopment Planning basically augments the traditional Information Strategy Plan (ISP) by providing an enterprise wide view of the existing systems environment. This process provides a more complete view of existing systems and functional decomposition in order to assist in completing the current systems analysis component of the ISP. Inventory / Analysis continues this analysis at a more significant level of detail. The purpose of this stage is to provide bottom up models of a business area for project planning input required as organizations move into Outline Business Area Analysis (OBAA).

The functional assessment of Inventory / Analysis captures and represents legacy views of entity relationship models, function hierarchy diagrams, function dependency diagrams and business area / entity type matrices. Process derivation may be started to support OBAA based on specific project requirements. Strategic system plans may be augmented based on discoveries made during bottom up analysis of existing applications. Bottom up support continues throughout the next two stages of the methodology.

Positioning stage activities are source code to source code improvements aimed at simplifying the existing physical system. Discoveries made during this process further support analysis and detailed design under the IE model. The Transformation stage is where detailed mapping of existing data and functions supports further IE or OO analysis, design. As with Positioning, Transformation activities are driven from the initial Inventory / Analysis stage.

Inventory / Analysis: IE Planning & Analysis Support

Inventory / Analysis drives the redevelopment planning process and does not assume that "from scratch" development is the correct approach. IS organizations, for whatever reason, tend to conclude that this is the right approach because it may appear that no other alternatives exist. The best decision generally comes to light during the course of this analysis. Inventory / Analysis involves functional, technical and architectural assessments and subsequent merger of the findings.

Information gathered at this stage includes:

· Future plans and architectural requirements

· Future conceptual designs

· Current functional analysis

· Current technical and architectural analysis

Business level planning, a key component of IE, is an assumed first step in this process. If, for example, strategic planning determines that the line of business undergoing analysis is being sold, or merged into another line of business, the organization would build an interim "systems survival" strategy and reduce the emphasis on long term planning in this area.

Another scenario may involve the discovery of two systems that, if merged and upgraded, could fulfill the requirements of a new application system. The list of alternative implementation scenarios for full scale replacement is exhaustive. It is critical, therefore, to understand the process that one goes through to arrive at a replacement strategy, build the plan and determine the role of existing systems under that plan.

The Functional Assessment

Bottom up analysis captures and categorizes existing data and functions, and maps these models to top down strategic models. The objective is to identify similarities and differences between current and future models for purposes of "tempering" top down conceptual designs with information derived from production systems.

Bottom up analysis is a key factor in determining what role existing systems play in the evolution of the strategic information architecture. Bottom up analysis captures objects representing the data and functions active in today's systems. Data, the more static of the two, is captured and analyzed first. This includes automated analysis and Subject Matter Expert (SME) interviews.

Captured data definitions are "transversed" using a data definition re-engineering tool. This process derives Entity Relationship (E/R) models from the current system. These are compared to models built during top down planning. Conformance is based on the number of overlapping entities, missing target entities and missing entities in the current system. Tools supporting this mapping effort include reverse engineering tools that capture primary definitions, create a first cut E/R model and merge these models with models derived through top down analysis.

Assuming that existing definitions overlap significantly with the set of target entities, functional analysis may begin. If the mapping process results in a large number of differences between current and planned models, this could signal a significant change in how an organization plans to do business in a given area. Although this is fairly uncommon, this mismatch may be an indicator that further analysis of the existing environment may not provide additional dividends.

A function, under IE, is a logical collection of processes within a business segment. A business segment is a collection of functions under a given market sector. There are several methods for identifying specific functions within a system. While tools cannot specifically identify a business function, it is clearly a tools assisted process. The technical assessment supports system level inventory and cross reference as well as program process analysis.

Cross references and verb counts are used to classify and scope physical objects containing processing functions. This physical inventory, combined with a manual review of system and user documentation, establishes a basis for further analysis. Actual source code analysis, if required, focuses on the 10% to 15% of the programs containing 80% of a given system's functionality. The key to validating bottom up functional analysis relies on interviews with user and technical SME's.

The functional mapping process is completed using a mapping chart that identifies target function, current function, program name or names, system name and various physical attributes such as verb counts. Where no mapping exists in the old system, this signals a need for brand new functionality. Results are summarized by assigning a reusability factor for each module, sub-system and system component. High reusability factors indicate that the current system can play a key role in design and construction activities.

Building an Integrated Information Strategy

Individual organizations have specific requirements and formats when it comes information planning. If one uses IE, planning includes certain formats dictated by the methodology. For example, recommended components include Technology Impact Analysis and IBM's Business Systems Planning. Under Comsys-TIM, these plans retain their basic structure while incorporating components from the existing architecture as previously outlined.

Large scale initiatives are generally driven by cost. Cost benefit analysis is usually a main factor in selecting a replacement approach. Specific migration scenarios, once various assessments are completed, may be recast and costs recalculated. Management can then execute decisions based on economic data supported by objective analysis. Separate cost analysis should be created based on the various goals that an organization wants to accomplish.

Under Comsys-TIM, this means that, at a minimum, Positioning and Transformation be cost justified separately. The reason for this is pragmatic. As a rule, Positioning activities can be cost justified based on maintenance productivity gains, the ability to reallocate senior analysts from maintenance to new design activities and the increased ability to meet near term user requirements during the development of the replacement system.

One key concept is that, during the execution of various Positioning activities, any reuse strategy initiated under the Inventory / Analysis stage should be solidified while further refining Transformation cost estimates. Cost justification for the Transformation stage is a matter of assessing the feasibility and practicality of reusing components from the current system in the detailed design and construction of the replacement system. Assuming that various Positioning activities are justified under an interim support plan, and that reusing functional logic blocks reduces design and construction efforts, the cost of reuse should be weighed against the cost of completing these tasks from scratch.

Preparing Systems for Redesign & Reuse

Positioning tools and techniques improve the quality of existing systems without affecting the functions or the basic architecture upon which those systems were built. Activities include language change, program restructuring, data definition rationalization, literal externalization and the re-aggregation of system components. These are source code to source code transitions.

Program restructuring and data definition rationalization stabilize and standardize existing systems so that experienced personnel can be diverted to critical design activities. As stated earlier, existing systems are an excellent source of information to temper new designs, ensuring that critical data and functions are included in the new system. Elimination of physical redundancies and inconsistencies prepares systems so that reverse engineering tools can load "clean" system components into supporting repositories and / or I-CASE tools.

As stated earlier, data reverse engineering tools facilitate first cut development of a conceptual model under the Inventory / Analysis stage. Normalizing these data models is difficult with redundant, cryptic data definitions from aging systems. Data definition rationalization, allows bottom up data models to import standardized, rationalized records and elements, simplifying subsequent attributing and normalization of those models. In addition, data migration requires analysis of current data structures, a task greatly simplified by data definition rationalization.

Functional reuse is simplified after procedural restructuring. Additional positioning of procedural logic involves a tools assisted technique called code slicing. This includes physical re-aggregation of procedural logic along functional lines dictated by the new design. Each Positioning process serves a dual purpose of reducing system complexity while facilitating component reuse.

Transformation: Defining a Migration Path

Under Transformation, an organization may select among three general paths. The first is to continue down the IE path, capturing and augmenting the full breadth of IE based models. The Replacement, Integration and Redundant Systems Consolidation scenarios follow this path. An organization may take a data path, choosing to keep the procedural component of the system in a source code format. The Code Based Client/Server Migration and Relational Migration scenario follows this path. Finally, an organization may select an object oriented / event driven path. The Model Driven Client/Server Migration scenario details this path.

Three critical transition / migration requirements, applicable regardless of the migration path selected, are business rule reuse, rule deactivation and data concurrency mapping. Component reuse in the development of new systems has been in use for decades by programmers who understand the value of not reinventing the wheel. Formalization of this process under Comsys-TIM recognizes the value of reuse, applies it throughout planning, analysis and design, and reconciles redundancies to avoid replication in the target architecture. By doing so, reuse becomes an effective strategy driven by IS management. Reuse is integrated into all tasks in order to capture and reconcile legacy rules with each other and with top down design models to reduce specification time and verify correctness of approach.

Reuse requires the forward / backward mapping of procedural specifications to legacy environments. This process supports rule deactivation as well. Rule deactivation is required when a target system does not replace an existing system in its entirety. This means that a new system replaces some of the functions in one or more current systems, but not to the degree required to shut those systems down completely. Comsys-TIM facilitates rule tracing for deactivation during certain Transformation tasks, and implements deactivation via Positioning's remodularization tasks. This same process tracks physical and logical data mapping during planning, analysis, design and deployment so that analysts can determine how to manage legacy data migration as new systems are activated.

Reuse, deactivation and concurrency mapping are managed via the Comsys-TIM Legacy Transition Meta-model (LTM). The LTM is a meta-model that defines objects and relationships for tracking physical, logical and external system components during all phases of the redevelopment cycle. One may compare it to a I-CASE encyclopedia's role during a traditional top down development effort. The LTM is described in Comsys-TIM Appendix G.

Mapping to Other Development Paradigms

If an organization wishes to migrate to an architecture that differs significantly from the IE, OO or data driven paths discussed here, Comsys-TIM still has significant benefits. The analysis and derivation techniques in Comsys-TIM may be adjusted for projects to target different types of development models. Analysts should determine the analysis and design models to be targeted and adjust the mapping process accordingly. Integration of Comsys-TIM with development methods will yield the best results for an organization over the long term.