|
Videos
November 15, 2011 By Matt Williams
Colorado’s computer systems — old as they are — aren’t out of line compared to other state governments. Rather, national data show that Colorado’s oldest systems — the ones Russell said are more than two decades old — are in the middle of the pack among systems operated and maintained by other state governments.
A study of states’ unemployment insurance (UI) systems made public last year by the National Association of State Workforce Agencies reported that most of them were first built in the 1970s and 1980s, and haven’t been modernized significantly since then. These systems, which collect unemployment taxes from employers and determine eligibility and pay unemployment benefits to workers, are in many cases considered separately as “tax systems” and “benefits systems.” A state government’s average benefits system, as of last year’s data, is 22 years old, while the average tax system is 24 years old, according to the study. The oldest of these systems, as of 2010, were 41 and 42 years old, respectively. Only eight states had modernized their systems, meaning they can fully support Web-based features and current database technology.
Before and after the Y2K scare, many states installed new enterprise resource planning (ERP) systems, which integrate a variety of business information, such as accounting and human resources data across a government. But 10 years later, even some of these systems are beginning to show their age. Several states are still running financial systems — which are often a part of the ERP — that were first implemented in the 1980s or 1990s, and may not have been heavily customized since then.
Old systems are found in all state governments, irrespective of geography. New Jersey’s payroll system, for example, dates back to 1969, and the state’s Motor Vehicle Commission uses a mainframe system that’s 30 years old — prompting New Jersey Gov. Chris Christie to float a $60 million plan for upgrades. Meanwhile, Arizona’s state financial system, which is used by 90 percent of the state’s agencies, is 25 years old. It runs on an IBM mainframe and uses the old COBOL and DB2 programming languages. Arizona has hired a consulting firm to help upgrade to an ERP system.
Utah’s MMIS is more than 20 years old and also runs on COBOL. “That’s the one we’re looking at [modernizing],” said Utah CIO Steve Fletcher. “The federal government pays for 90 percent of it, but it’s still very expensive — $120 million to build a new system.”
Installing new modules in the old MMIS is difficult for Utah to do, Fletcher said, because it’s trying to force COBOL to do something it wasn’t designed for. To make matters worse, the people who know how to code in COBOL are disappearing as they reach retirement age. “You spend an inordinate amount of time coding it and you spend an inordinate amount of time testing it. The cost for development becomes rather exorbitant,” Fletcher said.
Delaware CIO Jim Sills said the state’s top 11 mainframe systems average more than 20 years old and nearly half of those systems need to be replaced. Supporting those systems is difficult because the technology is old and so are the people who know how to maintain them. “I call it the ‘silver tsunami,’ a maturing workforce that will not be around to support these systems,” he said.
The looming wave of retirements expected among senior IT staff is no secret, as it’s been projected for years. A study released in January by NASCIO concluded that CIOs expect as much as 30 percent of their staffs to be eligible to retire within the next five years.
A loss of expertise is only one of several factors making system replacement an urgent priority. Other motivators are the promise of improved security and upgraded systems capable of pushing data out in order to support transparency.
Dave Andrews, who heads Accenture’s state and local government ERP practice, has been in the business since the 1980s. As the years went by, he came to believe that state governments would get a maximum of 20 years from their big systems. In reality, states held out even longer. “Would somebody out there be surprised to learn that there are systems that are 30 years old running the business of government? Yeah, that would surprise people,” Andrews said. The general public would be amazed by the amount of paper that still flows through government, and the “green screen” computer terminals still relied upon for back-office work, he said.
“We’re not replacing systems that are client-server or Web-based systems. We’re still replacing the mainframe systems,” Andrews said. He made the observation as he was visiting Richmond, Va., to meet with the controller about a 30-year-old KPMG green-screen system that’s still utilized by the agency.
You may use or reference this story with attribution and a link to
http://www.govtech.com/policy-management/CIOs-Seek-Ways-to-Replace-Legacy-Systems.html
in what way is the print icon on this page useful? It sure would be nice to get all of the 5 page story in one browser window.
Good article overall. Not really any earth-shattering news for those familiar with government systems. One glaring omission is how government salaries for IT pros have lagged far behind private industry. This causes the lack of new blood to come into government work. Also, the focus needs to be on how to better meet business needs than on how to replace mature systems, or you could replace your 1995 Mercedez with a 2011 Yugo!
Fix it because it's not working, not because it's old! Btw, how old is old?
We fly aircraft that are significantly older than these IT systems and operate them safely. Somehow we manage to maintain old aircraft and find pilots to fly them. Sounds like IT has a management problem. There's nothing wrong with expecting a young programmer to learn COBOL and IBM High Level Assembler. Management needs to see to it that training in those languages is available. Colleges will teach subjects that help their graduates find jobs. Management needs to work with college administrations to make them aware of their needs.
Everytime someone wants to justify spending millions of dollars on replacing "old systems" they serve up a story like this. They never mention that the mainframe computer that the "old code" runs on is usually only a few years old (system z), it probably has a modern enterprise-level database (like DB2)and it can easily have a modern web 2.0 presentation layer added through websphere and javascript code. Also any good coder should be able to write both procedural and object-oriented code.
Age of the system means absolutely nothing. What is important is how it was written and how it's been maintained. This artile leads the reader to believe any system older than 10 years is useless, has never been changed, and must obviously be tossed out. Old COBOL code was being replaced by new VB6 10 years ago. Today that "New" VB6 code is unsupported by Microsoft and has to be replaced. While that "Old" COBOL code would still be supported by IBM.
Mainframe technology has become underappreciated. Sure relational databases add a dimension beyond flat record structure and java / web interfaces have lots of flash and dazzle - but don't be fooled, ANY system is going to require maintainace support. Interfaces to older systems should not be dismissed if they suit the business need. THAT is what the focus should be, not merely upgrading just because newer whiz bang stuff exists in the market. But look at where Ms. Russel comes from, private industry, of course she will have this perspective - and its not necessarily bad, as long as upgrades are really necessary and cost effective. Sharing systems among states has been going on in pockets here and there for some time already. The best fit is where systems are similar and flexible enough to allow for state law differences. I'm not saying change isn't good, but if a system works and meets its intended objective and does not cost more than 2% of its original construction cost to maintain it. Then maybe that older system is OK to keep around a while longer. We seem to wast a lot of money in this country throwing away perfectly good stuff. Many times because elected officials decide it is time to change things whether it makes any sense or not. Change for the sake of change is wasteful. Lets fix the roads, bridges and dams before we repave the internet superhighway, we have enough traffic out there already.
EDD's COBOL went live in the late 80's. It was never a 70's era system. EDD began replacing COBOL with Visual Basic (eventually .NET) in 2005, not 2009, and it was the decision of the CIO, who was astoundingly incompetent, not due to any COBOL programming shortage. EDD's COBOL programmers never caused a delay in processing any UI checks. All delays to UI check-processing in the past 20 years have been directly attributed to incompetent managers, bad process, and disorganization beyond the control of programmers. By 2007, EDD managers, under the direct micromanagement of the CIO, had bungled most of the object-oriented development projects for which they had received ~$30Million. They did this by hiring and promoting a vast array of stupendously unqualifed staff and managers. A personnel sea change hit EDD's IT branch. The CIO, now hopelessly mired in a cesspool of incompetence created by himself, having rendered EDD's IT branch capable of Help Desk and Hardware/Software Support, only, began to request additional sums to bring in vendors, and the flood gates opened, and haven't closed since. $300Million and counting... all to replace COBOL? Heads should be rolling. Lots of heads.
I work for the Office of Information Technology for the State of Colorado. Prior to Ms Russell's appointment, the state of Colorado's documented track record for replacing old systems has been a disaster. Hundreds of millions of dollars wasted on failed replacement systems. Who said COBOL is bad and .Net is good? It is an illusion that you think that one state is the same as another. That is simply untrue. You cannot find some vanilla system that is one size fits all. The customizing for each state is horrendously expensive. The only solution is simply to replace each system little by litte, take each needle off the pine tree one at a time while shoring up your current COBOL system and perhaps rewriting those modules in a more elegant fashion in the meantime. Try automating business rules over the life of a current production system in some clunky ERP. Track records for ERP systems is that they fail over 75% of the time accoding to Gartner. I would not bet my agency on those percentages, but who am I to know, I have only been in IT for 34 years in both the privte and public sectors, in high tech, telecommunications, banking, and state government, and there is still more COBOL out there than IT management is willing to let on. That is the dark and dirty secret.
Use the Safari browser and just click on the "Reader" button in the URL window. A beautifully-formatted, printer-ready (and easily scrolled and read) window pops up. All that's missing is the clutter and ads ;-)