Let’s start with the basics…
How many of you reading this, feel trapped by a system that was created in the 1980s or earlier? How many of you feel that it is a necessary evil that you have to deal with day in and day out?
Here’s my next question: why? Why do you feel trapped by your legacy system? This is always the first question to my federal clients and their answer is always the same: “Our business runs on this system and without it we would not be in business.” This answer always surprises me because there are life rafts out there that can rescue you from what seems like an endless battle for survival.
Legendary. Not Legacy.
First of all, I would like to take the time to explain that here at Micro Focus, we do not view our customers’ ‘legacy’ systems as legacy. Personally, I feel this word has an extremely negative connotation and that it’s an incorrect term for the system. I would challenge you to think of it as legendary, in the sense that it maintains a company’s code that enables them to have a competitive advantage over other companies within that business sector. These legendary systems are “the core of my business,” as most North American clients would adamantly state.
COBOL is the predominant language within these complicated and intricately woven applications that are the lifeblood of many major corporations, government agencies, and numerous other companies ranging in a variety of sizes. COBOL seems to have acquired a negative connotation, which I think is because the maintenance of this vital system is often so overwhelming that organizations cannot even begin to think about innovation. Think about it: we’re talking about government systems that decipher what your taxes are, what your Medicaid payout is, social security benefits, etc. But really, how can you even begin to think of innovation when you spend all of your time just maintaining a static system?
Make the change.
This is where the thinking needs to change. COBOL, in case you didn’t know, processes more transactions daily than there are Google searches. It’s an important language that supports many mission critical applications. COBOL, for many industries, was seen as a highly portable, agile, readable, and robust language that could create a secure application. However, with advances in technology and the creation of new languages, COBOL has now taken a back seat and is seen as a far less popular language to develop in. Sometimes, businesses even choose to take on a rewrite (75% of these fail) or choose to buy a commercial off-the-shelf package that gives some, but not all the functionality they had with their homegrown COBOL application.
Shake things up.
Breathe. You can get back your freedom. What if there was a solution in which you could repurpose your COBOL code and integrate it with a modern language? Hard to imagine, right?
The truth is, Visual COBOL can enable you to do just that. You no longer have to struggle using an old hard-to-read system. Visual COBOL delivers the next generation of developer tools for the COBOL developer. In using industry standard IDEs, Visual Studio and Eclipse, you can now repurpose your COBOL application and integrate it with your choice of Java or .NET. However, what I find to be more remarkable about the solution is the ability to not only increase a developer’s efficiency when coding but the fact that it can help tear down the walls between different teams of developers. I mean how many times have you seen the COBOL developers sit in a different section from the Java guys or the C# guys? Well that no longer has to happen. You can all sit together and use the modern IDEs to gain better team collaboration and communication.
COBOL cuts costs
Cost is often another driving factor that keeps the legacy system as is. However, through modernization of these COBOL applications, Visual COBOL helps you to deploy your application to a wide variety of more cost effective platforms such as UNIX, Linux, and the Cloud. Instead of going through a rewrite, Visual COBOL enables you to retain your business logic and create a more modern application without losing the competitive edge the business logic provides. This cuts out the extensive cost of a rewrite or a package solution.
To conclude, I’d like to challenge you to think about your options. I challenge you to see the vitality in these legendary core government applications and the ways you can repurpose them into a modern and agile application of the 21st century. Do you want to keep maintaining a legendary system that you feel you have to deal with? Or, do you want to transform a system that has been running your business since the 1980s into a system that will continue to help grow your business and innovation far into the future?