Month: June 2017

    Legacy Modernization – Let’s Get Real!

    LegacyModernization - Let's Get Real

    Two things happened on Monday that left me shaking my head, wondering just what the hell is going on in the US government when it comes to legacy modernization. It’s not just the US government, or government generally, this applies much more broadly and is something we’ve touched on in the past.

    The first head shaker was the visit of tech industry leaders to the White House to talk about legacy modernization. A photo opportunity, or an in-depth analysis of the problem and possible solutions? As brilliant as these tech leaders are, do they represent the leading edge of knowledge in how to modernize legacy systems?

    I was surprised to read (in the article above) that one senior White House official described federal systems as “in some cases 10 to 20 years old.” That would suggest an origin of 1997 to 2007. Perhaps the senior official might have tried Google before openly flaunting his/her lack of subject matter expertise. According to a recent Nextgov article, the oldest federal government system is 56 years old (1961) – an IRS system written in assembly and running on a mainframe. The 10th oldest listed in the article is 39 years old.

    I guess, to be fair, some federal systems are 10 to 20 years old, it’s just that many are 50 to 60 years old!

    Why does this bother me so much? The government does recognize the issue, and has made funds available to solve it, but somehow those funds are being drained by companies who are not solving the problem, and who may not even be able to solve the problem, yet are still considered ‘strategic consultants of choice’. Check out the first article I linked to at the end of the first paragraph for more commentary on this and why it is happening.

    Which brings me to the second head shaker from Monday. This was a call I had with the CTO of a large State Government agency. They’re still running legacy COBOL apps on a mainframe and are looking to modernize for all of the obvious reasons (cost, integration, retiring knowledge base etc.). The head shaker was the estimates they had been provided following external feasibility studies, the latest of which suggested 5-7 years to modernize. Yes, 5-7 years, you read that correctly.

    I don’t know how 5-7 years was derived but I do know, a) it can’t have been generated by a subject matter expert (certainly not in application modernization), b) even with tens of legacy apps to modernize it’s a 1-2 year project at most (including moving off the mainframe), and c) it’s a relatively low cost and close to zero risk project.

    Is there even any point in today’s rapidly evolving world starting a modernization project with a 5-7 year horizon? Won’t it by definition be old before it’s finished? That’s a topic for another day. Or at least how to continually modernize.

    If your strategic consultant of choice has provided you with a similarly bleak timeline (and presumably a proportional cost estimate – did they even offer you fixed price?) then we can help you get real. Contact us using any of the facilities on this site to get the ball rolling.

    Categories: Application Modernization Tags: Tags:

    COBOL to MVC – C#/.NET or J2EE/Java

    COBOL Modernization

    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.


    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.

    The Silver Tsunami – Out with the Old and In with the…

    1 Comment
    Silver Tsunami

    …Old. Really?

    One of the few (only?) areas of bipartisan agreement in Congress and where both sides agree on policy, is the legacy modernization of government systems which is now high on the agenda of State, Local and Federal Agency CIOs.

    Driven chiefly by the need to: 1) drive out maintenance and support costs; 2) increase security; 3) increase integration with newer systems; 4) protect against the mass retirement of the knowledge base who originally created these systems (the silver tsunami); modernization of these legacy systems also provides the benefit of moving to the cloud and just generally increasing the functionality available to system users.

    We’re starting to see a significant uptick in the number of RFIs and RFPs from government bodies with legacy languages ranging from COBOL back even as far as assembly language. Of course, there are multiple approaches to the modernization of legacy systems with 3 in particular (Migration, Wrapping and Modernization) being offered broadly and Replace (COTS) in situations where a very close functionality match is available between the legacy system and off-the-shelf solution.

    Just to deal with Replace (COTS) first. There have already been several high profile failures with the DoD, in particular, wasting billions of dollars trying to replace legacy ERP systems yet never quite matching functionality and, consequently, increasing the workload on users. Then there is the cautionary note that technical debt can still be an issue with COTS software – out of the frying pan and into the fire!

    The ‘wrapping’ solution essentially offers enhanced interconnectivity for the legacy system affording some benefits (integration/having the app surface through modern channels such as mobile etc.) but leaving the application as is, or as was and has been since its’ birth potentially decades ago! Consequently, this solution can only be seen as temporary at best and will do nothing to stem the silver tsunami.

    The same applies to ‘migration’ which is the lift and shift approach. For example, migrating COBOL applications from a Mainframe environment to a Windows platform, preserving the original code except for some imposed adaptations, such as the change on the underlying Database Management System.

    This ‘migration’ approach has as its major advantage the potential for a lower immediate cost. As the language does not change, the current technical staff will be able to move easily to the new platform without a significant re-training expense. But it has a lot of disadvantages:

    • There are almost no new COBOL (by way of example) programmers available so, as the current experts retire (the silver tsunami), then the cost of future maintenance of software written in this ancient programming language will increase exponentially over the years.
    • Software written in COBOL is still good for some functions, but it lacks the possibilities offered by more modern programming languages, specifically regarding integration with other new components and technologies.
    • COBOL, as a procedural language, is not as agile as object-oriented languages for modern programming needs such as mobile apps and the Web. It doesn’t support Object Oriented programming, the notion of dynamic memory, concurrency or multi-threading.
    • While re-hosting (‘migrating’) the COBOL applications can get code off the mainframe more quickly, this is often seen as intermediate step only. This means that a future modernization will still be needed, and probably without the participation and the transfer of the currently available experts who provide a deep understanding of the applications business logic, functionality, behavior and specificities.

    In summary, re-hosting COBOL applications to a new platform only postpones the aging problem and denies the modern opportunities afforded by the newer technologies. It can have short term benefits, like reducing training costs, but in the long run the maintenance costs will increase, the integration capabilities will be very limited, and a future unavoidable modernization will have a much higher cost and risk than exists today.

    Adopting this approach will, in our opinion, represent a missed opportunity to evolve to more modern and versatile applications that will benefit both from the ease of integration with new applications and technologies, as well as from the abundance of developers and consultants with knowledge in the target languages and technologies.

    We see ‘migration’ proposed regularly but, for the reasons outlined above, view it as, at best, a bandaid, at worst a shunting of an escalating problem onto future administrations.

    The only responsible solution for both the short and long term (and likely the lowest cost/risk approach) is to modernize now. Watch out for our next post outlining the Morphis approach to taking COBOL applications to an MVC architecture running C#/.NET or J2EE/Java.

    Integritas Solutions to Deliver Application Modernization Services Based on Morphis

    Integritas Solutions logo

    We’re delighted to announce that Morphis and Integritas Solutions have signed an agreement that enables Integritas to deliver application modernization services based on Morphis’ technology platform. This licensing agreement will enable Integritas to independently market, sell and deliver modernization services and resell the Morphis platform.

    Integritas Solutions is a CVE Service Disable Veteran Owned Business that specializes in helping organizations reduce their operating costs and risk associated with transitioning to the cloud by providing a suite of managed cloud services.

    Already providing managed services for AWS and Azure, the addition of application modernization services is a natural extension and lead into these business lines for Integritas.

    For Morphis, the agreement with Integritas is another step towards our desired licensing model. While we continue to deliver modernization services using our own technology, the goal has always been to build the world’s leading technology platform for application modernization and have our partners license that platform and deliver modernization services to their trusted clients in their geographies and market sectors.

    We actually believe we have already built the world’s leading technology platform but there are always improvements to be made and licensing agreements of this type allow us to focus more on software development than service delivery.

    To learn more about the Morphis technology platform and request a demo, please use the form on the left of this page. To contact Integritas Solutions please go here. To discuss becoming a partner with Morphis please use the Contact tab at the top of this page. To stay informed on all things application modernization, please subscribe to this blog down below.

    Categories: Morphis is Expanding
    Get Immediate Access!
    Send My Report >>

    Wait, Don't Leave
    Empty Handed!

    Don't Miss Out On Our Guide To Which Apps To Modernize, Why, And The Best
    Modernization Approach For Each.
    Don't miss out on updates. Subscribe here to receive notifications in your inbox.