Automated Refactoring of a U.S. Department of Defense Mainframe to AWS

I wonder what 1 million lines of COBOL translated to Java looks like.<p>Let us stop and give some caring thoughts to the people who will maintain that code base.

I see this happening more and more. And for me, it was my guess at why IBM bought RedHat, since the government was likely moving off an IBM solution this allows IBM to still &quot;own&quot; the platform (RHEL + IBM Java) and I presume at some point they will try to own the cloud as well.<p>It was interesting while I was there helping to transition the Blekko stuff to IBM I brought up how this sort of modernization of their cloud offering was in their strategic interest. IBM is so big, and so complex internally, it was kind of like shouting at a crowd moving through Grand Central station in New York. People can hear you shouting and slowly start to comprehend what you&#x27;re trying to get them to see. Change is hard in an organization of that size.

It will be interesting to see how this works out, but I doubt we will hear much publically about it again.<p>I have been involved in a somwhat similar project where we had a large system written in an obsolete language. It was HUGE. And it ran fine. With millions of transaction. But it required expensive hardware to run it.<p>The decision was made to convert it to Java. The effort took years, and the rend result was not impressive I thought.<p>In a lot of ways Java was a step down in abstraction from the more DSL original langauge. Implementing new rules took more time, and running it took a lot more orchtecstration.<p>I am not convinced that it would have been better to hire and train a few devs in the old system and let it keep doing its thing for a few decades more.

I am impressed with this solution, insofar as was described in the press release. But I also have concerns.<p>My concerns mainly lie with choosing such a proprietary solution over one using more open-source standards. Both in the language selected, along with the backend (Oracle and AWS) being used.<p>Will there or could there be problems in the future, should the need arise to migrate off one or more of those proprietary platforms?<p>What will or could happen if there is a security issue that affects or targets AWS, Java, or this system in particular - are we &quot;stuck&quot; again with a potentially &quot;broken&quot; system that can&#x27;t be easily moved because of vendor lock-in of sorts?<p>Should Oracle make further moves in the direction of &quot;closing&quot; Java - will programmers continue to learn the language and support it, or will they move to other, more open, solutions?<p>What happens if or when AWS or Amazon ceases to exist?<p>I just wonder if we haven&#x27;t traded a largely unwieldy but mostly known issue of a mainframe and COBOL, for a seemingly known (but questionable) issue of AWS, Java, and Oracle.<p>Will we just revisit this whole problem again in 50 years?<p>If so, maybe then we&#x27;ll make a better decision to use more open and auditable solutions (but I&#x27;m not going to hold my breath to that)...

Was this based on the work one IRS engineer did?<p><a href="https:&#x2F;&#x2F;federalnewsnetwork.com&#x2F;tom-temin-commentary&#x2F;2018&#x2F;01&#x2F;irs-clutches-its-modernization-holy-grail&#x2F;" rel="nofollow">https:&#x2F;&#x2F;federalnewsnetwork.com&#x2F;tom-temin-commentary&#x2F;2018&#x2F;01&#x2F;...</a><p>edit: Added link to patent application.<p><a href="http:&#x2F;&#x2F;www.freepatentsonline.com&#x2F;y2018&#x2F;0253287.html" rel="nofollow">http:&#x2F;&#x2F;www.freepatentsonline.com&#x2F;y2018&#x2F;0253287.html</a>

I&#x27;ve worked on a similar project, we tested two different approaches:<p>Recompiling the COBOL codebase on Linux and accessing and loading it as shared objects (via JNI for JVM usage)<p>Running Hercules ( <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hercules_%28emulator%29" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hercules_%28emulator%29</a> ), an IBM mainframe emulator<p>The first one has lots of merits, as it allows for a progressive replacement of COBOL functionalities<p>The second one immediately lowers the TCO for obvious licensing reasons but does not plan for the future, particularly as COBOL developers retire and thus the resources are scarce.<p>(Anecdotally the customer chose both: recompilation &amp; progressive replacement by Java code for core assets and emulation for &quot;dead&quot;, non core, assets dev &amp; staging environments)

