Introduction
Human nature has a strange way of not letting a person. Recognize valuable information or ideas, even when they are right in front them. Advertisers and sales people are always trying to draw your attention away from your current interest to the ‘newest’, ‘latest’ or ‘most innovative’ bauble. You and your company have a very valuable corporate asset that’s been in place for a number of years, silently working in the background to make you and your company profitable: your COBOL based applications.
Now bear with me, I know what you’re thinking “COBOL??? You have GOT to be kidding!”. Yes, COBOL. Whether you “speak” Java, C#, RubyOnRails or any of the other newer languages consider what it is your COBOL applications have been doing all these years, what you’re looking for in a new or replacement application (or language) and the estimated costs of replacing those COBOL applications in terms of both effort and risk. There is significant value in the applications that have been running your business.
Silent Partner
COBOL has been a silent partner in your company’s success. It has been providing information to you day in and day out for too many years to remember. Yes, it’s old but honestly. So what? It is still doing the job for which it has been designed for, to process data and provide a competitive advantage to you. Yes technology has changed and you keep hearing “COBOL can’t do that”. The truth is it probably can but more on that later. So COBOL has been processing the data it’s been receiving all these years, analyzing it, generating reports and keeping the lights on for your organization. The people who designed and maintained the application(s) may have moved on to other companies, are retired or in worst case have passed on. Yet the COBOL application they created is still doing its job and you want to replace it with ‘the shiny new bauble’. Why?
What does that bauble have that COBOL doesn’t? Is it a new user interface? Is it the ability to support web services, including JSON and REST based services? Is it the ability to process XML data or access .NET or JVM classes and extend your applications reach to these new platforms? Are you trying to get to a mobile platform? If you answered ‘yes’ to any or all of these questions then you need to take another look at COBOL. All of the technologies or techniques mentioned are supported or obtainable from your current COBOL application. The key is knowledge and being able to research the capabilities of the language, which is where IBM and Micro Focus come into the
picture.
Skills Shortage
All the CxOs of your organization, and perhaps you as well, have heard is “COBOL can’t do that” or “COBOL is dead” or “no one is teaching COBOL anymore”. Some companies have had advertisements out for COBOL developers for months and haven’t had a single qualified applicant. They interpret this as validating the information they’ve been hearing all along, that COBOL is indeed
a dead language. This however is far from reality.
Two of the largest COBOL vendors in the world, IBM and Micro Focus each provide a wealth of training scenarios. From basic language courses to more advanced topics in integration with the new technologies. The IBM approach is more mainframe centric and can help you get new developers up to speed and productive in a short period of time. Micro Focus can also provide training for the mainframe centric developer but it can also provide training for those developers working in a distributed environment and looking to access new technologies such as .NET or JVM frameworks. Additionally Micro Focus has created an academic alliance with secondary education facilities around the world to help those institutions teach COBOL.
Rather than trying to hire a ‘COBOL programmer’ why not look for a developer already familiar with Visual Studio or Eclipse? New developers coming out of technical school, college, or existing developers looking to make a change in their career know one or in most cases, both of these development environments. The biggest obstacle, objection, learning curve to learning COBOL has been the environment in which it was maintained in. This should no longer be an issue as both Micro Focus and IBM have adapted the Eclipse environment and Micro Focus has even extended the development experience to Visual Studio.
Developers already know these IDEs, they know how to manipulate the environment and are generally already productive in it. So a significant part of the learning curve has just been eliminated. So what’s left? The language.
Parlez-vous français?
While I do not speak French I can understand the basic constructs of the language, common phrases and can decipher enough to ask for help in translating it to English, which is my primary language. I can do the same for German and Russian. In actuality, anyone of us can do the same. We learn a primary language and through necessity, want or influence learn additional languages as we grow in our lives and expand our circle of friends and co-workers. The same can be said for computer languages.
I am a COBOL developer at this point in my career. I didn’t start out that way, but I learned it. The very first language I learned was Pascal. I then went on to Visual Basic, COBOL, JCL, SQL, SAS, CICS, REXX, Windows Scripts, VB.NET and finally C#. I am more fluent in computer languages
than I am in spoken languages. What is the difference in all of these languages? Syntax. As a developer I know and understand how to formulate a series of expressions into a comprehensive set of instructions that instruct the computer to perform a series of tasks to complete a unit of work. Regardless of the language, the underlying logic flow is very similar in all circumstances. HOW I choose to implement the requirements is based on the environment in which I am running in. I may be coding a series of expressions in C# in the morning and a different set of expressions in the afternoon in COBOL. The language used is determined by the environment being employed and the requirements of the request. One constant though in all of the languages noted above is Visual Studio. I use Visual Studio for all my coding.
Any developer in the workforce today knows at a minimum three programming languages. These are dependent on the environment they are working in, but at a minimum, three languages. They can switch between these languages with ease (ok, you may have to stop a second to think about the
syntax) and complete tasks quickly and efficiently. Why can you not add COBOL to that mix? You already know your development environment. You already are multilingual. You can adapt to the requirements of the request. You can learn COBOL and you can become a more strategic resource to your organization while expanding your career into areas never dreamed of. COBOL truly does run the world of business and you can help integrate it with the new technologies available.
COBOL: No longer a silent partner
COBOL has come a long way with new syntax, new interfaces, new techniques that could enable your application to take a drastic step forward. Instead of trying to replace COBOL, why not work alongside it to achieve rapid, stable results for you and your company?
You didn’t know the languages you are working with today, you learned them through spending time and writing code. Spend some time and write some COBOL code in Visual Studio or Eclipse. You’ll see you can do it and you may even say it wasn’t that bad.