Following my last Post Steve Heffner of Pennington Systems emailed me a very comprehensive text about his approach to legacy language conversions. He makes some interesting points, so I have decided to post Steve's comments in their entirety.

Steve Heffner's comments in response to my post "Get Out Your Crystal Balls":

Paul,

I agree that fading languages represent a major obstacle for CIOs in moving to more modern IT practices, as well as presenting staffing and maintenance problems.  I also agree that RPG is on that list of languages, along with Pascal, Fortran, and, to a lesser degree, PL/I. COBOL is a different matter.  There is such a huge quantity of COBOL out there that sheer inertia will keep the COBOL ship afloat for a long time.  In addition, recent COBOL standards enhancements have made it a more modernizable language, and COBOL vendors such as Micro Focus are adapting it even further to the brave new world of SOA, Web 2.0, and cloud computing.  (Full disclosure: My company is a member of Micro Focus's Migration & Transformation Consortium [MTC], and we are doing some work with Micro Focus.)

Back to fading languages.  I understand your "no JOBOL" stance, but I also agree with your pragmatic embrace of language translation as a "bridge" strategy. There are a number of reasons for such a bridge:

• To get code out of proprietary languages (or dialects of standardized languages), in order to get it off fading platforms for which maintenance and repairs are becoming increasingly expensive or even impossible to do.
  
• To get code out of a fading language (proprietary or not) for which it is getting increasingly difficult to find programmers -- either experienced ones, or new ones willing to enter what they see as a career dead-end).
  
• To consolidate bodies of code in different languages, perhaps acquired as a result of mergers or acquisitions, and get them into a common language to minimize training and maximize skill sharing, common run-time libraries, etc.

Regarding the "JOBOL" issue, it's true that a straightforward, literal translation of one language to another ends up with results that are neither one nor the other, and likely worse than either.  This is exacerbated by the fact that some language translators produce output that can be very difficult to read or maintain. In addition, application modernization involves much more than just code translation.  The code must be assessed thoroughly before any porting activity begins.  And the port is very likely to involve issues that are not language-specific, such as code quality, a move to a different hardware platform and/or operating system, and repurposing the code to adapt it to a new environment such as SOA.

What does this mean?  It means what you need is NOT a simple, dedicated translation tool, but instead what I call a software engineering "meta-tool", which can be tailored and "tuned" to get the best possible result, including accommodating the vagaries of a particular body of code.  Such a meta-tool must have a powerful rules language you can use to tell it what you want it to automate and how, and that rules language must provide significant leverage, so that a substantial job can be automated with minimal effort.  The rules language must also be usable by any competent senior systems software engineer, not just by mad geniuses hidden in the vendor's back room.

I happen to be the author and vendor of such a meta-tool, named XTRAN.  It is an expert system for the symbolic manipulation of what I call Unambiguously Parsable Languages (UPLs) -- typically computer languages.  XTRAN's powerful rules language allows the automation of virtually any software engineering task involving existing code, with the leverage mentioned above.  XTRAN accommodates a broad range of languages, including many assemblers, 3GLs, 4GLs, XML, and HTML, as well as proprietary, scripting, data base, and Domain Specific languages.

We classify software engineering tasks that involve existing code into three broad categories:

• Analysis -- pulling information out of the code, such as code quality measures, platform dependencies, etc.  This is especially important when assessing code in anticipation of a change, be it re-engineering or translation or both.
  

• Re-engineering -- applying systematic changes to a body of code. Examples include automated code improvement, a hardware and/or operating system shift, a change to a different 3rd-party software vendor's API, or adapting the code to an SOA.
  

• Translation -- changing the code to a different language with the same functionality, for any of the reasons given above.

(Note that "existing code" includes code that has just been created.)

Of course, some software engineering tasks involve combinations of these three categories.  An application modernization effort is virtually guaranteed to involve all three to varying degrees. A meta-tool like XTRAN can be used to automate all of the aspects of application modernization with a single tool, single training, and single skill
set:

• The original system assessment, which (especially for large bodies of code) must be automated as much as possible in order to reduce it to a manageable task and allow as much analysis as possible.

• The re-engineering needed to repurpose the code, be it a platform shift or adaptation to SOA or Web 2.0.

• The re-engineering needed to improve the code's quality, either before or after any porting activities, to minimize ongoing maintenance effort.

Translation that may be needed to move the code to a modern, standard, and portable language. You can try to cobble together a tool set from different vendors' "point solutions" for analysis, modernization, and translation.  But you will inevitably encounter both gaps in tool coverage and mismatches among tools -- the output of one doesn't fit the input requirements of another.  With a meta-tool's rules language, you can create your own tool set, with no gaps and no mismatches.  And the leverage provided by a good meta-tool means that you can do this with reasonable effort.  Not only that, but the resulting tool set is yours; if you're in the software services business, this can represent a substantial competitive advantage.

One reason automation of the software engineering work is so important is to minimize the introduction of bugs during the activity resulting from human error.  In other words, the more you automate, the less debugging you'll have to do.  For large projects, this can even mean the difference between success and abject failure.

Even after the modernization effort, a meta-tool such as XTRAN can be used to automate ongoing software engineering efforts such as monitoring (and perhaps remediating) adherence to quality standards or coding conventions, as well as providing occasionally needed ad hoc analysis and re-engineering automation.

Even if a decision is made to scrap an existing application in favor of off-the-shelf software, a thorough assessment of the existing system must be done to ensure that you know what you must replace.  Many functional specifications are woefully stale, if they even exist at all.  It is critical to understand what your systems do before trying to modernize or replace them.

The current economic distress will motivate a lot of CIOs to try to do more with what they've got, to minimize ongoing costs, to adapt their current systems to new needs, and (most importantly) to improve their IT systems to provide the business agility mandated by the speed of market change in the Internet age.  All of these goals call for automating the software engineering workload as much as possible.

For more information about my company, XTRAN, and me, please visit WWW.Pennington.com.