Should You Panic Over Federal Government Legacy Systems?
The US Government Accountability Office released a report about legacy systems that various federal agencies still use…including one mainframe-based system used by the Treasury Department coded in assembler. Sounds scary, especially when Ars Technica headlines it as “Government agencies keep sacrificing cash to zombie IT systems, GAO finds”, right?
Well, if it’s that scary, then you should close out your bank accounts, credit cards, and insurance to name a few sectors that still use mainframe at the core of their business processes. We tend to see a system gain a number of years on it as “old” and “obsolete” since technology does change constantly. Mainframe systems are viewed in a negative light mainly because they’ve been around for so long and continue to do their job (mass transaction processing) quite well. In fact, the mainframe continues to evolve to keep up with the pace of technological change and the growing demands of mobile technology.
That’s not to say that these systems can run indefinitely. Things break. Weird things happen when you put data in the wrong place, and you need people who are knowledgeable about the business function and systems in order to maintain a happy, healthy system. It doesn’t matter if it’s on a z Series mainframe, Windows box, Linux box, or Mac box.
One thing the GAO report does point out is the lack of skills necessary to maintain these older systems. COBOL, High-Level Assembler (HLASM), and other mainframe skills aren’t cutting edge and they’ve been around for a while. Of course, the UNIX operating system (which Linux and Mac OS both owe their lineage to), C programming language, and Objective-C (which, until recently, iOS applications used as their base language) have been around over 30 years.
The lack of skilled talent is a symptom that affects both the public and private sector, and it’s something that both our education system and private industry should be working in order to fill the talent gap.
Technical systems need to be updated for sure (ain’t nobody using 8″ floppy disks any more), but I would be cautious of folks promising huge cost savings from converting tried-and-true legacy systems to “modern” platforms. It’s an expensive process that may or may not have a long-lasting total cost of ownership. Remember, it’s still your money at work.
Of course, Lawton suggests letting the brainiacs at GA Tech take a whack at it, but I’m sure they’ll just say “send it to the cloud.”
Now get off my lawn.
Add a Comment
You must be logged in to post a comment.
Assembler?!?! I used to code that.
I don’t get too hung up on the programming language used and short of the old open disk packs (ask your daddy) I once spotted the state still using in the nineties I don’t get too hung up on antiquated hardware. But antiquated operating systems present a cornucopia of problems with both human and equipment compatibilities. Most decent coders can intuit COBOL and the like fairly quick though I admit trying to glean the nuances out of a couple of million lines of code done by people long retired can be a challenge. But when the manufacturers of hardware have ceased support of an OS for a decade or so it makes it near impossible to attach modern peripherals people have come to expect to be able to use. Writing your own code to get a job done is one thing, writing your own interfaces can quickly become self defeating.
It’s not just limited to government. Windows XP was used for a lot of embedded systems. I’m sure (or hope) a bulk of those systems were upgraded, but I wouldn’t be surprised to see some systems using the embedded version of Windows XP. Heck, an airport in France did have/still has its air traffic control system running on Windows 3.1.
Learning syntax isn’t the challenging point. Just as you pointed out, it’s trying to understand other people’s (or computer converted) code that can be undocumented. I suspect that IBM is going to continue to upgrade z/OS as well as its version of Enterprise COBOL and HLASM as long as they have customers for it.
The benefit of cost savings from efficiency may not be the big ticket. The big ticket may be cost savings from identifying human misbehavior, fraud, error, mismanagement, directly and via lack of integration in the systems.
This is a big reason the VA has so many problems. The migration is not easy with old systems.
https://www.besttechie.com/va-hospitals-use-outdated-ms-dos-operating-system/
I appreciate this IT coverage.