| MODERNIZATION VIA PLATFORM MIGRATION |
The commonest software modernization strategy is to migrate the existing software to a new platform.
Example: Migrating an IBM Mainframe COBOL, CICS, VSAM application to – say – Java, Java Server Faces, IBM WebSphere, Oracle. It is a comprehensive approach that is best suited for our automated transformation methodology which is not only the best migration method but also carries the least risk.
Our Automated Transformation Methodology
We use the model-driven concept of MDA to automatically transform an application from one platform to another.
There are various approaches to accomplishing our goal.
In our purest approach, we use OMG's Architecture Drive Modernization (ADM) methodology to extract "knowledge" from your existing application and export it to the standard MDA process, as depicted below:
|
 |
There are variations of this approach that we shall discuss later. Let us first explore the AUTOMATED DESIGN RECOVERY process.
Step-1: AUTOMATED DESIGN RECOVERY
Meta-Model based Approach
A Meta-Model contains information about a model. For instance, a Java Meta-Model defines the grammar, syntax, rules, constraints and structure of Java. Meta-Models are complicates structures that enable us to understand and model your application
|
 |
As the first step to transforming any application, we must build a Meta-Model (or use an existing Meta-Model) of the programming languages your application is written in.
Then our parsers can analyze the source code (with reference to the meta-model) and extract all possible atomic-level software artifacts into an XML Repository. The XML Repository then enables us to fully analyze the source code and automatically generate documentation and analysis results for further engineering. See schematic below:
|
 |
Step-2: ASSESS AND STRATEGIZE
We analyze the existing architecture, diversity tools used, usage of external function calls (black boxes), programming ingenuity, data models, program structure, inter-program communication, external APIs, and so on, we can truly assess the :as is" state of affairs.
Based on this assessment, we can advice you on the pros and cons of the strategic directions we can take to modernize the application.
The typical choices are:
|
1) Adopting Model Driven Architecture (MDA)
We shall implement the process depicted under OVERVIEW above
|
| |
a) Use Automated Design Recovery to extract the "knowledge" of your existing application.
b) Use that knowledge, with supplemental assistance from business users, to build the Business Model using a BPM Tool.
c) Use MDA's model-to-model transformation procedures to convert the Business Model into source code.
d) Compile, link, deploy the generated software. |
2) Adopting a "loosely-coupled" approach to MDA
|
This generally means skipping the Business Model but employing similar automated model-to-model transformation concepts to migrate an existing application from one platform to another. Below are two typical examples just to give you an idea. We shall refrain from a detailed discussion here.
|
|
Step-3: IMPLEMENT THE CHOSEN MIGRATION METHODOLOGY
|
Regardless of method chosen, the ultimate results are typically as follows (not intended to indicate sequence of events):
|
1) A new target platform is selected. For instance, J2EE, .NET, etc.
2) A new architecture is determined for the new platform under the 'n-tier' architecture.
|
The n-tier architecture readily implements Distributed Application Design concepts. It distributes a system’s overall functionality into a number of layers or “tiers” with each tier performing some unique tasks that are not handled by other layers. It is possible to develop each of these layers separately from the others, as long as it can communicate with the other layers and adhere to the standard specifications. It is possible for each layer to treat the other layers in a “black box” fashion. That means that the layers do not care how the other layers process information, as long as the data is sent between layers in the correct format. This separation of concerns protects the other layers from any changes that might occur within the functions one particular layer handles.
|
The following is an example of 7-tier architecture:
|
 |
Depending on whether J2EE or .NET is selected as the target, the exact architectural components shall vary, as depicted in the schematic below: |
 |
3) If required, the new application is Web-enabled.
We have tools to automatically generate GUI screens from Mainframe/Midrange Character User Interfaces, which can then be manually touched up, as necessary.
4) If required, the application is migrated to a New Database.
Database consolidation (merging multiple databases into one database) is sometimes a requirement.
5) New source code is generated in the target languages.
More than one language may be called for. This may include DDL (Data Definition Language routines), WSDL (Web Service Definition Language), XSD (XML Schema Definition), CSS (Cascading Style Sheets), Stored Procedures and other code segments. All source code is part of our deliverable.
6) Additional code re-factoring, SOA-enablement and additional functionality may be implemented, if required.
7) Dynamic documentation of the new code base is generated, where the documentation will change in real-time to reflect the latest changes to the software.
|
| |
| |
| |
