In our last post, The Silver Tsunami – Out with the Old, and in with the…, we highlighted the three main options available for dealing with legacy systems: migrating, wrapping and modernization. With a specific focus on COBOL based systems, we concluded that both migration (lift-and-shift from, for example, mainframe to a Windows environment: COBOL to COBOL) and wrapping (adding connectivity layers without changing the core application) failed to address the core issue of the silver tsunami and potentially passed on a toxic problem to the next administration.
This post focuses on the modernization option and explores the Morphis approach to automating the transformation of the COBOL application to an MVC architecture running on C#/.NET or J2EE/Java.
The Morphis modernization approach is agnostic in terms of Java or .NET. Whichever your preference, the Morphis process is very similar and cost/delivery timescales the same.
A quick word on architecture:
Physical Architecture
Our standard target architecture is MVC, a 3-tier architecture although additional tiers can be added to provide increased flexibility and scalability, albeit at the cost of increased complexity, deployment/maintenance effort and cost.
In our experience, a 3-tier model provides the most optimal solution for the majority of applications.
Logical Architecture
For the layered logical architecture, we use a rich-client architectural pattern. This provides high performance, together with an interactive, rich user experience for applications that must operate in stand-alone, connected, occasionally connected, and disconnected scenarios.
We use logical layers for the Presentation, Domain, Data and Operational aspects of the system. Each layer exposes services to the others above.
The following diagram illustrates the layers, components and configuration:
In terms of the modernization process itself, this normally breaks down into the following components:
Pattern Mining/Source Model Transformations
This is the most generic activity. We have accumulated a series of generic COBOL transformations, all related to source code cleansing and optimization, that we can apply to all COBOL source code.
Outside of these generic situations, we use our Kuscos tool to detect application specific patterns. These often include, by way of example, discarding identified redundant code and unused variables; converting basic EVALUATEs to Ifs etc.
Transformation
The COBOL programming practices and concepts adopted by the client can provide a useful set of patterns from which we can automatically drive the design of the target applications.
For example, the COBOL programs transformed to procedural classes, with methods correspondent to the original COBOL sections and paragraphs. All COBOL statements, apart from the code patterns requiring special treatment, transformed to equivalent C# or Java code. All Working Storage variables transformed to Structural classes and private members. The COBOL copybooks transformed to public library classes, shared by all procedural classes obtained from the programs that include them in the application today.
The screen layouts can be captured from the COBOL data structures exchanged between the screen programs and the terminal. That information will be used to generate the new interfaces, either WPF windows or ASP pages, if .NET is the target. The remaining program logic will be migrated as interface event handlers.
All files and reports produced and consumed by the existing application will be handled by special proxy classes, which will have additional functionality, beyond Read or Write, such as serialization to different formats (XML, CSV) or sorting mechanisms.
The ‘sort’ functionality, in particular, can allow the application’s performance to be drastically improved, specifically in those cases where there is a heavy, yet required, I/O weight just for sorting groups of records.
After the transformation and the first side-by-side tests, we can use target model analysis to, for example, detect specific layout patterns (such as fields displaying dates and time, password input areas, groups of related fields, etc.), which can be replaced by modern semantically equivalent widgets, like calendars, password boxes and grids. This will be of major relevance, regarding the improvement and modernization of the transformed application.
The Morphis code generators will be customized not only to incorporate the target elements referred to above, but also to adopt any existing client practices or recommendations. They will be based on the existing Morphis C# or Java code generators that have been matured across many projects and have as their main guidelines: the clearance and simplicity of the code; the ubiquitous documentation of all elements; and the adherence to all major coding recommendations for the target language.
Finally, the database may need to be redesigned and migrated too. This is project specific and, in our experience, often carried out by the client project team. From a testing standpoint, and assuming the database is to be migrated, we will test the modernized application against the old database first and then against the migrated database to ensure equivalence.
As ever, if you have any questions or comments please reach out to us via the Contact Page.
