|
Videos
November 15, 2011 By Matt Williams
But there are still obstacles to overcome, and Robinson said those barriers tend to involve policy rather than technology. There are jurisdictional issues that need to be clarified. States, in some cases, have starkly different business rules, which will make using a shared system more difficult. Some states also have restrictions on cost recovery such that they couldn’t operate a shared system and charge other states a fee for using it, Robinson added. Also, it remains to be seen how these shared systems will be procured and managed. Will a consortium manage a system together, or will one state take the lead? But overall, these hurdles haven’t dampened enthusiasm for the concept.
“Clearly there is more interest in these multistate endeavors, particularly around the common functions that all states need to do — which would be ideal for a shared service operated by one state,” Robinson said. Similar to the UI consortia that are already under way, a few state CIOs such as Utah’s Fletcher have been pushing for support on shared MMIS. A coalition of western states is also going in together on an RFP for shared storage of GIS data — Colorado is one of them.
The multistate systems are one part of Colorado’s larger plan to update its legacy systems. Russell believes her state must also look within, at how it manages, budgets for and prioritizes its oldest computer systems. She doesn’t want any more “one-off” development of big, monolithic IT systems that can’t be upgraded as needs change.
Russell’s trying to get lawmakers, who hold the purse strings, to think about the sustainability of IT — and that means including ongoing maintenance, disaster recovery and security into the cost estimate of any new project. She plans to put forth new legislation that would codify this forward-looking strategy in Colorado. “What happens is that people get really fixated on the shiny new ball rolling across the table, and then they build the system and forget that grant funding ran out and they don’t know how to support it,” Russell said. “And that is why the systems get old.”
Russell also plans to build out a “comprehensive risk index” for all of the state’s IT systems — new and old. Each system will be assigned a numerical score, like a person’s cholesterol number or maybe a golf score. The higher the number, the worse off the system is. Russell wants this ranking number to dictate what system replacements are funded first and which are pushed down the list for later. The arithmetic will include the age of the system, what software it runs on and how secure it is. The business case also will be considered: Just because a system is old won’t necessarily mean it should be replaced right away.
The idea is to have a systemic picture of all of Colorado’s systems so that lawmakers can make informed funding decisions. Russell wants the state to have the necessary information to make proactive decisions instead of reacting after a system goes down. “We have a plan to not just solve the current problem,” she said, “but to solve the root cause of how we got here.”
Writer Colin Wood contributed to this story.
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 ;-)