I recently reconnected to a former colleague and friend of mine through a social networking site after almost 16 years. After brief messages online, we exchanged phone numbers and planned an informal chat. When we spoke to each other after more than a decade, his first question was, “I hope you are not still working on mainframes!” At first the question irritated me, but I quickly explained to him what I do these days and how the knowledge of various generations of technologies has become critical in the legacy modernization space.
In the early months of 2000, I remember several colleagues advising me to get out of mainframes as they would soon become extinct. The impetus was the switch occurring from a structured language concept to object oriented. Challengers like Java were considered the language of choice for many, and a large number of programmers planned to learn Java post Y2K. This friend of mine was among those who asked what I planned to do after Y2K. I moved from Bangalore to Memphis around that time and gradually lost touch with him.
Even 16 years later, 70% of the world’s code still resides on mainframes. The corporate giants that were trying to expand year digits from two to four are preparing to move into new technologies. The situation hasn’t really changed much since then—hence his question. However, the challenges facing companies have changed. They now include:
- Lack of documentation of an existing application
- Lack of information on the in-scope repository
- Lack of subject matter expertise (application knowledge has often faded along with the developers)
- Difficulty identifying of the number of folders/libraries where source code is located
I recently visited a client to talk about migrating a simple application from the mainframe to an open platform. We picked this particular application to tackle first because it was quite a bit simpler than the three other applications the client needed to migrate.
We soon learned that the code hadn’t been touched since last 10 years due to a lack of application knowledge. To avoid potential production issues when new functionality was needed, instead of making changes to the existing code, a new program was cloned from the original, copied in their own libraries, and never moved to production. This resulted in multiple source codes and multiple libraries, making it difficult to even identify the in-scope source programs.
The next surprise was the amount of missing source code. There were about 100 screens for which there was no source code—we were flabbergasted. Apparently, this application was more of a software package sold to the client by a third party vendor in the late 1970s that doesn’t exist today. They supplied only the maps without the code, so we had to employ a robust reverse engineering tool to develop the code before even beginning the migration.
So, 16 years post Y2K, companies are still struggling with how and when to modernize. The client in this example wasn’t even aware of the missing code until we pointed it out. Every step forward takes years, and we have still many steps to go.
Post Date: 2016-11-28