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.
Happy COBOL Coding!
Posts
