…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.