Why Software Vendors Care About Mainframe COBOL

Consider this quote from none other than Bill Gates:

"As a result of the changes in how businesses and consumers usethe Web, the industry is converging on a new computing modelthat enables a standard way of building applications and processes to connect and exchange information over the Web." ^[1]

In other words, the way we build business programs needs to change with the times. On that point, the other major software vendors appear to agree with Microsoft. Where they seem to differ is in their strategy in accomplishing this goal. The way I see it, they each have unique challenges. The traditional mainframe product vendors are more likely to have established relationships with customers that are already using COBOL. I imagine that these loyal customers are asking vendors such as IBM questions like "Will I be able to build tomorrow's Web-enabled applications using your COBOL development tools?" and "What are you going to do to help me leverage my existing COBOL investments?"

On the other hand, Microsoft's challenge appears to be a bit different. Their challenge is helping two sets of customers with different needs. One set of Microsoft's customers has already left the mainframe and started developing Windows and Web applications both with and without COBOL. Those customers, now using nonmainframe tools, need to get closer to what they left behind: their legacy data, legacy business logic, and legacy talent pool. The other set of customers are actually future, potential customers ”those contemplating a mainframe departure .

I suggest that neither Microsoft nor the other software vendors can ignore the fact that a windfall awaits the software/hardware vendor(s) that successfully taps the legacy-application market share. The legacy-developer talent pool is an attractive grassroots approach for entry into enterprises looking to take advantage of existing IT investments. That's right. You, I, and the billions of lines of legacy code that we helped write are now considered to be a commodity, and a very hot commodity at that.

Note	According to published estimates from the analyst firm Gartner, there are approximately 90,000 COBOL programmers in the United States and roughly 180 “200 billion lines of COBOL worldwide.

Cross-Reference

For further general information about the new appreciation for COBOL, read the Computerworld article titled "Remember Cobol? If You Don't, Get Reacquainted" ( http://www.computerworld.com/softwaretopics/software/appdev/ story/0,10801,60683,00.html ) and the Micro Focus press release titled "Micro Focus Announces Support For New COBOL 2002 Standard" ( http://www.microfocus.com/press/news/20011127.asp ).

Many scenarios can unfold, all of which are aimed at getting at this gold mine. Companies will, in some cases, rewrite or convert their legacy applications under the guise of leveraging their existing investment. On the other hand, some companies will choose to replace their mainframe legacy applications with desktop and Web solutions written for and processed on nonmainframe platforms in search of ways to reduce their total cost of ownership (TCO). This latter approach sometimes includes techniques referred to as wrapping and screen scraping. Wrapping is the common process of including legacy modules within a component written in newer technology. Usually hiding the older module, the newer component is then integrated with other new components . Screen scraping is the common process of programmatically accessing, navigating to, and "reading" from online "screen" applications. Although they are slightly different, these two techniques can be found on either the mainframe or nonmainframe platforms.

It is a fact that the COBOL language is radically evolving ”it has to. Here, I am attempting to answer the question of "Why?" You may disagree with my theory of corporations scrambling for market share and striving to please existing customers. Perhaps I could have taken a more plausible route. Suppose that the COBOL vendors are doing what is necessary to actually secure the continued existence of COBOL development and therefore their own corporate existence. In their individual and joint efforts to save the language, they may have actually sounded COBOL's own death knell.

Note	Please take a moment and read the previous paragraph again. Ponder that thought for a moment. Please read on.

Regardless of the motivation held by the various COBOL vendors, the fact remains that something is happening. COBOL, as we know it, is not just sitting still. Let's now explore the vendors' efforts to bring COBOL forward into the twenty-first century.

^[1] Bill Gates, January 14, 2002 ( http://www.microsoft.com/net/defined/net_today.asp ).