Here&#x27;s the main problem with this: Where are the requirements?<p>The COBOL doesn&#x27;t have automated tests. When you port the COBOL to Java (whether automated or manually) you aren&#x27;t asking &quot;where are the original requirements?&quot;. Contrast this with a &quot;re-write&quot;. When you do a re-write you have to go back to the customer and whatever documentation you can find and figure out and re-document what the system should do. This can be far removed from what the system did in its original design docs, and can differ still from what people believe.<p>This step of codifying tacit knowledge of the behaviour is important in the evolution of systems.

The system is the specification. Working software that is 65 years old is an organic and evolved entity that can&#x27;t be manually ported or updated.<p>Another possible target for this is the IPPS&#x2F;OPPS Medicaid&#x2F;Medicare code calculator system - which was written in COBOL for IBM 370 by mostly a single developer. Sadly, the developer passed away about 10 years ago, and the system has yet to be updated. The code was open sourced in a bid to gain assistance for updating from the community. Automation such as this would help significantly.

I&#x27;m surprised that automatically translated Java code would be easier to maintain than human-written COBOL. Doesn&#x27;t it become difficult to understand? I suppose 50 years old COBOL is basically as cryptic as auto-generated Java...

Very interesting write up, especially for what one might expect to be straight up promotional piece. It&#x27;s nice to hear that amazon can guarantee the necessary uptime to run a system of such importance.<p>It&#x27;d be interesting to compare this approach to modernization approaches in the government. For example the veterans administration is moving away from their ancient but popular and decently well regarded electronic health record system Vista (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;VistA" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;VistA</a>) to cerner.<p><a href="https:&#x2F;&#x2F;www.hitechanswers.net&#x2F;va-establishes-office-of-ehr-modernization-to-support-transition-from-legacy-patient-data-system&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hitechanswers.net&#x2F;va-establishes-office-of-ehr-m...</a>

Dumb question - how automated is an automated solution that &#x27;refactors COBOL to java&#x27; in 18 months? Impressed with the solution &#x2F; outcome.

We migrated the core banking from a small private bank, and that was 12 million COBOL lines. It actually seems like a &quot;small&quot; system. We used the same approach (java translation). Running the cobol is actually the easy part. The hard part is when you start throwing in managing files the mainframe way, the database (needs to quack like DB2), the transaction monitor (CICS), presentation layer (3270 like), scheduler, etc. And there is plenty of other technologies usually deployed in such shops (IMS, MQ, etc). And you need to support it all...

&quot;Refactor Redundant Code to remove code redundancies&quot; in the Phase 2 diagram was pretty great. I hope that was intentional.

&gt; At the end of Phase 1, the Java program is “dirty” with remaining COBOL coding practices. At the end of Phase 2, the Java program is “clean” without COBOL remnants.<p>Great use to match up with the dirty Java logo. I’m sure they had a lot of fun designing that, and this dirty&#x2F;clean terminology will probably stick in other source to source transformations.

Alternate title: How the DOD was locked into depending on single vendor<p>(this rarely works out well for taxpayers in the long term..)

What is &quot;architectural future state requirement&quot;? Why didn&#x27;t the emulation idea work? Isn&#x27;t that the industry standard for moving old code to new hardware?

Amazon, and AWS in particular, sure seems all in on building technology for the military and police.<p>Anyone else experience some cognitive dissonance in &quot;the world&#x27;s most customer centric company&quot; also someday powering the facial recognition systems used by customs, border patrol, police, and military systems?<p>It seems ripped straight of a cyberpunk novel to me.

My main question is why this can&#x27;t be done incrementally? The system can almost <i>always</i> be broken down into functional areas? Does Agile here just not apply?

From a national security point of view it seems a few well placed bombs in about 10 data centers will take out most of the US computing power.<p>I&#x27;m a bit surprised DoD encourages the consolidation, though maybe once the software is cloud enabled it will be more portable to small sites in the future.