Cybersecurity in the government has certainly come into focus recently as we have witnessed sensitive document troves exposed on WikiLeaks along access to government information from transaction systems. Perhaps the most serious of the latter was the 2015 incident in which the Federal Human Resources database was hacked for more than 22 million records containing sensitive personal information such as Social Security numbers. In this incident the source of the problem was 30-year-old mainframe software written in COBOL that was too technically obsolete to encrypt personal information. This raised the discussion of legacy system security to a new level.
When it becomes apparent that legacy code must be replaced, modernization is often the best possible strategy. With code modernization it is possible to refine the original code and bring it up to modern practices, as well as integrating it with existing software. One of the problems with modernization, however, is that critical applications tend to have thousands of lines of code and a manual rewrite is often impossible. To re-create the software requires a project of similar magnitude to the original development; to leave most of the code intact as a “black box” and build around it results in numerous security issues and inefficiencies, as well as inability to leverage emerging technologies.
In addition to performing documentation, transformation, and refactoring tasks all in-house, TSRI offers the ability for partner organizations to tap into TSRI's ability to parse legacy applications into an intermediate model stage--what we call Common Model Exchange. This provides you with the ability to use your technology against applications written in any of the 32+ legacy languages that TSRI supports, at any stage during a code documentation, transformation, or refactoring project.
If you've ever seen the MUMPS language (used by many healthcare applications in the federal government), it's not the easiest language to understand. One of my colleagues describes it as looking like "a cat walked across the keyboard". Modules are represented by numbers, so "laboratory" might be 332 and "x-ray" might be 497. That's only the beginning.
Modernization of code demands a high degree of precision. It is absolutely critical that the reengineered software performs in the same manner as the original. This requires two things: a rigorous approach to code refactoring based upon tried principles which retain the underlying logic; and a well-planned and consistent program of testing to ensure that logic is preserved and improvements do not in any way alter the function of the code. Testing is vital. Companies need to be certain that their modernized critical software will perform according to exact the same rules as the original.
Code modernization can create some interesting problems these days as business and government attempt to upgrade legacy systems. The route ahead is not always clear. Legacy systems may be in a variety of different languages installed for different purposes to meet the needs of the time. Even the transformation target itself can be problematic. Whether code is better translated into Java, a C variant, Python or something else demands consideration of the environment in which the code will reside, its interconnections, as well as the characteristics of the output language and its suitability. Economics rises as an important issue with older or obscure languages that do not have a breadth of available talent.