The following is from “COVID & COBOL” with Paul Barry and George Florentine. It has been edited for length.
Paul:
The COVID crisis has resulted in a huge spike in unemployment claims and brought major IT systems to their knees. The systems can’t handle this huge volume of requests, primarily because they’re built on 50- and 60-year old technology, called COBOL.
Why are organizations still running these COBOL-based systems?
George:
Many of these applications were built decades ago, and they basically work. If you’re looking at modern-day systems, they tend to be built in these things called microservices with very small libraries written in Java script, React, or Angular. Using little building blocks, it’s easy to replace one if needed.
On the other hand, COBOL is one of the languages with the largest number of functions. If you look at a COBOL system with 500 different components all written in COBOL, it runs as one application. If you said to me, “George, replace this COBOL system,” I might say, “Oh my gosh, I have to replace the whole thing at once and I don’t know how to do that and I don’t have people with COBOL expertise.” What I’ll do is just put a little web presence on top of the COBOL app.
You might come to me a year later and say, “Now we need a device that runs natively on iOS and Android.” Well, here’s my little app running on a user’s device. The customer-facing part of the company says, “Great, I’m now providing our customers with what they need.” But in the background, I’m saying, “Oh my gosh, I’m still running on a sixty-year-old piece of technology that might be running on hardware that’s in a basement of an old data center somewhere.” Or even if it’s in a cloud, it’s still very old technology. And I think that’s where we see people today.
Paul:
Why are organizations still using these systems? Why haven’t they been replaced?
George:
Part of it is risk. Everyone’s always trying to understand how to manage the risk. A lot of people think, “Well, the system works. I don’t want to break it. It’s really big, I don’t know how to patch it. Since it’s not broken, there’s low risk.”
People have been lulled into a sense that risk is low. But one of the things that the COVID crisis has already shown us is that good crisis managers do a lot of their work before the crisis hits. You have to start before a crisis occurs on migrating these systems so you’re not doing it during the crisis.
Paul:
What’s the first step someone can take to look at their COBOL-based applications?
George:
The first step is application analysis. It looks at alignment with where your current business is, it looks at classification and understanding what the application actually does. We’ve had customers who don’t even know what their application boundaries are because it’s just this giant pool of behaviors that they’re running.
You need to determine how to move the application forward. And you can start that today. You don’t have to make a big investment in software, and you don’t have to make decisions about how you’re going to archive your data today. But get started on that application analysis and you’ll probably find ways to optimize and ways to free up dollars for innovation.
You must open that scary black box you haven’t looked at in 30 years or that you’ve just been writing little web portals around. Really look into the application to see what you need and what you can turn off.
Paul:
What’s the second step organizations need to take?
George:
The second step is data rationalization. If you look in healthcare, insurance, energy, or financial services, everyone’s wanting to do machine learning. Everyone’s wanting to do predictive analytics, and they want to do historical analysis. To do that you have to understand what the data is. And back in the day when all of these COBOL systems were being built, memory was very expensive. They built this crazy notion that two different parts of the program could look at the same number of bytes and interpret the data differently.
As a technologist, I’m saying, “How can I share that data? I can’t put it in a data warehouse, I can’t do analytics on it because I don’t know what it is.” Different parts of the program are going to look at it differently.
Data harmonization is valuable because once done, you can start taking the older data and move it into your existing data warehousing. You can do machine learning on it and start doing predictive analytics. But until you understand what the data is, you can’t do any of that.
This is where we see some vendors talk about “lift and shift.” They’ll come in, take your existing application, wrap it in some virtualization, and put it in their cloud. They’ll do the assessment for free because they’re going to get an annuity stream from you on the back end.
I’m a little jaded about the “take everything” approach. Our approach is, “Let’s do an assessment, turn off what you can, and migrate what you want to.” You might put some in an archive or lower-cost storage. We also understand that some may be valuable IP that you can’t use because it’s locked in these COBOL copy books, which are part of the program. They’re not sitting in a data dictionary; you can’t evaluate it by any other program until you find that copy book. Harmonizing the data and assessing it is a key next step.
Again, you don’t have to buy hardware to do that, and you don’t have to buy cloud provisioning. You might bring in some consulting expertise to help you with that journey, but it’s a relatively low-cost step you can take right now.
Paul:
To summarize, organizations begin with an application analysis to understand what the application does today and what it needs to do in the future. They’ve looked at the data, they understand how that data is structured, how it can be harmonized and moved into a new application.
The third step is the implementation plan. It’s time to take action. Any action is better than no action. There’s a great quote that says, “Perfect is the enemy of good.” Your plan doesn’t have to be perfect. It should be an iterative plan.
You can adjust as you move forward. You may make some mistakes, you can correct those, you can move forward, but just taking some action is really what you need to do.
We’ve seen organizations gather their business and IT users and get together with subject matter experts, then get a plan started so that they’re not in crisis mode when the crisis hits.
George, any final thoughts?
George:
I would reiterate what you just said. One thing we’ve all learned in the last month is that we’re all interconnected and in a lot of ways that we didn’t quite understand. Whether we’re suddenly needing a surge of investment from the government or whether we’re doing unemployment checks and these systems are not scaled to handle those big changes.
Our financial systems have run well when everything’s pretty predictable. And what the COVID crisis has shown us is the world is still unpredictable. We’ve gotten complacent thinking, “We’ve got this old technology and since it’s not broken we don’t need to do anything.”
In fact, you do need a crisis management plan. You need to start now and not starting is actually risky.
