|
Videos
November 15, 2011 By Matt Williams
Former Oracle executive Kristin Russell used to be in charge of all the company’s data centers and worldwide computer operations. She was accustomed to technology being replaced every three to five years, a norm in the private sector. So when she decided to join Colorado Gov. John Hickenlooper’s administration earlier this year to serve as the state’s secretary of technology and CIO — her first government job — she was shocked by the condition of the state’s computer systems.
She learned that Colorado’s unemployment benefits system is 25 years old, its tax system is 23 years, and its titling system is 26 years old. And a recent audit found that the state’s financial reporting system, which processes $36 billion in expenditures annually, is at risk of failure. Russell’s discoveries confirmed an analysis two years ago of 200 of Colorado’s IT systems, which found that 77 of the state’s IT systems were more than 15 years old, and half had been around for at least a decade.
Many of these computer systems are coded in antiquated computer languages known only by the most senior of personnel — many of whom are set to retire in the next few years. The companies that built these systems in the first place no longer support them because the technology is so old, which drives up support costs with each passing year.
The situation has left Russell to wonder exactly how long her state can continue to scrape by. She likened state government’s systems to a consumer who is trapped in the past. The rest of the world has moved on to iPods and high-definition TV, but state governments continue to run eight-tracks and black-and-white sets.
There’s a growing sense that states like Colorado have run out of time, and that replacing these decrepit systems is a necessity, not a choice. Russell is among the optimists who believe that state governments can find a way to replace their old systems, even though funding appropriated by state legislatures and the federal government to do the necessary upgrades likely will be limited. Achieving success will require news ways of thinking and a willingness to work together.
“Being in IT and the high-tech industry my entire career, the big approach to brand-new systems has been tried out many times with increasingly disastrous results in terms of cost expenditures and failures,” she said. The “light switch” type of approach to system design and implementation is passé. “We need constant evolution to be in a better place than where we are today, and reliance on and help from the private sector and third-party vendors to help get there.”
CIOs like Russell are encouraged that states are working on developing systems that they can share. The thinking is that by banding together, these “multistate” systems can be updated as time goes on, helping to avoid the current problem of outdated computer systems. It also might be significantly cheaper.
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 ;-)