Next to our Bangalore office, there used to be a small tea shop selling tea, cookies, bread, newspapers, and so on. Some of my colleagues and many students from a neighboring college were regular customers. One day when passing by, I saw the owner had begun renovating the shop. There was hardly any space to stand inside, and it was extremely noisy and dusty. A few days later, I noticed that the shop had closed; it was simply too difficult to manage the renovation and keep the business running. Of course, the shop forfeited considerable revenue each day it was closed.
This series of events occurs frequently with companies as they attempt to modernize applications. I have seen clients send out an RFP to modernize a certain application, with aggressive timelines. Incredibly, the same RFP (with a revised timeline) arrives again the following year. Every year, the project fails to begin—unlike the tea shop, the application is too important to be shut down while modernization occurs.
Part of the problem is that the original application documentation was written many years ago, without subsequent revisions to the architecture information. Over the years, it changed with the arrival of newer architects, newer technologies, and enhancements needed to accommodate newer business requirements.
One company I worked with had attempted to modernize an application written in VB6 using mainframe (CICS) transactions to Java. I wondered if someone thought VB6 was a cutting-edge technology. How were they to know that the technology they had used would be declared legacy late in 2008 while the one they had replaced would be still be around and looking for a new partner?
In the late 1990s, instead of trying to replace COBOL, Microsoft created a new concept and language that changed traditional business into web business. COBOL was a real transformation for most enterprises during the time when 3GLs ruled because it was one of the first 4GLs that enterprises used. Microsoft intended VB to be simpler to use so that programmers could create both simple and complex GUI applications. Because maintenance of CICS screens posed a potential threat, VB6 (with its ability to create web-based applications) would have been chosen at that time.
Some of the applications developed in PowerBuilder in early 1990s would have had a similar route to VB. Although Sybase released a major upgrade to PowerBuilder in 2010, with support for the Microsoft .NET Framework, it couldn’t survive for long, either. Sybase announced its discontinuation in 2011 and ended support in 2012.
There are still some companies working to migrate applications to COBOL. For example, VisualAge PACBASE is an application development tool that generates COBOL code. However, the generated code is difficult to maintain without structured statements, potentially becoming costly in later generations.
One pharmaceutical company I worked with that boasted of making multiple technologies live in harmony suffered a major issue during its modernization project. It was a legacy application written primarily in MF-COBOL/ISAM database, interfaced with multiple technologies—eventually making it extremely difficult to migrate into a common platform.
The bottom line is that even though all of these decisions felt right when they were made, considering cost/need/competition, we don’t know what technologies are coming or how quickly they’ll fall from favor. Keeping your architecture modifiable and easy for the business to run is the only sure way to ensure you don’t run into the renovation conundrum of our tea shop owner.
Post Date: 7/28/2016